Re: No supported cipher suites have been found.

On 12/1/24 05:50, Sam Varshavchik wrote:
> Mike Wright writes:
> 
>> 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.
> 
> One common denominator is that these files have restricted permissions, 
> because they are secrets. Note that they are not world-readable.

Changed permissions to -rwxr--r-- and got the same results.  Here is the 
complete error message:

Could not read certificate from dhparams.pem.
4027B72ADD7F0000:error:1608010C:STORE 
routines:ossl_store_handle_load_result:unsupported:../crypto/store/store_result.c:151:

Unable to load certificate
> 
> Didn't you say that you updated and/or replaced packages.

Only the standard update, upgrade.

If you
> replaced Debian's native packages with the ones that are built from the 
> source, they're configured differently, using differed userids.
> 
Building now... see previous email.

> Run "courierauthconfig --configfiles" and the shown mailuser and 
> mailgroup should correspond to the ownership of the secret files.


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