SMTP: Lets Encrypt certificate cannot be verified

[Dennis14e]

Hello,
my mail server uses Let's Encrypt certificates. Bitwarden can not connect to this server because the certificate can not be validated, but the certificates are valid.
As a mail server, I use Mailu 1.5, the certificates are generated based on the "TLS_FLAVOR" setting "letsencrypt".

Docker version: 18.09.3
docker-compose version: 1.23.2
Bitwarden version: 1.30.0

Config:

globalSettings__mail__replyToEmail=noreply@MYDOMAIN.TLD
globalSettings__mail__smtp__host=mx1.MYDOMAIN.TLD
globalSettings__mail__smtp__port=465
globalSettings__mail__smtp__ssl=true
globalSettings__mail__smtp__username=MYUSERNAME
globalSettings__mail__smtp__password=MYPASSWORD

Log: https://pastebin.com/ysQAkBsw

[RedJohn14]

Have a look on my Issue:
#451

[alexzeitgeist]

Bitwarden version: 1.30.1
Docker version: 18.09.3, build 774a1f4

Doesn't work for me either. Has been working in the past, but now suddenly, it says "The SSL certificate presented by the server is not trusted by the system for one or more of the following reasons..." (valid Let's Encrypt certificates).

Setting that used to work in the past but doesn't work anymore:

globalSettings__mail__replyToEmail=no-reply@vault.hostname.com
globalSettings__mail__smtp__host=postfach.hostname.com
globalSettings__mail__smtp__port=587
globalSettings__mail__smtp__ssl=true
globalSettings__mail__smtp__username=relay@vault.hostname.com
globalSettings__mail__smtp__password=<secret>

Switching from SMTPS to STARTTLS as suggested in #451 still doesn't work, same "SSL certificate presented by the server is not trusted by the system" error:

globalSettings__mail__replyToEmail=no-reply@vault.hostname.com
globalSettings__mail__smtp__host=postfach.hostname.com
globalSettings__mail__smtp__port=587
globalSettings__mail__smtp__ssl=false
globalSettings__mail__smtp__username=relay@vault.hostname.com
globalSettings__mail__smtp__password=<secret>
globalSettings__mail__smtp__startTls=true

[kspearrin]

Try globalSettings__mail__smtp__trustServer=true

[alexzeitgeist]

Try globalSettings__mail__smtp__trustServer=true

Thanks. But I think this is a horrible workaround if it does what I assume it does. It would defeat the purpose of using TLS to prevent man in the middle attacks.

[kspearrin]

Yes, I understand. I am just trying to see if that makes the error go away or not.

[Don-Swanson]

I have the same issues, and I can confirm that the trustServer=true does get rid of the error, and resumes, normal email delivery, however as you agree, this should not be used in production. I tried updating to the dev channel (as suggested in #451 ) and adding the startTls=true setting, but it still doesn't work.

[kspearrin]

Seems like a duplicate of #451 , which seems related to a bug in .NET Core 2.x. We'll have to wait for the fix in .NET Core 3.

[alexzeitgeist]

Seems to be related to this bug: https://github.com/dotnet/corefx/issues/35035 and https://github.com/dotnet/corefx/issues/3034 and perhaps https://github.com/dotnet/corefx/issues/29064

Question: Could we include a flag to disable certificate revocation checking in SSLStream until upgrading to a fixed version of .net core? Sure it's not perfect, but it'd be still better than trusting any SSL certificate.

[davidus05]

Issue (for me) still existing. Are there any updates for this?

Workaround with
globalSettings__mail__smtp__trustServer=true
does work for me, but isn't really nice, as already mentioned above.

[Mart124]

.Net Core 3 has been released, 3.1.0 a few days ago.
May be worth a try.
Edit : just saw you are testing this on the master repo @kspearrin, good news, many thx 👍

[TheGorf]

Just to throw this in, I'm running 1.32 and this is still an issue for me. Hope the updates to .net fix it. For now I'm just running with the trust server workaround.

[AndrewSav]

@kspearrin .net core 3 has been out for a few months. Did it fix the issue?

[Mart124]

.Net Core 3 has been released, 3.1.0 a few days ago.
May be worth a try.
Edit : just saw you are testing this on the master repo @kspearrin, good news, many thx 👍

I confirm server 1.33.0 fixes this issue 👍
We then do not need globalSettings__mail__smtp__trustServer=true anymore.
Thank you !