Expired DST Root CA X3 certificat and connexion problems

Help
1

Hello,

I have a Vaultwarden installed on a raspberry since a few years and accessing it from the internet. Everything was working correctly until the DST Root CA X3 was expired on 30 September.

I used “sudo certbot renew” and received an new certificat but it still doesn’t work with Bitwarden iOS and Mac Client. The error is “There was an SSL error and it is impossible to establish a secure connexion with the server”.

I can access my server with my browser (Safari) if I accept to connect without security… but not via client apps.

How can I replace the old certificat by the new one “ISRG Root X1” ? Or should I wait for a Bitwarden Client update ?
Thanks in advance

P.S. forget to mention that I have latest Vaultwarden 2.21.1 on Arch Linux server

2

This has nothing to do with Vaultwarden. Your certificate still serves the DST cert which the clients do not except.

Best thing to do is to force generate a new cert with the new chain
With the latest version of certbot you should be able to do it like this.

certbot renew --force-renewal --preferred-chain "ISRG Root X1"
3

Hello,
Thanks very much.

I did what you suggested and now it is working on a few devices but strangely not all of them. For instance, I have a Mac and an iPhone on which the old certificate is still used…

Apparently, there is a certificate cache problem on certain client machine:

See for example here

Some operating systems hold onto the expired R3 > DST Root CA X3 chain even if your server is no longer using it. Try a restart of the affected client device.

Restarting, resetting network settings didn’t help on my devices.

And also here

So how come two different Macs connecting to the same site get such different chains of trust?
The answer I suspect lies in the caching of certificate checks. Both my iMac and iPhone have connected to this site previously, and rather than performing a full certificate check every time, macOS is just using old results, which still refer to the old intermediate and Root certificates. My M1 Mac mini had never connected to that site, so had to perform a fresh check on the chain of trust, which then traced back to the current chain with its replaced intermediate and Root certificates.

What can you do about this more generally, to save you from having to make each broken site an exception? As far as I know, nothing that you’d want to. Emptying Safari’s caches doesn’t help, as I think the old certificate information is held in a separate security database to which the user has no access. Unless you know better.

So it is not a “Vaultwarden problem” but I will still come back if someone finds a solution in case other people have this problem…

4

Hello,

Just in case, the solution was to use “fullchain.pem” and not “certs.pem” in the ROCKET_TLS environnement variable

NOT

ROCKET_TLS={certs=“/path/to/certs.pem”,key=“/path/to/key.pem”}

BUT

ROCKET_TLS={certs=“/path/to/fullchain.pem”,key=“/path/to/key.pem”}

Hope this helps ! Glad that everything is working great again !

5

A small note, you always need to use the full chain with every type of certificate. Same goes for server software like nginx or caddy or Apache httpd etc…