Re: No supported cipher suites have been found.

Mike Wright <[email protected]> Sun, 1 Dec 2024 00:03:15 -0800
Newsgroups gmane.mail.imap.courier.general
Message-ID <[email protected]>
On 11/30/24 22:37, Sam Varshavchik wrote:
> Mike Wright writes:
> 
>> I have no other reports of bounced mail.
>>
>> Journalctl reports this message (their IP is obfuscated)
>>
>> courieresmtpd: STARTTLS failed: ip=[::ffff:a.b.c.d], No supported 
>> cipher suites have been found.
>>
>> The esmptd-ssl file is unmodified except for the TLS_* certificate 
>> locations, SSLADDRESS=serverIP, and ESMTPDSSLSTART=YES.
>>
>> The most recent letsencrypt certificates are dated Oct 26.
> 
> The two most common reasons for this are:
> 
> - the peer does not like the certificate's hash functions. Some hash 
> functions, like MD5, are considered deprecated, and some TLS peers will 
> reject certificates that use deprecated hash functions.
> 
> I would expect, though, for letsencrypt to be up to speed, in this regard.
> 
> - the most literal meaning: the peer does not like the server's list of 
> supported ciphers, some TLS peers will only find DHE ciphers acceptable, 
> for reasons that are unimportant. Check what TLS_DHPARAMS in the 
> esmtpd-ssl configuration file is set to, and make sure that it actually 
> exists, and contains DH parameters. There should be a script that 
> periodically generates the dh parameters file (at least the default 
> Courier scripts do).

Thanks for the quick response.

I never mess with this setup and the system lives on a remote server 
(rented service).

Here's what esmptd-ssl says about DHPARAMS:
     TLS_DHPARAMS=/etc/courier/dhparams.pem

ls -l /etc/courier/dhparams.pem
     -rw------- 1 courier root 3535 Oct 14 08:21 dhparams.pem

I checked all my certs with openssl and got some strange results:

/etc/letsencrypt/archive/a.mx.hostisimo.com/ \
   {cert,chain,fullchain,privkey}X.pem and found the complete history 
validated using "openssl x509 -in PATH_TO_CERT -noout -text and 
everything checked out EXCEPT privkeyX.pem. NONE of the were readable,
throwing "Could not read certificate from privkeyX.pem".

On to /etc/courier and found dhparams.pem threw the same error.  ls -l 
dhparams.pem -rw------- 1 courier root 3535 Oct 14 08:21 dhparams.pem. 
That cert was auto-generated mid October by /usr/lib/courier/mkdhparams.

The debian o/s is up to date, all upgrades applied.  This is acting like 
the openssl package has become corrupted (my best guess).  Could memory 
be a culprit?

The question is why certs are OK but keys and dhparams are not.

Any ideas?


_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users