SSL Bad Certificate warning

fmaddict

Hi
I’m having trouble recently with my Mailcow server and seemingly SSL certs.

I unable to connect to the server via Thunderbird but sending and receiving still seemed to work fine through the webmail. Though applications I have trying to send/receive emails through this server are not working either.

In the Postfix logs I am regularly getting
warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1605:SSL alert number 42:

I’m using SSL certs from my NGINX Proxy Manager instance, and using the same process as I have been for a long time to move the certificates across. I think it’s dovecot not picking up the certificate for some reason? but I’ve not been able to find anything that has helped me with this so far.

Dovecot logs show no errors or warnings at all.

My SSL cert and privkey are in /opt/mailcow-dockerized/data/assets/ssl and /opt/mailcow-dockerized/data/assets/ssl/HOSTNAME.TLD as cert.pem and key.pem

I have put the outputs of a few commands that seem to show something below.

bash helper-scripts/expiry-dates.sh
Could not read certificate from <stdin>
Unable to load certificate
TLS expiry dates:
Postfix: Feb 12 07:48:19 2026 GMT
Dovecot: 
Nginx:   Feb  7 04:36:36 2026 GMT

openssl s_client -starttls imap -connect HOSTNAME.TLD:993 | openssl x509 -noout -text
40278DDDB07E0000:error:8000006F:system library:BIO_connect:Connection refused:../crypto/bio/bio_sock2.c:114:calling connect()
40278DDDB07E0000:error:10000067:BIO routines:BIO_connect:connect error:../crypto/bio/bio_sock2.c:116:
connect:errno=111
Could not read certificate from <stdin>
Unable to load certificate

openssl s_client -starttls smtp -connect HOSTNAME.TLD:587 | openssl x509 -noout -text
depth=0 CN = HOSTNAME.TLD
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = HOSTNAME.TLD
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = HOSTNAME.TLD
verify return:1
250 DSN
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            05:a0:ad:77:47:0e:b0:88:ff:f2:cc:c0:bc:93:df:cd:d3:16
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = E8
        Validity
            Not Before: Nov 14 07:48:20 2025 GMT
            Not After : Feb 12 07:48:19 2026 GMT
        Subject: CN = HOSTNAME.TLD
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:6a:36:1e:31:8f:3c:4a:e3:60:2f:fb:83:c8:a1:
                    34:89:db:ec:93:c2:49:8e:10:cd:10:a0:31:d7:7f:
                    54:d8:8c:61:75:37:3b:c1:fc:b8:62:2a:c8:a1:a1:
                    fb:a2:1d:ca:94:4f:19:cd:d3:f1:74:36:db:8f:ee:
                    e6:1b:14:bc:d4:d2:18:39:03:56:76:a0:08:95:20:
                    63:34:75:8a:c2:01:fa:4f:af:f6:f6:6c:b8:96:f8:
                    94:3f:15:60:6a:91:59
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                CD:62:C6:70:F9:8F:11:AB:75:83:0C:B5:7C:66:2B:69:A3:29:49:6D
            X509v3 Authority Key Identifier: 
                8F:0D:13:A2:F6:2E:7E:D1:50:6C:33:18:38:5D:59:8E:23:72:91:CA
            Authority Information Access: 
                CA Issuers - URI:http://e8.i.lencr.org/
            X509v3 Subject Alternative Name: 
                DNS:HOSTNAME.TLD
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://e8.c.lencr.org/23.crl
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : CB:38:F7:15:89:7C:84:A1:44:5F:5B:C1:DD:FB:C9:6E:
                                F2:9A:59:CD:47:0A:69:05:85:B0:CB:14:C3:14:58:E7
                    Timestamp : Nov 14 08:46:50.960 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:77:07:13:A2:E3:E7:3D:54:B6:BB:5F:E0:
                                62:CF:66:6B:27:4A:DB:E1:B9:A9:33:55:F7:60:F9:F0:
                                86:FE:1B:58:02:20:7D:63:25:3E:2C:0D:9A:24:DC:1E:
                                5C:77:4B:B1:15:B7:CC:36:9E:5F:37:9B:52:44:D2:F7:
                                31:72:7A:5E:E9:DD
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 49:9C:9B:69:DE:1D:7C:EC:FC:36:DE:CD:87:64:A6:B8:
                                5B:AF:0A:87:80:19:D1:55:52:FB:E9:EB:29:DD:F8:C3
                    Timestamp : Nov 14 08:46:50.949 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:70:8F:F0:33:5E:A4:16:C6:F8:3A:D8:11:
                                A6:4A:76:80:8B:65:B5:09:26:66:93:66:D8:50:50:E4:
                                AA:FC:49:A5:02:21:00:D0:A6:E3:C1:6D:45:72:27:32:
                                35:0D:04:22:59:29:E8:B5:BC:19:63:79:AF:6C:2B:BD:
                                88:BA:AC:92:60:FF:C9
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
        30:65:02:30:55:a9:a5:f0:2b:b0:31:59:45:ca:26:5b:79:3b:
        35:2e:1e:c5:54:f1:bf:f8:3b:f0:b8:fe:97:e8:2e:f6:6f:98:
        f0:5b:b4:56:16:ca:15:5e:38:2d:17:42:fc:22:e7:80:02:31:
        00:8f:a6:91:00:2f:c0:44:f6:87:79:69:c0:a5:22:b0:a1:91:
        ce:fb:99:40:8b:a9:46:6a:de:7e:58:5e:67:92:b3:e7:81:85:
        30:a5:01:4b:89:18:df:f3:19:4c:1f:19:94

esackbauer

fmaddict TLS expiry dates:
Postfix: Feb 12 07:48:19 2026 GMT
Dovecot:
Nginx: Feb 7 04:36:36 2026 GMT

Could you explain why the certificates have different expiry dates?

ETNyx

Keys seems to be newly rotated,..

            Not Before: Nov 14 07:48:20 2025 GMT
            Not After : Feb 12 07:48:19 2026 GMT

did you made restart? or down and up whole stack?

fmaddict

ETNyx I’ve tried both restarting the whole VM and just taking the stack up and down, with a few different certificates over a few days, freshly renewed each time to try and rule something out from that.

esackbauer all I get when trying to add an account in Thunderbird is “Thunderbird failed to find the settings for your email account” which isn’t at all helpful. Previously added accounts just don’t load anything and do not show any errors either.
Account details are definitely correct as the work in the webmail. Plus they used to work in thunderbird before what ever happened.
As for the DNS, it’s all still there too. This has been working for over a year without issues prior to this.
server is on mail2.website-inator.com if that helps

esackbauer

Without sharing your mailcow server host address its difficult to say whats the problem.
Also the log files of Thunderbird and exact error messages would help.
Maybe you have not all required DNS names (SAN) in your Nginx Proxy Manager certificates?
https://docs.mailcow.email/getstarted/prerequisite-dns/#the-minimal-dns-configuration

esackbauer

fmaddict “Thunderbird failed to find the settings for your email account” which isn’t at all helpful.

It is helpful as it indicates you are missing the autodiscover.website-inator.com and autoconfig.website-inator.com from your certificate. And checking your certificate on mail2.website-inator.com confirms this.

fmaddict

esackbauer I am still getting the same error on manual configuration, which shoudn’t rely on the autos. The DNS records are there for them anyway.
I’ve been swapping between trying wildcard cert and for the specific URL for testing, and had left it on the specific. It’s back to wildcard and the issues remain.

esackbauer

fmaddict the same error on manual configuration,

Could be that Thunderbird tries to overrule it. Maybe you have in Thunderbird settings the experimenal new account configuration activated? Try to deactivate it.

fmaddict The DNS records are there for them anyway.

That is another problem, if Thunderbird finds the DNS names, it expects a proper certificate.

fmaddict I’ve been swapping between trying wildcard cert

Wildcard certs are not supported by mailcows dovecot and postfix as far as i know.

fmaddict

esackbauer Could be that Thunderbird tries to overrule it. Maybe you have in Thunderbird settings the experimenal new account configuration activated? Try to deactivate it.

The experimental setting is not enabled. Also as previously mentioned other software trying to send emails through this server are having issues with their previously working set ups.

esackbauer Wildcard certs are not supported by mailcows dovecot and postfix as far as i know.

All the information I’m finding is saying otherwise.

Either way, I think the bigger issue here is why is this error coming up in postfix logs. This isn’t just about Thunderbird setup, I only mentioned that as a symptom that I have noticed. Also when running the expiry-dates.sh helper script, why does Dovecot not show a certificate at all?

esackbauer

Maybe the certificate file is incomplete. As per documentation:

save the combined certificate (containing the certificate and intermediate CA/root CA if any) to data/assets/ssl/cert.pem and the corresponding key to data/assets/ssl/key.pem.

fmaddict

esackbauer Maybe the certificate file is incomplete. As per documentation docs.mailcow.emailAdvanced SSL - mailcow: dockerized documentationNone :

The same issues exist wether using the fullchain.pem, or cert.pem from what’s downloaded from NGINX proxy manager. Historically using the cert.pem has been fine. When using chain.pem from this download the containers do not start properly.
If the certificate file was incomplete I would have expected the inbuilt nginx and postfix to have an issue reading it, which they don’t.

DocFraggle

It seems at least your postfix doesn’t serve the whole cert chain

# openssl s_client -connect mail2.website-inator.com:587 -starttls smtp -showcerts
CONNECTED(00000003)
depth=0 CN = *.website-inator.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = *.website-inator.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = *.website-inator.com
verify return:1
---
Certificate chain
 0 s:CN = *.website-inator.com
   i:C = US, O = Let's Encrypt, CN = E7
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Nov  4 05:44:12 2025 GMT; NotAfter: Feb  2 05:44:11 2026 GMT

It’s only the server cert, no intermediate

esackbauer

DocFraggle NotAfter: Feb 2 05:44:11 2026 GMT

Now this is the third certificate with another expiry date. If you request them from Nginx and copy them to mailcow as per documentation, they should all have the same expiry date.