-
Notifications
You must be signed in to change notification settings - Fork 31
Option to trust self-signed certificates #30
Comments
Is your SMTP server using TLS, but with a self-signed certificate? |
Yes. Its a local postfix instance used as a relay. It does have a 'openssl' generated cert that is self signed. Initially the error was as follows 2022-05-25T09:32:46.025029473Z [ERROR] failed to send user verification to 'xxxx@xxxxxx.com': x509: certificate relies on legacy Common Name field, use SANs instead After the certificate was regenerated with the missing bits the error changed and now 'unknown' authority is the issue. 2022-05-25T10:11:07.18150931Z [ERROR] failed to send user verification to 'xxxx@xxxxxx.com': x509: certificate signed by unknown authority This error is not a big issue but it would indicate that even if I manage to disable verification / activation it would be encountered while sending actual emails. |
Agreed! Will add this soon. |
Thank you. In the meantime. Is there a way to disable activation / verification. Account activation required: true In my config.yml have this set to 'false' but the app seams to ignore these settings. |
Environment variables override config variables and the Docker image has some set by default ( Lines 29 to 41 in 065f29f
-e with docker run ) things should work as expected.
|
Thank you for the advice. That worked perfectly. |
Please check if my recent changes fit your needs. |
Yes. Have rebuild the container image. Still receiving an error but it is unrelated. Simply the local relay is locked down via IP whitelists and provides no authentication. [ERROR] failed to send user verification to 'xxxx@xxxxxx.com': smtp: server doesn't support AUTH So if I enable AUTH that should work now. As there is no issue with the self signed certificate. Unless there is an option to disable authentication attempts from the APP itself. |
Good point, I created a new issue and will hopefully get to it soon. |
Awesome, thank you. Did not expect any work but appreciate as it would be useful. Got the notification of the ticket created so can test whenever the future gets included. I'm using this app for InfluxDB v2 as somehow it only works with HTTP APIs and does not have direct configuration for SMTP |
Hi,
Would there be a way to prevent TLS/SSL certificate verification.
Seams that changes to the config.yml are not working.
Have set the following:
security:
pepper: '123456'
allow_signup: true
verify_users: false
verify_senders: false
But the system still attempts to send the verification email that subsequently fails due to the SMTP relay using a self signed certificate.
± |master ✓| → docker logs mailwhale
2022-05-25T10:09:57.380930606Z [INFO ] ---
2022-05-25T10:09:57.380955667Z [INFO ] This instance is assumed to be publicly accessible at: http://localhost:3000
2022-05-25T10:09:57.380958788Z [INFO ] User registration enabled: true
2022-05-25T10:09:57.380960534Z [INFO ] Account activation required: true
2022-05-25T10:09:57.380962025Z [INFO ] Sender address verification required: true
2022-05-25T10:09:57.380963458Z [INFO ] ---
2022-05-25T10:09:57.382765931Z [INFO ] web server started, listening on 0.0.0.0:3000
.
.
.
2022-05-25T10:10:45.912522437Z [INFO ] created user 'xxxx@xxxxxxxxxx.com'
2022-05-25T10:10:45.912593829Z [INFO ] [request] status=201, method=POST, uri=/api/user, duration=92.273016ms, bytes=119, addr=172.17.0.1:51922
2022-05-25T10:10:45.934366226Z [INFO ] [request] status=200, method=GET, uri=/login, duration=106.7µs, bytes=533, addr=172.17.0.1:51922
2022-05-25T10:10:46.124002533Z [INFO ] [request] status=304, method=GET, uri=/build/bundle.css, duration=58.916µs, bytes=0, addr=172.17.0.1:51922
2022-05-25T10:10:46.124411257Z [INFO ] [request] status=304, method=GET, uri=/build/bundle.js, duration=59.983µs, bytes=0, addr=172.17.0.1:51924
2022-05-25T10:11:07.18150931Z [ERROR] failed to send user verification to 'xxxx@xxxxxxxxxx.com': x509: certificate signed by unknown authority
Please advise if a way exists to disable that check or to trust that certificate or a method to disable the activation / verification requirements.
The text was updated successfully, but these errors were encountered: