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