Versions Compared

Old Version 26

changes.mady.by.user David Walend

Saved on

compared with

New Version Current

changes.mady.by.user Simon Chang

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reverted from v. 31

...

mv newcert.pem shrine-client-signed.pem

For

...

All Other Nodes

The site node administrator will require the Java keytool, which should already be included on a SHRINE-capable machine.

...

keytool -import -v -alias shrine-hub-ca -file shrine-hub-ca.pemcrt -keystore $KEYSTORE_FILE -storepass $KEYSTORE_PASSWORD
keytool -import -v -alias shrine-hub-https -file shrine-hub-https.pemcrt -keystore $KEYSTORE_FILE -storepass $KEYSTORE_PASSWORD
keytool -import -v -alias $KEYSTORE_ALIAS -file shrine-client-signed.pemcrt -keystore $KEYSTORE_FILE -storepass $KEYSTORE_PASSWORD -keypass $KEYSTORE_PASSWORD -trustcacerts

...

  1. Your own PrivateKeyEntry, with an additional certificate chained to it. The "Issuer:" line should reflect information from the hub's CA, not your own. This is the signed certificate from the Hub (signed from the CSR). 
  2. The hub's HTTPS certificate.
  3. The hub's CA signature certificate. The "Owner:" line on this should match the "Issuer:" line on your PrivateKeyEntry's certificate.

Update shrine.conf and Restart SHRINE

Serve https

It is often fine to serve https using your own private key entry. However, if the CA is not signed by a certificate authority recognized by your users' browsers then they will have to click through warnings to use SHRINE. Also, some institutions may prefer SHRINE nodes to use different certificates to serve https. It is perfectly fine to import an extra cert into the keystore to serve https, but you should inform the hub admin of changes in advance. Your adapter will not run queries until the hub trusts your new cert, but the hub admin can harvest the public side of the cert using openssl.

Configure tomcat to serve https via its server.xml file:

 

Code Block
<Connector port="{{ shrine_ports.https }}" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
               keystoreFile="{{ tomcat_keystore_path }}"
               keystorePass="{{ tomcat_keystore_password }}"
               keyAlias="{{ tomcat_keystore_alias }}" />

Update shrine.conf and Restart SHRINE

SHRINE must be configured to understand this type of setup, SHRINE must be configured to understand this type of setup, as it does not assume the presence of a CA by default. For more information on these values, consult the SHRINE Configuration File article and look up attachSigningCert and caCertAliases.

...

In all cases, add the caCertAliases option into the keystore block, and make sure that the values for privateKeyAlias and password are also set appropriately. privateKeyAlias should be the same as $KEYSTORE_ALIAS. Also note that caCertAliases is an a json array of values. Do NOT surround it in only quotation marks, square brackets must be used. The value should match the alias of the -ca cert imported earlier. If using the ssl_keytool.sh script to import, the alias will automatically be set to the filename of the cert file.

keystore {
  [...]
  caCertAliases = ["shrine-hub-ca.pem"] 
  [...]
}

Save these changes and restart SHRINE. Assuming all passwords and other values are set appropriately, SHRINE should start up successfully, and it will now trust incoming queries from any node that attaches the CA certificate to their query signature.

...