Versions Compared

Old Version 28

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

...

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.

...

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.

...

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.

...