9

I am having a strange issue I cannot find the cause of: I have a website certificate issued on 31.07.2021 by letsencrypt.org and valid until 29.11.2021, however on my main iPhone (iOS 15) I get this error saying "Expired 29.09.2021" (on any browser: chrome, safari, etc):

certificate fail

The certificate is not revoked, I checked with both letsencrypt.org and https://certificate.revocationcheck.com. As mentioned on any other devices (laptop, other iPhones and iPads, desktop) the certificate is trusted and shows as valid. Or if I manually set my date on my main iPhone prior 29.09.2021 the certificate is working. Seems like a "manual" not trusted entry somewhere on my main iPhone, but I don't know where to check, I tried turning the phone off and on and clearing browser caches

I even tried issuing a new trusted certificate from letsencrypt.org but it says the same thing "Expired 29.09.2021" even if this is a totally new certificate, so there might be something related to the domain name?

I also checked "Certificate Trust Settings" on my main iPhone and other iPhones and the Trust Store Version and Trust Asset Version are identical (2021072200, however also weird that support.apple.com says the version for iOS 15 is 2021070500 https://support.apple.com/en-us/HT212773)

I am aware I should post the full certificate for full help but for privacy issues I'd avoid that until actually necessarily, maybe there's some known option causing this that I am not aware of

EDIT: I am seeing something possibly related (https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ / https://community.letsencrypt.org/t/production-chain-changes/150739), but my certificate chain is "R3 <- ISRG Root X1" and not "R3 <- DST Root CA X3" which expired today. Weird coincidence

EDIT 2: More info here https://scotthelme.co.uk/lets-encrypt-old-root-expiration/, some comments mention a possible fail due to the same name for the intermediate "R3" in chain, even though your certificate has the new "R3 issued by ISRG Root X1" your phone cache may have the old "R3 issued by DST Root CA X3" and not check for the new one...??? this would explain why the error only my main phone (where I used the certificate in the past so I may have a cached version of that "R3" intermediary...???)

5
  • Is the date on your phone set correctly?
    – DarkDust
    Commented Sep 30, 2021 at 10:47
  • @DarkDust see the screenshot ands also the comment on date changing
    – mmmmmm
    Commented Sep 30, 2021 at 10:50
  • What version of iOS is your phone?
    – mmmmmm
    Commented Sep 30, 2021 at 10:50
  • @mmmmmm iOS 15. Date is correct. I added more info about letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021 / community.letsencrypt.org/t/production-chain-changes/150739 Commented Sep 30, 2021 at 10:53
  • I found something possibly relevant: scotthelme.co.uk/lets-encrypt-old-root-expiration, some comments mention a possible fail due to the same name for the intermediate "R3" in chain, even though your certificate has the new "R3 issued by ISRG Root X1" your phone cache may have the old "R3 issued by DST Root CA X3" and not check for the new one...??? this would explain why the error only my main phone (where I used the certificate in the past so I may have a cached version of that "R3" intermediary...???) Commented Sep 30, 2021 at 11:17

2 Answers 2

8

Found a solution:

My dovecot file was referencing cert.pem instead of fullchain.pem.

Changed that, restarted services, and now working.

6
  • 2
    Somehow it is difficult to make a link between question and answer here, there is some context missing in either the Q or the A.
    – nohillside
    Commented Sep 30, 2021 at 13:06
  • 1
    Thank you, that's the solution. My server was only sending the domain certificate causing the client to fetch the intermediate certificates on its own (and it seems my iPhone was using the old cached version of the "R3" intermediate certificate which expired today), so now I am sending the full certificates chain (found in fullchain.pem file) which contains the new version of the "R3" intermediate certificate so the client doesn't need to fetch "R3" cerificate on its own (and fail by using the cache) and it works Commented Sep 30, 2021 at 13:13
  • This however is still a partial fail from Apple too, relying on a cached version of a certificate with the same name even if the new certificate with the same name has a different signature Commented Sep 30, 2021 at 13:13
  • Im curious whether this is related to using Apple’s new Mail Privacy Protecton? Is that where the Apple-cached certificate comes into play? Or is it simply a certificate configuration issue? Thx. Commented Sep 30, 2021 at 18:11
  • This answer did help me solve the same issue with my email server, however it took some deciphering. For anyone else with as little understanding as me, when Let's Encrypt produces the certificates, you get a file that just contains your certificate (which is the one I was using in my dovecot/conf.d/10-ssl.conf file) and one called fullchain which contains multiple certificates. The fullchain is the one to use. Interestingly, mine are created with .crt file extensions, not .pem but that does not matter, it seems. Commented Oct 1, 2021 at 7:42
1

Same problem here, solved changing the cert.pem with the fullchain.pem because the cached R3 cert (for intermediate authority) remain valid.
Open Postfix configuration to change:
nano /etc/postfix/main.cf
control w to search for ssl
Modify where line start with smtp_tls_cert_file
smtp_tls_cert_file = /etc/letsencrypt/live/YOUR_DOMAIN/cert.pem
With
smtp_tls_cert_file = /etc/letsencrypt/live/YOUR_DOMAIN/fullchain.pem
Then change Dovecot configuration:
nano /etc/dovecot/dovecot.conf
Modify where line start with ssl_cert
ssl_cert = </etc/letsencrypt/live/YOUR_DOMAIN/cert.pem
With
ssl_cert = </etc/letsencrypt/live/YOUR_DOMAIN/fullchain.pem
Then restart services
service dovecot restart
service postfix restart

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .