Mailu: TLS_FLAVOR=mail makes letsencrypt certificates untrusted ?

Created on 4 Apr 2020  路  6Comments  路  Source: Mailu/Mailu

I have a reverse proxy to access HTTPS frontend.
The certificate is valid and CA cert is correct (valid letsencrypt certificate).
Using Mailu 1.7, I set TLS_FLAVOR=mail , and make /cert pointing to the same certificate than the reverse proxy.

Access to mailu HTTPS (webmail/admin) works fine through the rproxy, with a valid certificate.
The certificate provided by mailu for imap SSL (port 993) is the same (same fingerprint) certificate that the rproxy (port 443).

BUT the mailu imap SSL certificate is seen untrusted by mail clients (Trust anchor for certification path not found), whereas there is no pb with the rproxy certificate.
I doubled check with online tools which confirms the difference.

Any idea what could happen?

Most helpful comment

Mailu defaults is to use key.pem and cert.pem, but this can be changed.
Add TLS_CERT_FILENAME=fullchain.pem in your mailu.env, and it should be Ok.

All 6 comments

I guess that your certificate is using an intermediate certificate which is known by your browser, but not known by your mail clients. See 搂 "SSL certificate chains" in the nginx documentation

You could also look at the output of:
openssl s_client -connect mail.yourdomain.net:993
to check your chain of certificates

I don't think its a browser certificate. See openssl outputs for bot commands on ports 993 and 443:

openssl s_client -connect mail.yourdomain.net:993

CONNECTED(00000003)

Certificate chain
0 s:CN = mail.yourdomain.net

i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

Server certificate
-----BEGIN CERTIFICATE-----
MIIGVTCCBT2gAwIBAgISA+He2YjGCC3hrbXz0Dls4pbQMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDAzMTIxODI3NThaFw0y
<...>
-----END CERTIFICATE-----
subject=CN = mail.yourdomain.net

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3


No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS

Server Temp Key: X25519, 253 bits

SSL handshake has read 2359 bytes and written 399 bytes

Verification error: unable to verify the first certificate

New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 473C56F361955595EEB10779E67AC6DAEFCD3B5C9DB5D47D5BDB261C8C245E7A
Session-ID-ctx:
Master-Key: 6C8BDDDDE64BECB34E6581C1946494D9839CCB87081F6B432020D7693077D9BF65E850821E3320C577B40FE169F8B213
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1586067018
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)

Extended master secret: yes

  • OK IMAP4 ready

openssl s_client -connect mail.yourdomain.net:443

CONNECTED(00000003)

Certificate chain
0 s:CN = mail.yourdomain.net
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

i:O = Digital Signature Trust Co., CN = DST Root CA X3

Server certificate
-----BEGIN CERTIFICATE-----
MIIGVTCCBT2gAwIBAgISA+He2YjGCC3hrbXz0Dls4pbQMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDAzMTIxODI3NThaFw0y
<...>
-----END CERTIFICATE-----
subject=CN = mail.yourdomain.net

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3


No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS

Server Temp Key: X25519, 253 bits

SSL handshake has read 3620 bytes and written 386 bytes

Verification: OK

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server certificate
-----BEGIN CERTIFICATE-----
MIIGVTCCBT2gAwIBAgISA+He2YjGCC3hrbXz0Dls4pbQMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDAzMTIxODI3NThaFw0y
<...>
-----END CERTIFICATE-----
subject=CN = mail.yourdomain.net

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3


No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS

Server Temp Key: X25519, 253 bits

SSL handshake has read 3620 bytes and written 386 bytes

Verification: OK

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent

Verify return code: 0 (ok)

Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent

Verify return code: 0 (ok)

read:errno=0
HTTP/1.1 400 Bad Request
Server: nginx/1.17.5
Date: Sun, 05 Apr 2020 06:11:37 GMT
Content-Type: text/html
Content-Length: 157
Connection: close
Strict-Transport-Security: max-age=31536000


400 Bad Request

400 Bad Request



nginx/1.17.5

Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 70CD51ECD8793BC47E7ADD8AB6DC1C849E02ACDC8D4A4A605C8CB4A7F5D849FA
Session-ID-ctx:
Resumption PSK: 2E1DF8EDE744AEF76A07B1BC3E9CC100D5FCFA38C40A414313C4B13333C3FFBEA51196F917F6162B3AC809140CABD798
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - d5 7d e5 23 e5 c0 65 1a-82 6a 98 90 29 9e 06 66 .}.#..e..j..)..f
0010 - dc 1a b0 8f c1 e9 8d 54-79 ad 14 86 b3 02 1e b9 .......Ty.......

Start Time: 1586067073
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no

Max Early Data: 0

read R BLOCK

Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: BB340EA03BAF974BE0CED686A5B175B99A5E26ED7D6088800ABD5ECFC0C3F0DB
Session-ID-ctx:
Resumption PSK: 4B8A470585D1427AD5688E4749EE88E2BBFDCF9CF6D85EDAE55D544EC88555063C2735415F0275C00BFDB2A7F6C381BB
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - a8 1b ec 06 fb 43 42 6c-87 93 c1 68 43 f8 bd 66 .....CBl...hC..f
0010 - 2e 5b b9 92 88 4a a8 a4-56 18 45 17 e9 11 1f 8f .[...J..V.E.....

Start Time: 1586067073
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no

Max Early Data: 0

read R BLOCK

If you compare the "Certificate chain" on both outputs, you will see a difference:
in the :443 output:

Certificate chain
0 s:CN = mail.yourdomain.net
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

Whereas on the :993 output:

Certificate chain
0 s:CN = mail.yourdomain.net
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3

It looks like Mailu is not using a fullchain certificate. On :993 , you only have the intermediate certification "Let's Encrypt Authority X3" and missing the "DST Root CA X3" one, although your frontend is using one.
Could you have a look on (all) certificate files generated by your setup ? You might find several crt, one of them being a fullchain ?

The directory mapped on /certs does have the fullchain.pem (whose content is the cat of chain.pem and cert.pem). Its content:
account_key.json account_reg.json cert.pem chain.pem fullchain.pem key.pem
I tried deleting cert.pem and chain.pem, but mailu does not seem to use/find the fullchain.pem

Mailu defaults is to use key.pem and cert.pem, but this can be changed.
Add TLS_CERT_FILENAME=fullchain.pem in your mailu.env, and it should be Ok.

I missed this point in the doc, sorry.
Problem fixed, thanks for you support!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

SJS28092018 picture SJS28092018  路  3Comments

elektro-wolle picture elektro-wolle  路  3Comments

Diman0 picture Diman0  路  3Comments

styxlab picture styxlab  路  4Comments

Angedestenebres picture Angedestenebres  路  3Comments