certificate verify failed for smtp

[jief666]

Hi,
I'm running vaultwarden 1.32.7 on debian 12 (not in docker, I've extracted the binary).
I can only get smtp to work if I accept invalid cert. I'm using a self hosted postfix smtp server on that same computer.
Needless to say that email works perfectly. Certificates are not expired. Accessing vaultwarden web vault works.

I don't understand why I got :

janv. 13 21:36:08 debian12 vaultwarden[1180098]: [2025-01-13 21:36:08.644][vaultwarden::mail][DEBUG] SMTP error: lettre::transport::smtp::Error {
janv. 13 21:36:08 debian12 vaultwarden[1180098]: kind: Connection,
janv. 13 21:36:08 debian12 vaultwarden[1180098]: source: lettre::transport::smtp::Error {
janv. 13 21:36:08 debian12 vaultwarden[1180098]: kind: Connection,
janv. 13 21:36:08 debian12 vaultwarden[1180098]: source: Ssl(
janv. 13 21:36:08 debian12 vaultwarden[1180098]: Error {
janv. 13 21:36:08 debian12 vaultwarden[1180098]: code: ErrorCode(
janv. 13 21:36:08 debian12 vaultwarden[1180098]: 1,
janv. 13 21:36:08 debian12 vaultwarden[1180098]: ),
janv. 13 21:36:08 debian12 vaultwarden[1180098]: cause: Some(
janv. 13 21:36:08 debian12 vaultwarden[1180098]: Ssl(
janv. 13 21:36:08 debian12 vaultwarden[1180098]: ErrorStack(
janv. 13 21:36:08 debian12 vaultwarden[1180098]: [
janv. 13 21:36:08 debian12 vaultwarden[1180098]: Error {
janv. 13 21:36:08 debian12 vaultwarden[1180098]: code: 167772294,
janv. 13 21:36:08 debian12 vaultwarden[1180098]: library: "SSL routines",
janv. 13 21:36:08 debian12 vaultwarden[1180098]: function: "tls_post_process_server_certificate",
janv. 13 21:36:08 debian12 vaultwarden[1180098]: reason: "certificate verify failed",
janv. 13 21:36:08 debian12 vaultwarden[1180098]: file: "ssl/statem/statem_clnt.c",
janv. 13 21:36:08 debian12 vaultwarden[1180098]: line: 1889,
janv. 13 21:36:08 debian12 vaultwarden[1180098]: },
janv. 13 21:36:08 debian12 vaultwarden[1180098]: ],
janv. 13 21:36:08 debian12 vaultwarden[1180098]: ),
janv. 13 21:36:08 debian12 vaultwarden[1180098]: ),
janv. 13 21:36:08 debian12 vaultwarden[1180098]: ),
janv. 13 21:36:08 debian12 vaultwarden[1180098]: },
janv. 13 21:36:08 debian12 vaultwarden[1180098]: X509VerifyResult {
janv. 13 21:36:08 debian12 vaultwarden[1180098]: code: 20,
janv. 13 21:36:08 debian12 vaultwarden[1180098]: error: "unable to get local issuer certificate",
janv. 13 21:36:08 debian12 vaultwarden[1180098]: },
janv. 13 21:36:08 debian12 vaultwarden[1180098]: ),
janv. 13 21:36:08 debian12 vaultwarden[1180098]: },
janv. 13 21:36:08 debian12 vaultwarden[1180098]: }

Anyone got any idea on how to debug this ? Can I have more debug message from vaultwarden, or from ssl ?

Thanks.

[kpfleming]

Verification of server's certificate will fail if there is no already-trusted Certificate Authority root certificate for it. How did you create/obtain the certificate that is being used by the Postfix server?

[jief666]

It's a Let's Encrypt certificate. And the root certificate ISRG_Root_X1.pem in installed in /etc/ssl/certs.

[jief666]

ISRG_Root_X1.pem is a link to /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt. Accessible and valid to June 4, 2035.

[jief666]

I must add that my certificate is issued by E5. The E5 let's encrypt certificate is issued by ISRG Root X1.
Not an expert. But it the browser seems to have no problem with it.

[jief666]

Does the vaultwarden process uses the same libraries as curl, for example?

[BlackDex]

It should. But you must make sure you provide the whole chain of certificates, not just the one specific for that domain.

Also, if you use localhost or something instead of the FQDN listed on the cert, this will happen.

[jief666]

If curl can do it, doesn't it mean that it has access to the whole chain of certificates ? I also tried an openssl command to check that certificate. Works too.
I use the qualified name, not localhost or 127.0.0.1
Any idea how can I debug that ?

[BlackDex]

Enable SMTP_DEBUG=true, that should provide more details

[jief666]

Completely miss that in the .env. Yet it was there. However it didn't give me much more.
But I got an idea and finally found that the smtp was returning the certificate without returning the intermediate certificate used to sign it (return fullchain.pem instead of cert.pem).
I changed that and then it worked.
Thanks.