CERTIFICATE_VERIFY_FAILED in application since DST Root CA X3 Expiration

Help
1

My domain is: api.luxaround.de

My web server is (include version): Apache 2.4.29

The operating system my web server runs on is (include version): Ubuntu 18.04

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Certbot 1.20.0

Additional info: openssl 1.1.1 (11 sep 2018)

Now the problem: since the expiration of the DST Root CA X3, I updated the certificates of my server, and ssl checks with openssl show me, that it has been done correctly (with the help of the community :slight_smile: ).
But now, one of the applications running on this server fails to call the server itself, the logfile only says [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852).

I have to admit: The application running on it is not made or maintained by me, it just happened, that I have to fix it without knowing anything about it or having contact to the original devs...

I think that there is somethin wrong with the certificate chain. The currently used chain can be seen here: https://decoder.link/sslchecker/api.luxaround.de/443
I don't know, which chains I can try because I can't find the names of them.

So the question(s):

  • How are the names of other applicable certchains?
  • I tried to install isrg-root-x2.pem and lets-encrypt-r3.pem, but the system didn't install any of them. When I checked all installed root-CAs, those two were not listed.

Do you have any Idea, what I can check to get this solved?

2

@DerManiac
There are two ways to fix/overcome this problem.

  1. update the app to use a trust store that includes the new (since 2015) "ISRG Root X1" root cert.
    [this may mean finding which trust store is used and updating the trust store - perhaps manually]
  2. switch trust paths:
    a. to the longer/default path
    But since you are using the shorter/alternate path, I can only presume the longer one failed with other clients and you were forced to switch. So... I suspect that neither of the LE trust paths will resolve all of your client needs.
    b. to another (FREE and ACME friendly) CA
1 Like
3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.