Page History
...
In order to reduce administrative overhead in larger hub-and-spoke SHRINE topologies, SHRINE will support using certificates signed by a central Certificate Authority (CA) starting with SHRINE 1.18. Using this approach, a SHRINE network will establish its own private CA (typically administered by the hub administrator), and sites generate certificate signing requests that will be signed by this CA. A SHRINE node then adds this new CA-signed certificate and the CA's own certificate to their keystore, and then adds a few values to shrine.conf. Now, instead of having to import the certificate of every other site on the network along with the hub's certificate, a site only needs to import the hub's CA certificate. If the site receives a query from another node that has been blessed by the same CA, SHRINE will trust that query. This moves the trust model from each individual site to the hub (and thus, the network as a whole), making it easier to add additional nodes to the network later on.
It is We highly recommended that SHRINE networks going forward adopt this approach whenever possible, especially for networks larger than 4 nodes. When using a CA in a hub-based topology, a node only needs to create firewall exceptions for one other host (the hub) and only needs to perform one certificate exchange, solving the N^2 problem that has traditionally afflicted larger SHRINE networks.
...
The server that will function as the Certificate Authority will require a distribution of OpenSSL with the CA.sh/CA.pl/CA helper script. While it is possible to operate as a CA without the helper script, it is strongly recommended to use the helper script, as it makes life much easier. The exact location of this helper script varies from distribution to distribution, but two three places to start are either are /usr/local/ssl/misc or , /etc/pki/tls/misc, and /System/Library/OpenSSL/misc. The latter of these two is what CentOS uses, and the rest of the guide will be written assuming a CentOS environment.
...
The script will ask for a password, which you will be prompted for whenever accessing the private key. Keep this password safe and secure. Additionally, in typical SHRINE setups that do not differentiate between HTTPS and SHRINE signing certificates, the password for this private key must be the same as the password used for the keystore ($KEYSTORE_PASSWORD).
...
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.
...
Or, for a more convenient method, copy the ssl_keytool.sh script from the SHRINE installer and run the following command instead:
...
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
...
Certificate reply was installed in keystore
If it does not, verify that you $KEYSTOREthat $KEYSTORE_ALIAS is set appropriately and that the keytool command is set to import to the correct alias. Also make sure that the CA's signing certificate was imported first. This must be present before the last command will work.
...
- 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).
- The hub's HTTPS certificate.
- The hub's CA signature certificate. The "Owner:" line on this should match the "Issuer:" line on your PrivateKeyEntry's certificate.
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 shrineUpdate shrine.conf and Restart SHRINE
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.
...
Overview
Content Tools