Page History

...

As the script says, it will generate a file called newcert.pem. This is the final signed certificate that should be given back to the requestor. Alongside this signed certificate, the hub administrator should also send their cacert.pem (hopefully copied and renamed with a more descriptive name) file so the requestor can import the CA certificate into their keystore.

Signing Certificates with SubjectAlternativeName

If a certificate has X.509 extensions (typically SubjectAlternativeName), the CA script should not be used since it will ignore those extensions when signing the certificates. Instead, we must use the openssl tool manually and provide it a special .cnf file to match the certificate.

Make a copy of openssl.cnf (typically found in /etc/pki/tls on RedHat-based distributions) and place it alongside the CSR:

cp /etc/pki/tls/openssl.cnf /etc/pki/tls/misc/shrine-client.cnf

In the [ req ] block of the newly-created .cnf file, make sure the following line exists or is uncommented:

req_extensions = v3_req

In the [ v3_req ] block of the newly-created .cnf file, make sure the following line exists:

subjectAltName = @alt_names

Below the [ v3_req ] block, add the appropriate SubjectAlternativeName information like this:

[ alt_names ]
 IP.1 = CERTS.PUBLIC.IP.ADDRESS

Then sign the cert using the following command:

openssl ca -policy policy_anything -out shrine-client-signed.pem -config shrine-client.cnf -extensions v3_req -infiles shrine-client.csr

Rename Files

This is mostly a warning, but when generating CSRs or signing certificates using the CA script, it will write to newkey.pem, newreq.pem, and newcert.pem. These files will be overwritten if generating or signing multiple certificates! Make sure to move or rename these files before moving on to the next certificate request! For example:

...

Make absolutely sure the -alias value in the second command exactly matches the alias used for your original certificate! (the one marked as PrivateKeyEntry )! in the keystore) Otherwise, queries will fail with signature verification errors, since the CA's signature not be on the exact same keystore entry that SHRINE uses. Upon importing your signed certificate, the following message should appear:

...

If the node is a Query Entry Point, add the attachSigningCert option into the queryEntryPoint block, and make sure the broadcasterServiceEndpoint.url value points at the appropriate hub.

queryEntryPoint {
  [...]
  attachSigningCert = true
  [...]
  broadcasterServiceEndpoint {
    url = "https://shrine-hub.u-of-example.edu:6443/shrine/rest/broadcaster/broadcast"
  }
}

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 array of values.

...