Certificates Showing As Expired on some platforms

Help
1

My domain tenjinconsulting.co.uk has been working fine for years, suddenly now throwing errors on the certificate. This is the same for all certs I have on this server.

However, my certificates are showing as current and live (expiring in Nov 2021, so last renewal worked), and if I access the website via Firefox on Mac OS it shows the correct certificate. Forcing a certificate refresh on my server it tells me that all certs are valid and so skips all of them.

However, accessing my mail server on the same domain I get an "untrusted" message.

That message (same on iOS) is showing the certificate as having expired 29/09/2021 20:21:40 GMT+1 (BST).

Is this to do with this:? Certificate Compatibility - Let's Encrypt

extract:

"root certificate used by Let’s Encrypt to sign client certificates will lose its validity on this day (expiry of Intermediate R3 on 2021/09/29 at 19:21:40 GMT – the DST Root CA X3 expires on 2021/09/30 14:01:15 GMT)"

This is exactly the same date / time as the expiry date reported in the errors I get.

Can anyone suggest how I can fix this? It's displaying an error pop up on my phone every 30 seconds or so, which is really annoying. :smiley:

UPDATE - looking at other tickets someone suggested running these commands, but I'm not sure what it is telling me (I had someone else set up SSL for me...)

openssl x509 -noout -dates -in /etc/letsencrypt/live/tenjinconsulting.co.uk/chain.pem
notBefore=Sep 4 00:00:00 2020 GMT
notAfter=Sep 15 16:00:00 2025 GMT

openssl x509 -noout -dates -in /etc/letsencrypt/live/tenjinconsulting.co.uk/fullchain.pem
notBefore=Aug 31 18:43:52 2021 GMT
notAfter=Nov 29 18:43:51 2021 GMT

I have also, as suggest in another thread, updated /etc/apache2/sites-available/tenjinconsulting.co.uk to reference the fullchain.pem file instead of just chain.pem, and remove the ChainFile key:

SSLCertificateFile /etc/letsencrypt/live/tenjinconsulting.co.uk/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/tenjinconsulting.co.uk/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/tenjinconsulting.co.uk/fullchain.pem

  • becomes:

SSLCertificateFile /etc/letsencrypt/live/tenjinconsulting.co.uk/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/tenjinconsulting.co.uk/privkey.pem

This has removed "chain errors" as reported by SSLLabs checker.

Any ideas would be very much appreciated!

Darren.

1 Like
2

This is complete nonsense.

This is good configuration :+1: :

This should have resolved your issues?

3

Any ideas... on what?
Are there any more problems?

4

Hi,

Thanks for the reply.

What I'm seeing is this:

If access my domain via Firefox on Mac OS X 11.5.2 the site works fine, and checking the SSL certificate it all looks good.

If access my email from the same Mac (mail server and web server run on the same remote Ubuntu server) I get errors saying that the SSL certificate has expired.

Trying to access my email on my iOS devices also throws the same "certificate expired" message.

Running a check on SSLLabs shows this in the "certification paths" section:

Capto_Capture 2021-09-30_03-52-20_pm
Capto_Capture 2021-09-30_03-52-20_pm960×856 117 KB

While I'm a developer, I have little experience with the server side (someone else set this up for me originally, and I am now having to dig in to try to fix this problem)

Thanks again,

Darren.

1 Like
5

SSL Labs checks on port 443 ONLY
Which port(s) does the email run on?

6

Hi,

Mail runs on the following ports:

IMAPS is 21199
POP3S is 20099

What does the "in trust store" entry saying "EXPIRED" mean in the log above?

Thanks

7 
openssl s_client tenjinconsulting.co.uk:21199
CONNECTED(00000003)
depth=0 CN = server.tenjinconsulting.co.uk
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = server.tenjinconsulting.co.uk
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = server.tenjinconsulting.co.uk
verify return:1
---
Certificate chain
 0 s:CN = server.tenjinconsulting.co.uk
   i:C = US, O = Let's Encrypt, CN = R3
---

it's missing intermediate certificates entirely use fullchain.pem in ssl_cert = </etc/ssl/certs/dovecot.pem paremeter

2 Likes
8

That means that your server is sending that cert - which is already in the trust store (not good).
And that cert is actually already expired (also not good - unless you are an old Android device).

9

no it didn't sent by server - just meaning last intermediate server sent will point to that

1 Like
10

How do I stop it sending that one, and start sending the right one?

My word, now I know how all the people whose computers I fix feel when they are asking me what look like simple questions to them but I know have complex answers. :rofl:

1 Like
11

The web server seems correct (or as correct as it can be today).
The problem is with your email system - it isn't using the chain at all.

12

Thanks, parameter in which file?

13

/etc/dovecut/conf.d/10-ssl? or /etc/dovecut/dovcut.conf?
whereever your dovecut config is

1 Like
14

Thanks, it's set to to that already I think?:

10-ssl.conf:ssl_cert = < /etc/letsencrypt/live/tenjinconsulting.co.uk/fullchain.pem

1 Like
15

Looking further, local.conf in /etc/dovecot has the following lines. Does this make any difference?:

ssl_cert = </etc/letsencrypt/live/tenjinconsulting.co.uk/cert.pem
ssl_key = </etc/letsencrypt/live/tenjinconsulting.co.uk/privkey.pem

16

ya cert.pem doesn't have any intermediates

1 Like
17

Change cert.pem to fullchain.pem and reload Dovecot.

Is there also a SMTP service running somewhere? Ah yes, SMTP with STARTTLS on port 25 also misses the intermediate certificate. Please also update and reload your SMTP service.

18

Thanks everyone, I'll try those and report back. :+1:

19

Thanks for your help everyone, it looks like this is now fixed.

Moving all references to "cert.pem" to "fullchain.pem" seems to have fixed it.

Thanks again!

Darren.

20

I'm facing the similar issue on chrome browser while accessing my website where as it works fine on Mozilla Firefox. Can you please let us know if there is any possible workaround to mitigate this issue.

Google Chrome 94.0.4606.71 (Official Build) (64-bit) (cohort: Stable Installs & Full Version Pins)
Revision 1d32b169326531e600d836bd395efc1b53d0f6ef-refs/branch-heads/4606@{#1256}
OS Windows 7 Service Pack 1 (Build 7601)
JavaScript V8 9.4.146.18
User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36
Command Line C:\Program Files\Google\Chrome\Application\chrome.exe --from-installer --flag-switches-begin --flag-switches-end
Executable Path C:\Program Files\Google\Chrome\Application\chrome.exe

Windows Information:
Operating System: Windows 7 Professional 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.130828-1532)

Regards,
SSA