Mail server borked? (Server certificate verification error)

[oddhack]

I just got the following from fetchmail on sonic. It was working fine a few hours ago. Anyone else having trouble?

fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: Broken certification chain at: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about. For details, please see the README.SSL-SERVER document that ships with fetchmail.
fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from oddhack@imap.sonic.net
fetchmail: Query status=2 (SOCKET)

[oddhack]

Oh, also seeing errors popping up on webmail.sonic.net, though I did manage to click through to a new email on maybe the 5th try. Maybe a software upgrade that went bad tonight?

[ewhac]

Code: Select all

fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: Broken certification chain at: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

Who the hell is still using COMODO?

https://www.crn.com/news/security/comod ... -000-users

[oddhack]

Who the hell is still using COMODO?

Shrug. They do appear to have more products than forum software (like issuing certs). Anyway, fetchmail is functioning again whatever the cause. Maybe some poor, pathetic, benighted country's President decided to shut off email here and there just to show that he could.

[ewhac]

Shrug. They do appear to have more products than forum software (like issuing certs).

That's the problem; they're a sh*t CA. Nobody should be using them.

From 2011: https://www.infoworld.com/article/26236 ... cates.html
From 2019: https://techcrunch.com/2019/07/27/comod ... cess-data/

To be fair, COMODO isn't the only CA run by bungling idiots: https://www.theregister.co.uk/2018/03/0 ... ntec_spat/

[ewhac]

More to your point, however: A quick check using openssl reveals this:

Code: Select all

$ openssl s_client -connect imap.sonic.net:imaps
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = imap.sonic.net
verify return:1
140255720559872:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2149:
---
Certificate chain
 0 s:OU = Domain Control Validated, OU = PositiveSSL, CN = imap.sonic.net
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
 2 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
[blah blah blah...]
-----END CERTIFICATE-----
subject=OU = Domain Control Validated, OU = PositiveSSL, CN = imap.sonic.net

issuer=C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA

---
No client certificate CA names sent
---
SSL handshake has read 5821 bytes and written 313 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1590772906
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

The only potential issue that's immediately visible is the error message "error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small". OpenSSL installations on Linux started upgrading their default security level to 2, which throws warnings/errors when a server's Diffie-Hellman key is too short. The other thing that happened relatively recently is that fetchmail got much more picky about certs and cert chains being valid.

Unfortunately, my SSL-fu is not strong enough to isolate this further. Weak Diffie-Hellman keys appears to be server-side issue; it looks like Sonic may need to tweak/upgrade their TLS libraries.

Try the `openssl` command above and see if it offers you more clues.

[kgc]

https://sonicstatus.com/2020/05/28/imap ... r-upgrade/

It would have been more accurate to say it was rolled back than postponed. There were some issues post upgrade and it wasn't readily apparent how to resolve them.