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:

  1. the certificate
  2. the private key
  3. the certificate chain, and
  4. 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.


This is the public certificate file. You won’t need to change this.


This is the private key of the certificate. You won’t need to change this.


This is the public certificate chain file and this is the file you’ll need to change.


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