Troubleshooting SSL Errors

How to check the details of an SSL certificate

If you're not sure if the certificate you're using is new, old, or what info is in it, you can use the "openssl" command with the 509 option to get you more info on a certificate, e.g.,

openssl x509 -in  -text -noout
       Version: 3 (0x2)
       Serial Number: 0 (0x0)
       Signature Algorithm: md5WithRSAEncryption
       Issuer: C=US, ST=Someprovince, L=Sometown, O=none, OU=none, CN=/emailAddress=webaster@localhost
           Not Before: Jul  7 05:58:09 2009 GMT
           Not After : Nov 21 05:58:09 2036 GMT
       Subject: C=US, ST=Someprovince, L=Sometown, O=none, OU=none, CN=/emailAddress=webaster@localhost
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (1024 bit)
               Modulus (1024 bit):
               Exponent: 65537 (0x10001)
   Signature Algorithm: md5WithRSAEncryption

Similarly, you can manually connect to a remote host (e.g., )

to check if a certificate is self-signed or not:

openssl s_client -servername  -host  -port 443 | grep 'Verify return code'

where the output might look like:

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = 
verify return:1
   Verify return code: 0 (ok)

We'd take note of the Verify return code: 0 (ok) status. The "code: 0" is good, as it means the certificate is correctly signed by a certificate authority.

I usually type "QUIT" to exit the current connection (this is a client connection to Apache, so you could create a request here). Else some systems might need Ctrl-D to send an "end-of-file" character to close it.

If you see:

Verify return code: 18 (self signed certificate)

then it means the certificate could be self-signed (you created the cert/key yourself), or the ca root bundle or chain have not been correctly installed.

How to check the details of a certificate request

If you have a certificate request, and want to see what information is set inside, you can use the "openssl" command with the "req" option to get you more info on the CSR.

openssl req -in /path/to/your/certificate.request -text -noout
Certificate Request:
       Version: 0 (0x0)
       Subject: C=CA, ST=Alberta, L=St. Albert, O=JBMC-Software,
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (2048 bit)
               Modulus (2048 bit):
               Exponent: 65537 (0x10001)
           challengePassword        :A challenge password
   Signature Algorithm: md5WithRSAEncryption

DirectAdmin is not accepting my encrypted SSL key

If you have an RSA PRIVATE KEY with headers that look something like:

Proc-Type: 4,ENCRYPTED

then you would have a password encrypted key.

This will not work with DirectAdmin since it would require someone to type in a password each time Apache restarts.

You do not have to start over unless you've forgotten the password. You can actually convert this password protected key into a normal key by typing:

openssl rsa -in /path/to/your/key -out /the/new/key

where you'd replace the path values with appropriate values.

This will ask you for the password you specified when you created the original key.

It will then create a non-password-protected key that you can use for DA.

The LetsEncrypt DST Root CA X3 Expiration, Fixes, and ZeroSSL Support

Albeit a rare occurrence, CA root certificates do occasionally expire, and this can cause a multitude of SSL errors for clients using older OpenSSL versions and/or outdated ca-certificate installations.

The Public Key Infrastructure (PKI) facilitates SSL and public key encryption management, providing CIA (confidentiality, integrity, and authenticity) trust services. It includes a Truststore, which is a locally stored list of all 'trusted' root CA self-signed certificates stored directly on your OS. This establishes explicit trust for the root CAs listed.

Root CA certificates are necessary in validating a Chain of Trust in order to verify the authenticity of an organization claiming to own the domain for which the SSL is implemented. A trusted Registration Authority (RA) will create their own self-signed root CA certificate (which is trusted explicitly via your truststore), then, in order to guard it as much as possible, will store it offline and create/sign intermediate SSLs (sub CA certificates) with it (these must be verified). These intermediate SSLs are then permitted to sign your domain's SSLs on behalf of the root CA. If any of the SSLs in this Chain of Trust are broken, SSL errors may result.

So, what happens when a root CA certificate expires and how can we rectify the errors that result?

LetsEncrypt and ISRG

LetsEncrypt started out using a known and trusted CA, IdenTrust, to cross-sign their root certificate until their own ISRG root certificate became widely trusted. Now that it is, the existing root CA is expired. However, existing SSLs that were signed with this now expired root CA may show SSLs with different utilities if the computer you are connecting from has the expired root CA still listed in its truststore.

An example of this is recent connections via CustomBuild to DirectAdmin mirrors that have valid SSLs, but the chain includes the expired root certificate, so SSL errors like this excerpt from a CustomBuild run may result:

ERROR: cannot verify's certificate, issued by '/C=US/O=Let\'s Encrypt/CN=R3':
  Issued certificate has expired.
To connect to insecurely, use `--no-check-certificate'. against the mirror shows this:

In trust store 	DST Root CA X3   Self-signed	
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
Weak or insecure signature, but no impact on root certificate

The cross-signed SSL shouldn't be a problem if the expired root SSL is removed from the TrustStore, or if OpenSSL v1.1.0 or later is in use rather than OpenSSL v1.0.2.

OpenSSL v1.1.0 has improved certificate chaining so that trusted store certificates are preferred over untrusted certificates, thus allowing a working certificate chain to be built.

So, if you're using an older version of OpenSSL, you have the following options to rectify this issue for connecting to domains that use the expired root certificate in their chain:

  1. Upgrade OpenSSL to v1.1.0 or later
  2. Upgrade the package ca-certificates
  3. Blacklist the expired root certificate in your TrustStore

If these errors are occurring on your own site, you can:

  1. Use --preferred-chain in ACME LetsEncrypt libraries, such as is used with DA's own script now, to specify the preferred chain to be built using the valid ISRG root certificate.
  2. Use an alternate provider to issue your SSLs, but know that they, too, will have an expired root certificate one day, as this issue is not specific to LetsEncrypt only (recall the Comodo/Sectigo AddTrust External CA Expiration of May 2020?open in new window).

How to Upgrade OpenSSL

These upgrades would be handled by your OS. Reference your OS vendor's documentation for how to proceed here.

For example, for CentOS, Cloudlinux and other RHEL servers, you can use yum or dnf to run updates: yum update or dnf update

Alternatively, you can update specific packages, via a package manager like dnf, or by compiling from source. Again, reference your OS vendor's documentation for instructions.

How to Upgrade the ca-certificates package

This, too, is vendor specific.

Check if your truststore contains the expired LetsEncrypt DST CA Root X3 certificate:

trust list | grep -A2 -B2 'X3'

If yes and if you're using CentOS or Cloudlinux, run this:

yum update ca-certificates

Then check that the expired certificate has been removed:

rpm -q -changelog ca-certificates | head -5

Output should be as follows:

[root@host4 ~]# rpm -q -changelog ca-certificates | head -5
* Tue Sep 14 2021 Bob Relyea <> - 2021.2.50-72
- Fix expired certificate.
-    Removing:
-     # Certificate "DST Root CA X3"

[root@host4 ~]# 

And wget/curl commands used by CustomBuild should now succeed:

[root@host4 ~]#  wget
--2021-11-11 09:17:11--
Resolving (, 2607:5300:60:1eb6::16
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 265985 (260K) [application/octet-stream]
Saving to: ‘custombuild.tar.gz.1’

100%[================================================================>] 265,985     --.-K/s   in 0.08s   

2021-11-11 09:17:11 (3.05 MB/s) - ‘custombuild.tar.gz.1’ saved [265985/265985]

[root@host4 ~]# 

If using Debian:
sudo apt-get --only-upgrade install ca-certificates or
sudo apt-get install --reinstall ca-certificates

How to blacklist the expired certificate in your TrustStore

First, get the pkics11 id:

trust list | grep -A2 -B2 'X3'


[root@host4 ~]# trust list | grep -A2 -B2 'X3'
    type: certificate
    label: DST Root CA X3
    trust: anchor
    category: authority
[root@host4 ~]# 

Since this is a read-only certificate, it cannot be removed with the trust anchor --remove command:

[root@host4 ~]# trust anchor --remove "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10;type=cert"
p11-kit: couldn't remove read-only certificate
[root@host4 ~]# 

Instead, dump the certificate into a file so that it will be blacklisted in your TrustStore (be sure to confirm the appropriate path for your OS):

trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10;type=cert"  > /etc/pki/ca-trust/source/blacklist/DST-root-CA-X3.p11-kit

Then, update the ca trust store:


Output expected will be similar to the following:

[root@host3 ~]# update-ca-trust
p11-kit: overriding trust for anchor in blacklist: DST-root-CA-X3.p11-kit
p11-kit: overriding trust for anchor in blacklist: DST-root-CA-X3.p11-kit
p11-kit: overriding trust for anchor in blacklist: DST-root-CA-X3.p11-kit
p11-kit: overriding trust for anchor in blacklist: DST-root-CA-X3.p11-kit
p11-kit: overriding trust for anchor in blacklist: DST-root-CA-X3.p11-kit
[root@host3 ~]#

Now, upon checking your TrustStore, you'll see that the certificate is blacklisted:

[root@host3 ~]#  trust list | grep -A2 -B2 'X3'
p11-kit: overriding trust for anchor in blacklist: DST-root-CA-X3.p11-kit
    type: certificate
    label: DST Root CA X3
    trust: blacklisted
    category: authority
[root@host3 ~]# 

And the errors are gone:

[root@host3 ~]# wget
--2021-11-11 03:24:49--
Resolving (, 2607:5300:60:1eb6::16
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 265985 (260K) [application/octet-stream]
Saving to: ‘custombuild.tar.gz’

100%[==================================>] 265,985     --.-K/s   in 0.08s   

2021-11-11 03:24:50 (2.99 MB/s) - ‘custombuild.tar.gz’ saved [265985/265985]

[root@host3 ~]# 

How to use --preferred-chain with

This allows you to specify which chain will take precedence, so that OpenSSL v1.0.2 won't end up using the untrusted, expired certificate for the chain. It will instead use the certificate you specify. This is done for you automatically via the script, which sets the preferred-chain to "ISRG Root X1".

How to use an alternate provider- ZeroSSL

Per’s-encrypt-problems.64652/post-336508open in new window:

We have prepared an early tech preview of a ZeroSSL support. For this to work we released a new lego version (capable of issuing ZeroSSL certificates) and new letsencrypt version v2.0.24. Participation in this early preview is controlled by the existence of /root/.zerossl file. If this file is present DA will try issuing cert from ZeroSSL, if this file is absent everything will work as before (certs issued from LetsEncrypt).

If you would like to try it out please do the following:

da config-set default_acme_provider zerossl
/usr/local/directadmin/scripts/ request

The following command can be used to confirm that a ZeroSSL certificate is now in use:
openssl s_client -connect -servername

Last Updated: