SSL certificates can be a crazy and confusing mess. I'm using Apache but this is good info for any server. Good luck!!!!!
Browsers won’t trust your certificate outright because they can’t identify the authority behind it. That’s where root certs come in; they vouch for the authority who signed the certificate. But sometimes root certificates also delegate some authority to intermediate/subroot certificates. The InCommon (or whatever it’s called now) has a root certificate and one or two intermediate/subroot certificates depending on when it was generated. So, in order to get a browser to trust the traffic coming from Apache, you need to supply all of those certificates in the “right” order.
The Easy Solution
Use certbot. It automates everything for you. If that doesn't work for some reason, then take three deep breaths and continue.
We need three files:
- A key
- A signed certificate
- A certificate chain (AKA "chain file")
We are going to PEM encode all certs so that we can stick them all in one file, which we'll call our "chain file".
- Certificate Authority An entity that issues certificates.
- Certificate A public key. Essentially, it makes it possible for a browser to communicate to a server over HTTPS.
- Root Certificate A certificate that all major browsers already trust. You need one of these at the top of your "chain of trust" in order for the browser to allow HTTPS.
- [Signed Certificate]()
- Certificate Signing Request (CSR) A message sent to a certificate authority to apply for a new certificate.
- Self-Signed Certificate A certificate that anybody can make for free. You can only use one of these if you have control over the client computers, because you need to tell the client computers to trust the self-signed certificate. For example, in a corporation or at a university. You still can't use it for a public web site, though, because users at home won't trust the self-signed certificate.
- Chain of trust The series of certificates that leads all the way back up to a root certificate.
- Key In the context of SSL files, a "key" seems to refer to a private key that corresponds to a certificate, which is essentially the "public key" for that pair. This essentially means you keep the "key" file secret and make the certificate public, and that allows a secure connection over HTTPS.
- X.509 It's just a standard that defines the format for certificate files.
We want to convert all our certs to PEM encoding.
To test if a cert is PEM encoded, run
openssl x509 -in FILENAME -text -noout where FILENAME is your cert. If you get errors, it's not PEM encoded.
To test if a cert is DER encoded, run
openssl x509 -in FILENAME -inform der -text -noout. If you get errors, it's not DER encoded. If it is DER encoded, you can convert it to PEM by running
openssl x509 -in FILENAME -inform der -outform pem -out NEW_FILENAME
Creating the chain file
Now that all certs are PEM encoded, you can stick them all in one file. That file should have sections for all relevant certs, separated by a blank line. The sections need to be in order from your Root cert at the top, then intermediate/subroot certs, then your signed cert. Then save the whole thing. The file name can be anything you want with any extension, but we'll call it chain.crt on linux or chain.cer on windows.
Telling Apache where to find everything
In your Apache config you need to set three directives for your site.
- Set the
SSLCertificateChainFileto the absolute path of your chain cert file.
- Set the
SSLCertificateFileto the absolute path to a file that contains the signed cert. AKA only the bottom section in the chain cert file.
- Set the
SSLCertificateKeyFileto the absolute path to the key file for the signed cert.
Restart apache. If it successfully starts, it should be all good to go!!!!!! If not, check the apache error logs to find the best error message.