Strange behavior

Hello good afternoon!
I have been using this great service for several years, thank you very much.

Case 1: imc-qro.autoshop-easy.com - autoshop-easy.com
Lately I have been experiencing some strange behavior: the most recent certificate for a subdomain works intermittently, that is, browsers sometimes find it valid and minutes later they no longer recognize it as valid. I noticed that when they don't identify it as valid it's because instead of seeing the subdomain's certificate (imc-qro.autoshop-easy.com), they try to use the domain's certificate (autoshop-easy.com), which of course results in error.
Because it is a productive service I had to use a different domain to keep the service stable, so imc-qro.autoshop-easy.com is down at the moment.
My server is Debian 9, Virtualmin, Apache 2.4, I get my certs through Virtualmin.

Case 2: quien-vende.com
Now I am experiencing another error in another of my certificates for another domain: when I try to read a file with wget or from PHP with file_get_contents I get different results, one with error and one normal from different machines.





These strange behaviors started a week ago.
My server is Debian 9, Virtualmin, Apache 2.4, I get my certs through Virtualmin.

In advance I appreciate any help you can give me.
Greetings!

1 Like

Hi @agusdiaz,

This is a little hard to debug without being able to interact with it; can you send us a screenshot of the error and also maybe put this service up again and tell us the original IP address?

This probably relates to the recent DST root certificate expiration and the "long chain" vs. "short chain" issue.

There are tons of (rather long) threads on the forum about this issue because various consequences of this have affected many people. However, if you don't want to read all of them right now, you might just look at

https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/

This describes the issue from the point of view of the servers running wget using the OpenSSL library. One solution could be to upgrade to a newer version of OpenSSL, or you could use any of the other workarounds described there, including changing from the Let's Encrypt "long chain" to "short chain" (removing the expired X3 root). (The reason that the expired root is still included is to maintain compatibility with older Android systems, which will only work if this is provided; unfortunately, including it also reduces compatibility with older versions of OpenSSL and related software.)

1 Like

It seems that your Mac may need an update to its' trusted root store.
I don't use Mac, so I can't say with certainty how that is done.
But I think there is a topic for that elsewhere on this forum.

Hi @schoen, thanks for your answer.

My website users access our systems from most browsers and mobile platforms with a mix of old and new devices. From your comments I understand that there is an attempt by LetsEncrypt to preserve the balance. I read the document you shared with me, so I will proceed to establish alternatives for our productive environment. I thank you again for your comment.

Hi @rg305, thanks for your answer.

The commands were sent from Ubuntu Linux 16.04 LTS. Each screen from different machine on the same network (México) to the server (Canada)

1 Like

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