exim issue diffie hellman

I was told now that Letsencrypt defaults to EC ciphers and it seems HP printers do only use RSA ciphers, also on TLS 1.2.
They are a bit older but still not out of date and used for TLS.
So at least we have a cause now. It might well be that on the hostname LE renewal it switched to EC.
They are looking into that now and see if there is a fix possible for people still using or needing RSA ciphers.
 
Yup for that /those kind of and upcoming the forum Letsencrypt is also HOT

community.letsencrypt.org

Help thread for DST Root CA X3 expiration (September 2021)

If you have any questions about whether you need to do anything special for the upcoming DST Root CA X3 expiration in September 2021, please post them here. A staff member may split out some conversations into their own …
community.letsencrypt.org community.letsencrypt.org
 
There is a not yet released letsencrypt.sh script which I could test.
This script checks of presence of EC and creates RSA certificate if not present, if I understood everything correctly.

So I revoked the certificate for my hostname, and created a new one using this new letsenrypt script.
This seems to fix all problems, the RSA ciphers are back again and the customer was able to use their printer again to email scans.

I presume this script will be doublechecked and released so this fixes things for everybody who needs the DHE-RSA ciphers.
 
Richard G said:
There is a not yet released letsencrypt.sh script which I could test.
This script checks of presence of EC and creates RSA certificate if not present, if I understood everything correctly.

So I revoked the certificate for my hostname, and created a new one using this new letsenrypt script.
This seems to fix all problems, the RSA ciphers are back again and the customer was able to use their printer again to email scans.

I presume this script will be doublechecked and released so this fixes things for everybody who needs the DHE-RSA ciphers.
Click to expand...
I am asking again here ( FOR DA SUPPORT) is creating an new cert not enough and automaticly revoking?

So do we need to revoke if we create manual / automatic a new cert ( or with other configs..) ? ')

The other question i did asked before howto for the other 384 ... and hostname cert while docs/wiki/help only say about 2048 / 4096 DA script to do that.
Sorry in BOLD and kind of breakin here on your topic but are old questions not answered yet.

Bit related though. ;)
 
Richard,
Good to read that there is progress!. Will we be getting this with the CustomBuild script or with a DirectAdmin update?

To elaborate on our issue: We have an Exchange 2016 Server that uses Exim as a relay-host. And for some reason it does not use EC ciphers when connecting to Exim.
We do have a ticket with our IT-partner on why this is. (Exchange not using EC ciphers, but ECDHE-RSA-AES256-GCM-SHA384:256 ). But good to know a fix on the Exim side is underway.

regards,
Mathijs
 
Last edited:
ikkeben said:
Think this changed part maybe:
Click to expand...
Yep, that seems to be the changed part.

mgeerarts said:
Will we be getting this with the CustomBuild script or with a DirectAdmin update?
Click to expand...
I don't use the custombuild script and always update via SSH. But as far as I know, yes that would be the case.
However, it might be that after the update you have to create a new certificate for the hostname.

After the fix, these ciphers will be present:
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong

mgeerarts said:
(Exchange not using EC ciphers, but ECDHE-RSA-AES256-GCM-SHA384:256 ).
Click to expand...
I hope it will work then. Non-fixed servers have this:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - strong

I'm not familiar with Exchange but maybe ciphers can be changed there to use these without RSA to prevent future issues if it would change again.
 
Richard G said:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - strong

I'm not familiar with Exchange but maybe ciphers can be changed there to use these without RSA to prevent future issues if it would change again.
Click to expand...
Indeed, we asked out IT-specialist to check, why it is that Exch. doesn't use the ciphers.

When do you think the will new le-scipt be prodution-ready?

regards,
Mathijs
 
Unfortunately, it's not fixed yet. Seems the customer with the printer can now send scans again.

But most other customers including myself are having issues receiving and/or sending mail.
Outlook will give the 0x800cc1a or something error that encryption is not good. Sometimes it works, sometimes it doesn't.

So it seems the ciphers are causing confusing now for the mail clients.
 
Richard G said:
Unfortunately, it's not fixed yet. Seems the customer with the printer can now send scans again.

But most other customers including myself are having issues receiving and/or sending mail.
Outlook will give the 0x800cc1a or something error that encryption is not good. Sometimes it works, sometimes it doesn't.

So it seems the ciphers are causing confusing now for the mail clients.
Click to expand...
Hi Please try to extend ticket asking the way you did revoke and renew cert is the way to go also or the scripts for Letsencrypt hostname and doku help wiki are up to date.

The single and multiple for hostname i mean.

Sometimes docu - help is not 100% in synch with some newer stuff.!
 
We are still busy in the ticket.
Last evening the issue with intermittent problems occured. I put back the original v2.0.21 script and requested a new certificate for the hostname they way it should be done, to get things back to original gain.
Odd enough the RSA ciphers were not removed and are still there.

So later on I revoked the certificate again and again requested a new one the correct way. Oddly enough, all stayed the same, but the problem was gone about 15 minutes after that. Maybe due to some tally action (i've seen a DA tally was running), i don't know yet.
The RSA ciphers (from the v.2.0.22 request) are still present, but all problems are gone now.
No intermittend actions with picking up or sending mail anymore and printer can print because the RSA ciphers are still present. I presume, because the customer did not complaint again yet.

So very strange.
 
@mgeerarts Maybe you've seen it but the new letsencrypt.sh 2.0.22 script has been released last night.
So it should be available for everybody now. I hope that fixes your issue too, maybe you need to request a new hostname certificate (I would suggest to revoke the old one first).
Please let me know if this also fixes your issue with Exchange.
 
Ok i put also here some Letsencypt links to read and test ( read also there the changes Last updated: May 13, 2021 | See all Documentation) for those finding this topic. ( i know this is double post but in this topic for certs could be handy you don't have to search for those links)

letsencrypt.org

Staging Environment

We highly recommend testing against our staging environment before using our production environment. This will allow you to get things right before issuing trusted certificates and reduce the chance of your running up against rate limits. The ACME URL for our ACME v2 staging environment is...
letsencrypt.org


And to test the certs:

crt.sh | Certificate Search

Free CT Log Certificate Search Tool from Sectigo (formerly Comodo CA)
crt.sh

crt.sh | Certificate Search

Free CT Log Certificate Search Tool from Sectigo (formerly Comodo CA)
crt.sh
 
Last edited:
Richard G said:
@mgeerarts Maybe you've seen it but the new letsencrypt.sh 2.0.22 script has been released last night.
So it should be available for everybody now. I hope that fixes your issue too, maybe you need to request a new hostname certificate (I would suggest to revoke the old one first).
Please let me know if this also fixes your issue with Exchange.
Click to expand...
Richard,
The new letsenrypt.sh did fix our issue.
Thank you for the support.

Mathijs
 
You're welcome. Glad to hear it's fixed for you too.
Just to be sure (and out of curiosity), did you had to request a new hostname certificate too for things to be fixed?
 
Richard G said:
You're welcome. Glad to hear it's fixed for you too.
Just to be sure (and out of curiosity), did you had to request a new hostname certificate too for things to be fixed?
Click to expand...
Richard,
We did not test without requesting a new cert. We went straight ahead ran the letsencrypt.sh script to generate a new cert. (we did not revoke anything) We used this command:

/usr/local/directadmin/scripts/letsencrypt.sh request_single hostname.domain.com 4096
Mind you; this is de actual server/hostname (VPS) that DirectAdmin uses for its internal services like Exim.

After that, the TLS-error went away and a correct TLS-connection was negotiated between Exim and Exchange
 
You must log in or register to reply here.
Back
Top