E-mail sending does not work if server (postfix) uses ECDSA certificate about healthchecks HOT 7 CLOSED

Awesome, mystery solved :-)

EMAIL_USE_VERIFICATION controls whether Healthchecks sends an email with a confirmation link when adding an email integration. (See https://healthchecks.io/docs/self_hosted_configuration/#EMAIL_USE_VERIFICATION)

from healthchecks.

To help me reproduce the issue – are you using LetsEncrypt-issued certificates?

from healthchecks.

To help me reproduce the issue – are you using LetsEncrypt-issued certificates?

Yes. With the following config:

text = True
non-interactive = True
webroot-path = /data/letsencrypt-acme-challenge
key-type = ecdsa
elliptic-curve = secp384r1
preferred-chain = ISRG Root X1

from healthchecks.

I haven't had luck reproducing this yet.

I found a random mail server on shodan that listens on port 587 (STARTTLS) and seems to be using ECC certificate.

I started a throwaway Healthchecks instance like so:

docker run --rm \
  --name=healthchecks \
  -p 8000:8000 \
  -e ALLOWED_HOSTS=localhost \
  -e DB=sqlite \
  -e DB_NAME=/data/hc.sqlite \
  -e DEBUG=False \
  -e DEFAULT_FROM_EMAIL=fixme-email-address-here \
  -e EMAIL_HOST=random-mailservers-hostname-here.com \
  -e EMAIL_HOST_PASSWORD=foo \
  -e EMAIL_HOST_USER=bar \
  -e EMAIL_PORT=587 \
  -e EMAIL_USE_TLS=True \
  -e SECRET_KEY=--- \
  -e SITE_ROOT=http://localhost:8000 \
  -v healthchecks-data:/data \
healthchecks/healthchecks:v2.10

In the web UI, I submitted the "Create Account" form which should trigger an outgoing email. The error I got was:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
    self.run()
  File "/opt/healthchecks/hc/lib/emails.py", line 25, in run
    self.message.send()
  File "/usr/local/lib/python3.11/site-packages/django/core/mail/message.py", line 298, in send
    return self.get_connection(fail_silently).send_messages([self])
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/mail/backends/smtp.py", line 127, in send_messages
    new_conn_created = self.open()
                       ^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/django/core/mail/backends/smtp.py", line 94, in open
    self.connection.login(self.username, self.password)
  File "/usr/local/lib/python3.11/smtplib.py", line 750, in login
    raise last_exception
  File "/usr/local/lib/python3.11/smtplib.py", line 739, in login
    (code, resp) = self.auth(
                   ^^^^^^^^^^
  File "/usr/local/lib/python3.11/smtplib.py", line 662, in auth
    raise SMTPAuthenticationError(code, resp)
smtplib.SMTPAuthenticationError: (535, b'Incorrect authentication data')

From the error message it looks like it got past the TLS handshake, but the SMTP credentials were wrong – which makes sense.

Can you point me to a publicly available mail server that I can test with (don't need username/password, just the hostname), or provide instructions to reproduce the issue in some other form?

from healthchecks.

You can use the following:

EMAIL_HOST=mail.tal-deloitte.de
EMAIL_HOST_PASSWORD=xxx
[email protected]
EMAIL_PORT=587
EMAIL_USE_SSL=False
EMAIL_USE_TLS=True
EMAIL_USE_VERIFICATION=True

from healthchecks.

Please apologize. You are right. The correct certificate was not presented.

How to use your own certificate
Make sure you disable mailcows internal LE client (see above).
To use your own certificates, just save the combined certificate (containing the certificate and intermediate CA/CA if any) to data/assets/ssl/cert.pem and the corresponding key to data/assets/ssl/key.pem.

I did not follow the whole instruction of the mail server.

A last question: Setting EMAIL_USE_VERIFICATION to False did not work as well. Should this option not disable the certificate check?

from healthchecks.

Thank you again and I want to apologize for stealing your time.
Of course the deployment of the correct full chain certificate is already fixed.
At the moment I am investigating, why other web services did not alarm in this configuration.

from healthchecks.