EC-384 keys auto renew as DH-4096 instead of EC-384

P

patrickkasie

Verified User
Joined
Sep 21, 2021
Messages
226
Location
Een echte Hollander
Dear DirectAdmin forum,

It seems that 24 days ago, there has been an update to multiple servers in some way, but due to round errors let's say it was on monday august 12th. At that day, I've updated all DA servers to their most recent version. The problem only appears now that I was testing some domainnames to see if they were up to internet.nl's standards. They do not anymore.

Ever since the autorenewal of the keys since august 12th, they seem to all be renewed using DH-4096 key bit size instead of EC-384. Domainnames that are bound to have their certificate renewed after the 12th all have the DH-4096 key bit length, the currently unrenewed domainnames from before that day that are still valid are still holding on to EC-384.

Using the option "Free & automatic certificate from Let's Encrypt", renewing the certificates manually regardless of EC-384 or DH-4096 renews it with their respective keybits if you don't select a different keybit option.

What has the reason for this change? Is it a bug or is it just me? It happens across MOST but not all servers from 2 different hosting companies, so it's not 1 mistake on one site.
It happens on servers that are both CentOS7, but not on AlmaLinux8
 
Last edited:
Hi Patrick

In our case, I have changed the letsencrypt renewal script, so all certificates gets renewed with EC-256 keys.
At the moment, even when someone requests a RSA or EC-384 key, the certificate gets requested with EC-256 keys.
I don't see why a customer would make the right decision on key size if even DirectAdmin choses a weird default.
=> Currently EC-384 is the default key size.

I don't see why it is necessary to request a RSA key with a 4096 bit size, or a EC key with a 384 bit size.
Even a RSA key with a 2048 size or a EC key with a 256 size is 'probably' 'unbreakable' today until 2030.
Plus, all certificates have a lifetime of around 3 months. I say: IMPOSSIBLE....

Edit:
I just want to say: bigger key sizes does not inherently make things more secure. It just makes the certificate more difficult to break. And it is more difficult to verify as well. This means that it takes more CPU cycles on the visitors' device to verify the certificate. And this means the (first) connection to your client's websites takes a bit longer.
Because the certificate key is recycled every 90 days, some could technically determine that a RSA keysize of 1024 would suffice. But I am not going to say this.

You can find the letsencrypt script in /usr/local/directadmin/scripts
When you change it, make a copy of it into /usr/local/directadmin/scripts/custom/

Kr
Dries
 
Last edited:
At this moment we still have these:
Code: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
and some others.

However, for a printer of a customer we needed these, was also an issue in the past:
Code: 
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Which are not present anymore again.

Why are they gone again? They are also part of TLS 1.2 right? Do we need this fixed again like in 2021?
 
This is the misconception many people have.
The keysize or the algorithm of the certificate does not determine the encryption standard that will be used to connect over TLS.

The certificate only provides the client with prove that it is connecting with the server it wants to connect to.
When the certificate gets stolen, or it gets cracked (impossible with RSA 2048 or EC-256 today) someone could potentially do a man in the middle. Even to do a man in the middle is rather (or somewhat) 'difficult'.
You will need to be the owner of a wifi network, or you need to be a government or you must have hacked a very big provider to do a man in the middle on a bigger scale.

Kr
Dries
 
Driesp said:
This is the misconception many people have.
Click to expand...
Well it might be. But in the past the printer of the customer could not connect when having only the EHDCE, then that odd SSL error occured in the logs. I have some threads about it. And you too.

So it was fixed and the DHE_RSA was back again, which I'm missing again now. I'll ask my customer if the printer now still works. Maybe they got a new one.
 
Make a copy of the script /usr/local/directadmin/scripts/letsencrypt.sh to /usr/local/directadmin/scripts/custom/letsencrypt.sh

Open the custom letsencrypt script with this command:
# vi /usr/local/directadmin/scripts/custom/letsencrypt.sh +330

On this line, change KEY_SIZE=$3 with
KEY_SIZE="ec256"
Please test this and read this script so you understand what it does before changing it in production.

When someone requests a certificate via a acme provider, the certificate will be requested with a EC-256 key regardless what key is chosen in DirectAdmin.
Also when a certificate is due to be renewed, it will be renewed with a EC-256 key regardless of what the algorithm was before.
So change this, and wait 90 days before all certificates will be renewed with a EC-256 key.

In DNSSEC, the root key (the key that is used as a root anchor) is a RSA 2048 key which is generated in 2017.
If you tell me you really need a RSA 4096 key or a EC-384 key which will be renewed every 90 days, I will not believe you.

Kr
Dries
 
Thank you for the response. I've gone through the script and I see what it does. It requests or renews the certificate without regards of what has been selected as the third argument, which is the key_size.

Again, this is only up to the standards of internet.nl as my employer puts great emphasis on getting to 100% on that website. We may not need it, but if it brings an artificial number up, then we'll want to do it.

Btw, is this a confirmed bug that it's happening to our servers on CentOS7 since 4 weeks? I'd rather have an explanation for the behavior where it decided to automatically renew as DH-4096 instead of what it was using before. I will await a response before implementing the change, even though it looks harmless, I'd rather have less scripts to keep track of.
 
Just to be sure, when you say DH-4096, you are talking about RSA-4096 right?

I am not running CentOS 7 anymore, because it is out for support. So I cannot comment on this.

Can you tell me the exact message you see on internet.nl?
 
Unsure. It's just the button, see attached image
 

Attachments

  • chrome_0HFktC0IiT.png
    chrome_0HFktC0IiT.png
    2.9 KB · Views: 17
Driesp said:
Just to be sure, when you say DH-4096, you are talking about RSA-4096 right?

I am not running CentOS 7 anymore, because it is out for support. So I cannot comment on this.

Can you tell me the exact message you see on internet.nl?
Click to expand...

Uitslag:​

Je webserver ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.

Technische details:​

[th]
Webserver-IP-adres​
[/th][th]
Getroffen parameters​
[/th][th]
Status​
[/th]​
[td]136.144.153.109[/td][td]DH-4096[/td][td]onvoldoende[/td] [td]2a01:7c8:fff7:2ed::1[/td][td]DH-4096[/td][td]onvoldoende[/td]

Testuitleg:​

We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je webserver, veilig zijn.
ECDHE: De veiligheid van de ECDHE-sleuteluitwisseling is afhankelijk van de geselecteerde elliptische kromme. We testen of de bitlengte van de gebruikte kromme tenminste 224 bits is. Op dit moment kunnen we niet de naam van de elliptische kromme testen.
DHE: De veiligheid van de Diffie-Hellman Ephemeral (DHE) sleuteluitwisseling is afhankelijk van de lengte van de publieke en geheime sleutels die in de geselecteerde finite field-groep wordt gebruikt. We testen of je publieke DHE-sleutelmateriaal gebruikmaakt van een van de gepredefinieerde finite field-groepen die zijn gespecificeerd in RFC 7919. Zelf-gegenereerde groepen zijn 'Onvoldoende'.
De grotere sleutellengtes die noodzakelijk zijn voor het gebruik van DHE gaan ten koste van de prestaties. Maak een zorgvuldige afweging en gebruik waar mogelijk ECDHE in plaats van DHE.
RSA als alternatief: Naast ECDHE en DHE, kan RSA gebruikt worden voor sleuteluitwisseling. RSA loopt het risico om onvoldoende veilig te worden (huidige status 'Uit te faseren'). De publieke RSA-parameters worden getest in de subtest 'Handtekening-parameters van certificaat'. Overigens heeft RSA voor certificaatverificatie wel de status 'Goed'.
Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.
Elliptische krommen voor ECDHE
  • Goed: secp384r1, secp256r1, x448, en x25519
  • Uit te faseren: secp224r1
  • Onvoldoende: Andere krommen
Finite field-groepen voor DHE
  • Voldoende:
    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Merk op dat we ook testen op ffdhe8192 and ffdhe6144 die beide voldoende zijn. Echter, hun beperkte beveiligingswinst weegt zelden op tegen het prestatie-verlies.
  • Uit te faseren:
    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b
  • Onvoldoende: Andere groepen
Let op: de bovenstaande namen zijn gebaseerd op de IANA naamgevingsconventies. Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals prime256v1 (ANSI) en NIST P-256 voor secp256r1.
 
This message is not talking about the certificate. But probably about a TLS cipher.

You should upgrade to Rocky 8 or Rocky 9.
I would suggest not putting any more effort into a CentOS7 install.

My suggestion is, make a new installation with Rocky 9 and move everything over to Rocky 9.
Your issue would most likely be gone.
 
Driesp said:
This message is not talking about the certificate. But probably about a TLS cipher.

You should upgrade to Rocky 8 or Rocky 9.
I would suggest not putting any more effort into a CentOS7 install.

My suggestion is, make a new installation with Rocky 9 and move everything over to Rocky 9.
Your issue would most likely be gone.
Click to expand...
We're already planning on upgrading to AlmaLinux8 within the next week or 2 on all our servers. We'll be fine. But thank you for the reply
 
I've got the same on my Alma 9 server for my domain, same issue you are having when looking at SSL.
1725470153236.png
 
Last edited:
What does this say?
# grep ssl_configuration /usr/local/directadmin/custombuild/options.conf
It should say intermediate.

The second screenshot says something about a nameserver's IP range which is not signed with RPKI.
Only the provider which is hosting that nameserver can fix this.

Kr
Dries
 
Yes it's intermediate. The second screenshots is for the datacenter which needs to change that. I thought I removed those screenshots but seems I've forgotten that one so I will take it away now.
Not the provider that is hosting that nameserver (because that's us), but the ip owner can fix that, so in my case Hetzner.

So I have intermediate, but on my domain and server domain for example having those DH-4096 which internet.nl says is not sufficient.
Seems the servers hostname is not having this issue. So maybe we must renew certificates some way, however DA is doing that automatically, is also set to automatic ssl creation.
Hostname I created manually.
 
Oh, this is interesting. I would like to know why this is.
Can you private message me the link to the results on internet.nl please? I would like to know why this is happening.
 
Gives a grade A and the chipers are 95% just like with internet.nl where I get a 97% for total.


TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 4096 bits FS 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 4096 bits FS

These are ciphers from ssllabs.
 
You must log in or register to reply here.
Back
Top