Skip to content

SSL Certs

Jump to bottom
Doug Hagan edited this page Oct 27, 2017 · 8 revisions

Process

  • Service (MeTL) provider (SVC): publishes a services at the domain, has public certificate (supported by intermediate certificate) and private key
  • Certificate provider (CP): owns the intermediate certificate (public certificate for signer of other public certificates, signed by root authority), and generate cryptographically-related public certificates
  • Domain Manager (DM): is able to add records to DNS for the domain
  1. SVC generates private key
  2. SVC creates CSR (certificate request) for a domain, that contains crypto from private key but not the key itself
  3. SVC sends CSR to CP
  4. CP provides an control verification record (CVR) to SVC, that it requires be added to DNS to prove that SVC is trusted (controls the domain that is requested)
  5. SVC provides CVR to DM
  6. DM adds a TXT record to DNS containing the CVR
  7. CP reads TXT record to verify that SVC is able to manage (via proxy) the domain
  8. CP provides a bundle containing public certificate and intermediate to SVC
  9. SVC installs the public certificate and private key to a keystore so that the webserver can refer to them (eg Jetty)

Parties for SLU

  • SVC is Stackable
  • CP is Thawte (presumably)
  • DNS manager is SLU

Creating a Java Key Store (JKS) for Jetty

The public (server.crt) and intermediate (ca.crt) certificate files must be in x509 base64-encoded format.

> cat server.crt > certAndCa.pem
> cat ca.crt >> certAndCa.pem

Create a p12 keystore containing the public and intermediate certificates.

> openssl pkcs12 -export -in certAndCa.pem -inkey private.key -out keystore.p12 -name jetty

This will prompt for a 'keystore password' for the P12 keystore.

Create a JKS from the p12 keystore.

> keytool -importkeystore -destkeystore keystore.jks -srckeystore keystore.p12 -srcstoretype PKCS12 -srcstorepass [password] -alias jetty

This will prompt for a 'keystore password' for the JKS keystore.

Set a new 'private key password' (within the keystore). This has most likely been set by default to the same as the keystore password (see above).

> keytool -keypasswd -alias jetty -keystore keystore.jks

This will prompt for a password for the private key, which must be different from the JKS 'keystore password'.

NOTE: currently Vysper requires the passwords to be the same, so there are additional hoops to jump through to get them in that way.

Update Jetty to reference the new file with new passwords, via the etc/ssl-context.xml file (more secure as filesystem permissions can be set to restrict access by other system users).

<Set name="KeyStorePath"><Property name="jetty.base" default="." />/[keystore file]</Set>
<Set name="KeyStorePassword">[keystore password]</Set>
<Set name="KeyStoreType">JKS</Set>
<Set name="KeyStoreProvider"><Property name="jetty.sslContext.keyStoreProvider"/></Set>
<Set name="KeyManagerPassword">[private key password]</Set>
<Set name="TrustStorePath"><Property name="jetty.base" default="." />/[keystore file]</Set>
<Set name="TrustStorePassword">[keystore password]</Set>
<Set name="TrustStoreType">JKS</Set>

This can also be done via -D params in the startup script (less secure as other system users can see the command used to start a process).

  • jetty.sslContext.trustStorePath = [keystore file]
  • jetty.sslContext.trustStorePassword = [keystore password]
  • jetty.sslContext.keyStorePath = [keystore file]
  • jetty.sslContext.keyStorePassword = [keystore password]
  • jetty.sslContext.keyManagerPassword = [private key password]

Ensure the keystore is readable by the jetty process.

Converting certificate format

If certificates are provided in P7B format (Windows) then "open" them (using the inbuilt tool from Windows Explorer), and export as x509 base64-encoded.

Updating Apache SSL Certificates

Apache (eg metl-prod-redirector) requires three files: private key (private.pem), intermediate certificate (ca.pem) and server certificate (server.pem). As the names suggest, these are all in PEM format.

After logging on to the redirector instance, update the files in /srv/httpd/certs. The config and certificates directories are in a local git repo (no remotes) so also git commit.

The new certificate can be tested by disabling the redirect function temporarily so that the certificate of the redirector can be viewed in a browser, rather than just redirecting which makes the certificate then inaccessible. Edit /srv/httpd/conf/ssl.conf and disable the following lines (by preceding with #).

RewriteEngine on
RewriteRule "^/(.*)" "https://whiteboard.lionsshare.saintleo.edu/$1" [R,L]

Home

Clone this wiki locally