I had the same issue with a few domains, the fix above worked, but I wonder what will happen after the 30th
LetsEncrypt - SSL certificate is not valid
- fulltilt
- Thread is marked as Resolved.
-
-
I had the same issue with a few domains, the fix above worked, but I wonder what will happen after the 30th
it could be a funny day ... also because of outdated devices & software from the customer side
-
-
i think we'll get trouble. Debian test with time in the future:
# service ntp stop
# date --set="2 OCT 2021 18:00:00"
# openssl verify -CAfile fullchain14.pem -purpose sslserver cert14.pem
O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 3 depth lookup: certificate has expired
error cert14.pem: verification failed
# service ntp start
# openssl verify -CAfile fullchain14.pem -purpose sslserver cert14.pem
cert14.pem: OK
maybe
sub validateCertificate in
/var/www/imscp/engine/PerlLib/iMSCP/OpenSSL.pm
should be disabled ?
-
i think we'll get trouble. Debian test with time in the future:
maybe
sub validateCertificate in
/var/www/imscp/engine/PerlLib/iMSCP/OpenSSL.pm
should be disabled ?
doesn’t sound good ...
-
-
i think we'll get trouble. Debian test with time in the future:
I have tested this but I have no idea whether it is meaningful ...
maybe setting ISRG Root X1 as preferred in the plugin?
some more details
-
-
-
SSL Checker Results from:
https://decoder.link/sslchecker
section Certificate # 2 - Common Name: R3 shows:
Issuer Common Name: ISRG Root X1
and section Certificate # 3 - Common Name: ISRG Root X1 shows:
Issuer Common Name: DST Root CA X3
does that mean it will work or not?
Code- OpenSSL Handshake
- depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
- verify return:1
- depth=1 C = US, O = Let's Encrypt, CN = R3
- verify return:1
- depth=0 CN = mydomain.tld
- verify return:1
- CONNECTED(00000003)
- OCSP response:
- ======================================
- OCSP Response Data:
- OCSP Response Status: successful (0x0)
- Response Type: Basic OCSP Response
- Version: 1 (0x0)
- Responder Id: C = US, O = Let's Encrypt, CN = R3
- Produced At: Sep 28 14:37:00 2021 GMT
- Responses:
- Certificate ID:
- Hash Algorithm: sha1
- Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4
- Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6
- Serial Number: 0489B634CBFFEF56829022CD544550B3BC04
- Cert Status: good
- This Update: Sep 28 14:00:00 2021 GMT
- Next Update: Oct 5 13:59:59 2021 GMT
-
-
-
maybe
sub validateCertificate in
/var/www/imscp/engine/PerlLib/iMSCP/OpenSSL.pm
should be disabled ?
maybe disable the LE cronjobs if problems occur - should avoid deleting of the apache vhost-ssl.conf files ...
Code- nano /etc/cron.d/imscp
- # imscp [Plugin::LetsEncrypt::pending] entry BEGIN
- #@hourly root /usr/bin/perl /var/www/imscp/gui/plugins/LetsEncrypt/cron/pending.pl > /dev/null 2>&1
- # imscp [Plugin::LetsEncrypt::pending] entry ENDING
- # imscp [Plugin::LetsEncrypt::renew] entry BEGIN
- #@daily root /usr/bin/perl /var/www/imscp/gui/plugins/LetsEncrypt/cron/renew.pl > /dev/null 2>&1
- # imscp [Plugin::LetsEncrypt::renew] entry ENDING
-
Thu Sep 30 15:04:24 CEST 2021
the good news is ...
when I create a new certificate > verify result:
however, the verify result for older certificates which are still valid > dec
these are still shown as valid in web browser but what happens when the daily letsencrypt cron job has run through tomorrow?
are these ssl apache configs deleted and certs marked as invalid afterwards?
I guess when old fullchain1.pem is being replaced with a new fullchain1.pem it could work ...
-