New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with email verification on self hosted mail server and others public hosted mailserver #451
Comments
Maybe you need to add the Lets Encrypt CA to ./bwdata/ca-certificates? |
Hi, I have already copy all Lets Encrypt CA to ./bwdata/ca-certificates everything from docker host plus lets encrypt CA. Any ideas? Please see also my post here: https://community.bitwarden.com/t/bitwarden-e-mail-to-localhost-mailserver/4894 So I would like to use the external mail server but this server have lets encrypt and I have the error you see below here in the log file. How did you solve this issue on your hosted Bitwarden? Regards, Oliver |
Any ideas what I can do? I would like to buy Premium Plan and Familie Plan for 5 Persons but only if I can use the mail function without problem. Many users have problems. What I can do? Its only a little thing maybe? |
Can you ping your SMTP server from within the bitwarden-api container? Does another mail server, like Gmail or SendGrid work? |
System.Net.Mail.SmtpException: Failure sending mail. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure. But why? Letencrypt is valid certification and no other programs have problems with it.
I can see that the ./bitwarden start delete docker default_network card. I have also two docker network cards. docker0, this network card have always the same static ip no changes after reboot, start or rebuild br-29a2b1f877c5, this network card changed every reboot, start or rebuild, the network card have than another name e.g. br-xxxxx and other IPs / network. Every rebuild, reboot or start +1 the IP range from this network card. (I tested it several times). My problem is that I can not allow relay the docker containers via postfix on docker host because IP is always changing. Regards, Oliver |
I am thinking this has something to do with the broken SMTP library that we've been using. For whatever reason it doesn't like the Lets Encrypt CA cert. Our next version is using a newer SMTP library which might fix this. |
Okay and what is the workaround? At the moment I can't register users on my bitwarden installation. I would like to buy your premium package but not if simple SMTP send is not working... What is about my 2. question, why are the IPs / hole IP range is changed after ./bitwarden stop and ./bitwarden start or ./bitwarden restart? If I can set this IPs fix I can relay mails via my own server without any problems. But at the moment every restart the IPs / hole IP range from docker containers are changed. So I can't relay over my local mail server after reboot because containers have new IPs that are not permitted to send via local mail server. And one more question, I have seen that the timezone in docker containers are not right, how can I change it? Can I change it with docker-compose.override.yml? Which parameters? Maybe I can fix the IP problem also with the file docker-compose.override.yml but how? Many Thanks!! |
Is there a workaround now? I can't log in because of 2-factor email authentication. |
1.30.0 is now available with the new SMTP lib. Give it a try? |
Same problem with 1.30.0.
|
If you want to ignore the untrusted certificate failure and blindly trust the server (not recommended) you can now set the following in >= 1.30.0 in
Then restart with |
With Thank you. |
Thanks for update this issue! |
So I guess there is no way to avoid blindly trusting the server? Definiteley not a friend of that. I am having the same problem. I copied the ISRG Root X1 (current Let's Encrypt root cert) and DST Root X3 certs into bwdata/ca-certificates, but I don't think that is the problem as I start getting these messages on rebuild and update:
The certificate my SMTP server is using is valid of course (none of my applications are complaining and https://www.checktls.com/ shows no errors). |
@ArisenDrake It seems to be a problem with the .NET Core runtime on Linux. Supposedly they have some fixes coming in v3 which we'll eventually upgrade to. |
Try to relay local. Local mail server will relay to your right mail server with letsencrypt ca. |
Can confirm this on Ubuntu 18.04.2 clean install with just Bitwarden running on port 8443 using the LE option when setting it up (chaning ports in the config) - using SMPT2GO as a relay. Don't have so much logs to speak about (none) since I don't have full access to the server. |
This is still broken:
Blindly trusting any server is not a good solution, so if .NET Core 3 fixes this updating would be really nice. //edit: To clarify: I'm trying to send mail directly via Port 25 and SMTP+STARTTLS. There is no user for mail sending configured (and it is not required). Even |
I'm seeing the same thing, the strange thing is that this used to work. The recent update to 1.30.1 seems to have broken it. Unfortunately I don't know what the previous version was, but I believe 1.28.something. |
Tried again today, still doesn't work with 1.30.1:
This is the configuration:
The docker container, certificates and mail server are OK:
I reckon that there is a issue with STARTTLS. I tried to look at a pcap of the container when sending a mail but instead of sending the starttls command and upgrading the connection to a secure one, suddenly weird data is sent. This would also explain the error message, "The handshake failed due to an unexpected packet format". Disabling SSL works, but is obviously no solution. Disabling certificate validation also doesn't work (and would not be a solution either). |
I am confused. Your configuration is using port 25 with SSL disabled... ? |
Sorry, Copy & Paste error. It was enabled when I tried everything and crafted the log information. I disabled SSL afterwards so users are not interrupted. Seems like I copied the configuration with disabled SSL, sorry. |
So your config is...
? |
I've glanced at the BW code and at https://github.com/jstedfast/MailKit/blob/e9dee7febf94b1e75b0db070e02c9b61115a830f/MailKit/Net/Smtp/SmtpClient.cs a bit (I hope that's the right MailKit). It seems to me (not being a C# programmer) that we're holding it wrong. SMTP has three basic modes:
SMTPS is very rare, if people talk about SMTP and SSL they almost always mean STARTTLS. MailKit supports all of those, and which one it uses depends on a rather complicated decision tree based on the parameters passed into ConnectAsync. It looks at the port number and the third parameter, SecureSocketOptions. BW just passes in a boolean (True or False) for SecureSocketOptions, and that does not do what one think it does, if I read the code correctly. https://github.com/jstedfast/MailKit/blob/e9dee7febf94b1e75b0db070e02c9b61115a830f/MailKit/Net/Smtp/SmtpClient.cs#L872 is what's making the decision on whether to use plain SMTP, SMTPS or STARTTLS, and when SecureSocketOptions is a boolean we hit the default branch for both switch statements, and end up with STARTTLS disabled. If BW wants to support only STARTTLS and not SMTPS then passing in SecureSocketOptions.StartTls instead of a boolean should work, and no new config options would be required. If BW wants to support both SMTPS and STARTTLS there needs to be a config option that will let users chose. |
Yes. This worked in previous versions with STARTTLS on port 25 and is as far as I know widely used. See the OpenSSL command provided that connects to port 25 and establishes a TLS connection afterwards. Thanks @Lalufu for your answer, I think there are some misconceptions here regarding transport encryption and SMTP and your explanation is excellent and on point. |
Currently, we use the following logic:
It seems we need to add some other override to allow a user to use StartTLS on port 25. The correct configuration for you would be:
But we need to find a solution to overcome no. 1 logic hole. |
I added a possible fix in 5cc0b19 . You can now provide So you would use:
You can try this out in the dev tags on DockerHub if you like. Edit |
Thanks, I'll test it within the next week. |
@kspearrin Your fix works, thanks a lot! I see the STARTTLS command in tshark and the rest of the connection runs encrypted with TLSv1.2. I received the mail for my admin login, so everything is fine. It would be nice to have this in the stable branch and documented. Also, the admin page may also be extended by a flag indicating that STARTTLS is used: |
This works well for my configuration. api and admin
|
above fix are there any updates on this? |
Same here. No solution is known. Could anyone help, please? Thanks. |
Its already fixed with latest bitwarden version duebto newer dot net. At least for me with my LE cert. |
It seems not to, as I'm running Bitwarden 1.33.1. |
Since 1.33 its working with LE on my server. Without trustServer=true |
This is my config:
And I have "less secure apps" turned "on", at google. Thanks. |
@Commifreak Please post your config. It would be useful to others. Thanks! |
If it helps. Ill post it later this day. But its the default one. I just added the trustServer attribute then and removed it again since bw is using latest dotnet. |
I'm facing this as well on 1.33.1 running in docker and I keep getting a handshake failure.
I can also connect from within the API container just fine, so I'm pretty sure the CA cert was installed correctly and is trusted.
My config looks like:
It sends an email after I add |
Hi,
I tried to connect to my local server and other public servers. I used lets encrypt on my own system. Passwort is correct and I can send emails with e.g. Thunderbird.
My logs shows:
System.Net.Mail.SmtpException: Failure sending mail. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
What is the problem? Did Bitwarden really have problems with lets encrypt?
Regards,
Oliver
The text was updated successfully, but these errors were encountered: