For openssl s_client -connect mail.fmp.com:143 -starttls imap I currently get the following, maybe you're still working on it..
CONNECTED(00000003)
40E7A617E67F0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:354:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 534 bytes and written 340 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
So I had a look with Wireshark, and your couriertls is throwing error messages:
NO STARTTLS failed: couriertls: /etc/ssl/certs/7c302982.0: No such file or directory
* NO Error in IMAP command received by server.
....5. NO Error in IMAP command received by server.
.. NO Error in IMAP command received by server.
* NO Error in IMAP command received by server.
* NO Error in IMAP command received by server.
So the problem appears to be with your couriertls expecting some of the files in /etc/ssl/certs that appear to be no longer there. I'm not experienced with courier, so no idea why that happens.
I can't find any portion of the Courier suite, especially the couriertls unit, which expects a specific file in ssl/certs. This is, oddly enough, another TrustCor certificate, which has been removed as per executive decision by Mozilla, but the mail server should never be asking for a specific file within the SSL subsystem.
You've restarted the services right? I can't see why it would refer to a file that doesn't exist unless it had cached the file paths in memory and now it was trying to load them. Impressively, googling your error returns this very post.
Yes, one of the 1st things I always do for mail server problems is check the process table and then kill and restart the entire Courier suite. On rare occasions, something in Courier will get hung up and a full restart of the suite will correct it. In this case, it didn't. It may be that the file access request on /etc/ssl/certs/7c302982.0 is cached elsewhere. Courier MTA and friends has an active forum, of which I'm a member, so I'll pursue it there.
Google is quick to index tech forums. No surprise thiat this discussion is already in their index.
In line with our policies, Mozilla weighs the risks and benefits to end-user security when deciding whether a CA should be a member of our Root Program. Ordinarily, Mozilla would not directly evaluate the benefit of the CA owner’s other products when considering whether a CA should be a member of our Root Program. However, Trustcor’s quantifying value statement rests heavily on the value of MsgSafe which has suffered from a number of problematic behaviors [9] that undermine the value proposition of MsgSafe, and therefore undermine the purported benefits for the TrustCor CA to be a member of our Root Program.
Our assessment is that the concerns about TrustCor have been substantiated and the risks of TrustCor’s continued membership in Mozilla’s Root Program outweighs the benefits to end users.
Set “Distrust for TLS After Date” and “Distrust for S/MIME After Date” to November 30, 2022, for the 3 TrustCor root certificates (TrustCor RootCert CA-1, TrustCor ECA-1, TrustCor RootCert CA-2) that are currently included in Mozilla’s root store.
Remove those root certificates from Mozilla’s root store after the existing end-entity TLS certificates have expired.
The couriertls program iterates through the files in /etc/ssl/certs. These are symlinks to files in /usr/share/ca-certificates/mozilla/. The package update process removed files in the latter folder, leaving broken symlinks in the former, and couriertls was barfing on the broken symlinks. I removed these manually and it looks as if all is well.
My sincere thanks to everyone who weighed in on this problem.
Lindsay Haisley, by golly. I guess I'll visit your website to see what you are up to. I suspect you are still as old as me, because that can't be fixed, but do you still live in Austin?