bitwarden cannot use configured email server because the cert received, from the mail server, is not trusted. Adding ability to install respective root/subordinate CA's will allow bitwarden to trust the cert
Your environment
Bitwarden_rs version: 1.15.1-b34d5482
Install method: docker compose sourcing image at bitwardenrs/server:latest
Originally created by @causalityloop on GitHub (Jul 5, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1045
### Subject of the issue
bitwarden cannot use configured email server because the cert received, from the mail server, is not trusted. Adding ability to install respective root/subordinate CA's will allow bitwarden to trust the cert
### Your environment
<!-- The version number, obtained from the logs or the admin page -->
* Bitwarden_rs version: 1.15.1-b34d5482
<!-- How the server was installed: Docker image / package / built from source -->
* Install method: docker compose sourcing image at bitwardenrs/server:latest
* Clients used: <!-- if applicable -->
* Reverse proxy and version: <!-- if applicable -->
* Version of mysql/postgresql: <!-- if applicable -->
* Other relevant information:
### Steps to reproduce
<!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults)
and how did you start bitwarden_rs? -->
Used the following related smpt settings
```
extra_hosts:
- "mail.codeloft.tech:<email_server_ip>"
environment:
- SMTP_HOST=<email_server_ip>
- SMTP_FROM=<user>
- SMTP_PORT=565
- SMTP_SSL=true
- SMTP_EXPLICIT_TLS=true
- SMTP_USERNAME=<user>
- SMTP_PASSWORD=<password>
```
### Expected behaviour
<!-- Tell us what should happen -->
Emails are delivered
### Actual behaviour
<!-- Tell us what happens instead -->
Emails are not delivered.
### Relevant logs
<!-- Share some logfiles, screenshots or output of relevant programs with us. -->
The bitwarden log contains:
```
bitwardenrs | [2020-07-05 12:51:08][bitwarden_rs::api::core::accounts][ERROR] Error sending welcome email: SmtpError.
bitwardenrs | [CAUSE] Io(
bitwardenrs | Custom {
bitwardenrs | kind: Other,
bitwardenrs | error: Failure(
bitwardenrs | Ssl(
bitwardenrs | Error {
bitwardenrs | code: ErrorCode(
bitwardenrs | 1,
bitwardenrs | ),
bitwardenrs | cause: Some(
bitwardenrs | Ssl(
bitwardenrs | ErrorStack(
bitwardenrs | [
bitwardenrs | Error {
bitwardenrs | code: 337047686,
bitwardenrs | library: "SSL routines",
bitwardenrs | function: "tls_process_server_certificate",
bitwardenrs | reason: "certificate verify failed",
bitwardenrs | file: "../ssl/statem/statem_clnt.c",
bitwardenrs | line: 1915,
bitwardenrs | },
bitwardenrs | ],
bitwardenrs | ),
bitwardenrs | ),
bitwardenrs | ),
bitwardenrs | },
bitwardenrs | X509VerifyResult {
bitwardenrs | code: 20,
bitwardenrs | error: "unable to get local issuer certificate",
bitwardenrs | },
bitwardenrs | ),
bitwardenrs | ),
bitwardenrs | },
bitwardenrs | )
bitwardenrs | [2020-07-05 12:51:08][response][INFO] POST /api/accounts/register (register) => 200 OK
```
Or you can make sure the docker host has the CA installed correctly and do a read-only mount the /etc/ssl/certs folder within docker by using -v /etc/ssl/certs:/etc/ssl/certs:ro this should include all the ca certs your host allows within the docker container.
And you probably need to mount the following also as a read only: -v /usr/share/ca-certificates/mozilla:/usr/share/ca-certificates/mozilla:ro
<!-- gh-comment-id:674533020 -->
@BlackDex commented on GitHub (Aug 16, 2020):
You can try to add the CA cert your self by using the startup script @jjlin created: https://github.com/dani-garcia/bitwarden_rs/wiki/Starting-a-Container#customizing-container-startup
Or you can make sure the docker host has the CA installed correctly and do a read-only mount the `/etc/ssl/certs` folder within docker by using `-v /etc/ssl/certs:/etc/ssl/certs:ro` this should include all the ca certs your host allows within the docker container.
And you probably need to mount the following also as a read only:
`-v /usr/share/ca-certificates/mozilla:/usr/share/ca-certificates/mozilla:ro`
@causalityloop, do you have this issue fixed?
I'm thinking of implementing an option to ignore the certificate when needed in cases like this. If have to wait a bit for the email library to release there new (beta) version which should have this included.
<!-- gh-comment-id:706436262 -->
@BlackDex commented on GitHub (Oct 9, 2020):
@causalityloop, do you have this issue fixed?
I'm thinking of implementing an option to ignore the certificate when needed in cases like this. If have to wait a bit for the email library to release there new (beta) version which should have this included.
@causalityloop commented on GitHub (Oct 10, 2020):
Yes, thank you for reaching out. I will close this. I had a pr against this issue that fixed my specific use case (1046) and @jjlin reached out with his idea (1048). After looking at the code deeper, it looked like I could just place a script in /etc/bitwarden_rs.d/ and it would execute. I use this image in a k8s cluster and this is what I did. I loaded the certs and the startup script as config maps and placed the script in /etc/bitwarden_rs.d/ and I have it import the CA certs on create
<!-- gh-comment-id:706457617 -->
@causalityloop commented on GitHub (Oct 10, 2020):
Yes, thank you for reaching out. I will close this. I had a pr against this issue that fixed my specific use case (1046) and @jjlin reached out with his idea (1048). After looking at the code deeper, it looked like I could just place a script in /etc/bitwarden_rs.d/ and it would execute. I use this image in a k8s cluster and this is what I did. I loaded the certs and the startup script as config maps and placed the script in /etc/bitwarden_rs.d/ and I have it import the CA certs on create
```
kind: ConfigMap
apiVersion: v1
metadata:
name: startup-script
namespace: bitwarden
data:
bitwarden_rs.sh: |-
#!/usr/bin/env sh
echo "running startup commands..."
echo "update-ca-certificates"
update-ca-certificates
```
@causalityloop, do you have this issue fixed? I'm thinking of implementing an option to ignore the certificate when needed in cases like this. If have to wait a bit for the email library to release there new (beta) version which should have this included.
After almost four years, is there any ability to ignore the certificate ? I'm also in this scenario with SMTP server with self-signed certificate. Thanks @BlackDex
<!-- gh-comment-id:1897965322 -->
@ch4r13 commented on GitHub (Jan 18, 2024):
> @causalityloop, do you have this issue fixed? I'm thinking of implementing an option to ignore the certificate when needed in cases like this. If have to wait a bit for the email library to release there new (beta) version which should have this included.
After almost four years, is there any ability to ignore the certificate ? I'm also in this scenario with SMTP server with self-signed certificate. Thanks @BlackDex
<!-- gh-comment-id:1897978875 -->
@BlackDex commented on GitHub (Jan 18, 2024):
@TasyDevilsky that is already implemented for about 3 years or so.
See: https://github.com/dani-garcia/vaultwarden/blob/890e668071cffe2833834348e19bbef3c061d014/.env.template#L448-L457
Many thanks ! especially for very fast response !
Thank you ❤️
<!-- gh-comment-id:1898000786 -->
@ch4r13 commented on GitHub (Jan 18, 2024):
> @TasyDevilsky that is already implemented for about 3 years or so. See:
>
> https://github.com/dani-garcia/vaultwarden/blob/890e668071cffe2833834348e19bbef3c061d014/.env.template#L448-L457
Many thanks ! especially for very fast response !
Thank you ❤️
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @causalityloop on GitHub (Jul 5, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1045
Subject of the issue
bitwarden cannot use configured email server because the cert received, from the mail server, is not trusted. Adding ability to install respective root/subordinate CA's will allow bitwarden to trust the cert
Your environment
Steps to reproduce
Used the following related smpt settings
Expected behaviour
Emails are delivered
Actual behaviour
Emails are not delivered.
Relevant logs
The bitwarden log contains:
@BlackDex commented on GitHub (Aug 16, 2020):
You can try to add the CA cert your self by using the startup script @jjlin created: https://github.com/dani-garcia/bitwarden_rs/wiki/Starting-a-Container#customizing-container-startup
Or you can make sure the docker host has the CA installed correctly and do a read-only mount the
/etc/ssl/certsfolder within docker by using-v /etc/ssl/certs:/etc/ssl/certs:rothis should include all the ca certs your host allows within the docker container.And you probably need to mount the following also as a read only:
-v /usr/share/ca-certificates/mozilla:/usr/share/ca-certificates/mozilla:ro@BlackDex commented on GitHub (Oct 9, 2020):
@causalityloop, do you have this issue fixed?
I'm thinking of implementing an option to ignore the certificate when needed in cases like this. If have to wait a bit for the email library to release there new (beta) version which should have this included.
@causalityloop commented on GitHub (Oct 10, 2020):
Yes, thank you for reaching out. I will close this. I had a pr against this issue that fixed my specific use case (1046) and @jjlin reached out with his idea (1048). After looking at the code deeper, it looked like I could just place a script in /etc/bitwarden_rs.d/ and it would execute. I use this image in a k8s cluster and this is what I did. I loaded the certs and the startup script as config maps and placed the script in /etc/bitwarden_rs.d/ and I have it import the CA certs on create
@ch4r13 commented on GitHub (Jan 18, 2024):
After almost four years, is there any ability to ignore the certificate ? I'm also in this scenario with SMTP server with self-signed certificate. Thanks @BlackDex
@BlackDex commented on GitHub (Jan 18, 2024):
@TasyDevilsky that is already implemented for about 3 years or so.
See: https://github.com/dani-garcia/vaultwarden/blob/890e668071cffe2833834348e19bbef3c061d014/.env.template#L448-L457
@ch4r13 commented on GitHub (Jan 18, 2024):
Many thanks ! especially for very fast response !
Thank you ❤️