First, do you need to fix anything?
If your certificate is not signed by Sectigo or COMODO, then you don’t need to fix things.
If your current certificate is signed by Sectigo or COMODO, but its chain does not expire soon, then you don’t need to fix anything.
It is our experience that popular browsers (e.g. Chrome, Firefox, IE, and Safari) do not use the chain provided by server. Instead, the browser uses the certificate store already on the desktop/notebook. So web service should not be impacted. It’s broken, yet it doesn’t need to be fixed.
We believe only server-to-server SSL is affected.
You will only need to fix something if it’s broke: if your certificate is signed by a certificate chain that is expiring soon (May 30th, 2020). See Testing Your Certificate Chain.
SSL Configuration Basics
Each application or service will have its own specific configuration file and syntax. But each SSL configuration will have four values:
- the certificate
- the private key
- the certificate chain, and
- the certificate authority
The CA bundle is not specific to the service. It’s a large set of certificates. It probably has 150 or more certificates. It’s often confused with the certificate chain file which is specific to each certificate. Only the certificate chain must change.
The most common SSL-protected service is a web server and the most common web server is Apache’s httpd. So, we’ll look at the httpd config. And we’ll look at the OpenLDAP server config, which is slightly different.
Sectigo vs COMODO Certificate Chains
UofT has contracted with COMODO certificate service many years. Recently, the service became Sectigo. And we still have active COMODO certificates. So you’ll need to check which certificate authority signed your certificate. Also, you may have a certificate signed by someone else.
If your certificate is not signed by Sectigo or COMODO, the chain expiry doesn’t affect your service.
If you certificate is signed by Sectigo or COMODO and the chain expires soon, you’ll have to replace the chain. And you have to choose the chain that matches your signer. Pick the matching chain from:
We’ll presume your certificate is signed by “Sectigo RSA Organization Validation Secure Server CA” and use Sectigo-AAA-chain.pem.
Apache httpd SSL Configuration
Typically, httpd is installed via RPM or another package manager. The configuration files will be installed in /etc/httpd or, /etc/apache. The root configuration file will likely be /etc/httpd/conf/httpd.conf and it will include other files, like /etc/httpd/ conf.d/ssl.conf which would have the SSL settings.
SSLCertificateFile
This is the public certificate file. You won’t need to change this.
SSLCertificateKeyFile
This is the private key of the certificate. You won’t need to change this.
SSLCertificateChainFile
This is the public certificate chain file and this is the file you’ll need to change.
SSLCACerttificateFile
This is the large set of global root certificates. You won’t need to change this. It might be commented-out. That’s fine: it’ll use the SSL default ca-bundle.crt.
For example, your ssl.conf might include:
SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
Replace the SSLCertificateChainFile
Download the new certificate chain.
Copy the file into the directory with your other SSL cert files.
cp Sectigo-AAA-chain.pem /etc/pki/tls/certs/Sectigo-AAA-chain.pem
Then modify the ssl.conf settings:
SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key SSLCertificateChainFile /etc/pki/tls/certs/Sectigo-AAA-chain.pem
Then test httpd:
# apachectl configtest
And reload httpd to make the new chain active:
# apachectl graceful
OpenLDAP’s slapd Configuration
OpenLDAP configuration is a similar, but it does not have CertficateChainFile setting. Instead, you’ll have to include the chain in the TLSCertificateFile. The OpenLDAP config file is likely /etc/openldap/slapd.conf and should contain:
TLSCertificateFile /etc/openldap/ssl/server.crt TLSCertificateKeyFile /etc/openldap/ssl/server.key
Your server.crt file might already have the chain. You’ll need just the host’s certificate and not the chain. Create a file with the current host certificate and the new certificate chain:
cd /etc/openldap/ssl cat server-cert-only.pem Sectigo-AAA-chain.pem > /server-with-chain.pem
And then set your configuration to point to this file:
TLSCertificateFile /etc/openldap/ssl/server-with-chain.crt TLSCertificateKeyFile /etc/openldap/ssl/server.key
Run slap test
/usr/sbin/slaptest -f /etc/openldap/slapd.conf -v
If successful, restart slapd. Restart procedure is system specific, but it’s likely one of the following commands.
systemctl restart ldap systemctl restart slapd service ldap restart service slapd restart
Or you may have to stop and start.
service ldap stop && service ldap start