I have a server that when installed automatically created a Let's Encrypt cert. The cert is 2048 but for testing I need to rekey it to 1024. I don't see any rekeying procedures anywhere or at least any documentation explaining a workaround.
2 Likes
Unfortunately, you won't be able to get a Let's Encrypt certificate of that size. The minimum supported key length for RSA certificates is 2048.
6 Likes
Thanks for the info. Since we have hundreds of devices that can’t negotiate SSL connections with certs larger than 1024 we’ll have to get our certs elsewhere.
2 Likes
You will likely have to spin up your own internal certificate authority in order to generate certs with 1024 bit keys. I don't think any publicly trusted certificate authority is allowed to issue certificates with key sizes that small anymore unless I'm misunderstanding the baseline requirements.
There is an organization called the CA/Browser Forum that governs a set of baseline requirements all publicly trusted CAs must adhere to. Specifically section 6.1.1.3 states
The CA SHALL reject a certificate request if one or more of the following conditions are met.
- The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6;
And section 6.1.5 states:
For RSA key pairs the CA SHALL:
- Ensure that the modulus size, when encoded, is at least 2048 bits, and;
- Ensure that the modulus size, in bits, is evenly divisible by 8.
5 Likes
Most likely a futile question / obvious answer ... but I have to ask it:
Do those device support any other type of certs, like: ECDSA/ECC ?
READERS: Get involved and participate: If you read something you like, then click to like it 
2 Likes
Although many sizes may be allowed, I think this is no longer being supported by LE.
4 Likes
From the numbers we implicitly assumed (of course, with extreme high likelihood) that you are talking about RSA keys here. For the shake of precision could you confirm this, please?
Just out of curiosity, what kind of device is it, which does not allow bigger than 1024 bits of RSA key to use?
2 Likes
There was kind of a big fight about some of the rules that @rmbolger mentions because they were part of an important security update for the Internet, but many people had older devices that weren't compatible with them (if I remember correctly, mostly retail point-of-sale systems, but probably others too).
There was a paid CA that offered a workaround to this by continuing to issue legacy certs under a particular root certificate that was then removed from browsers (thereby creating a difference between browser-trusted certs and various-legacy-device-trusted certs). I don't remember which CA that is or whether this service is still offered, but it might be relevant to @slonkak's situation. As you mention, no publicly trusted CA (for the web PKI) will be allowed to issue these certificates anymore, but it might happen that there is some CA trusted by the relevant devices that continues to offer this service for a period of time.
3 Likes
The server is a voip server and the devices are old Cisco SPA303's. I've found various posts on the Cisco forums and other sites with people doing crypto dev and they found that the 303's can only do DH negotiation at 1024, and since it's standard to have your cert and DH bit level match, I made the jump that the cert needs to be 1024 as well for it to work. But if no public CAs offer 1024, I'm not sure I can make this work because Cisco phones only trust certs from the Cisco CA (maybe I have to get the cert from them for it to be 1024) unless you add the option to trust another CA, which was what I have to do for them to trust LE certs. Even if I were to make a self-signed cert on the voip server, I'm not sure if I can make the phone trust a self-signed CA. I guess I just gave myself a few more things to test.
3 Likes
How about any ciphers that don't use DH?
1 Like
Do you have a Cisco CA?
If so, what are the cipher options available there?
If you can get them to trust another CA, then you could create your own CA for them to trust.
But aren't all CAs essentially self-signed?
1 Like
I'd have to contact Cisco to get them to issue me a cert from their CA.
I could, but the other thing I have to keep in mind is that this cert isn't just for phone provisioning, it's also the cert for the phone system's website. So whatever my solution is it has to keep working with modern web browsers without warning users of an insecure certificate for one reason or another. This is also the issue with doing a self-signed cert. The phones might work but then web browsers would complain.
I suppose I could modify the nginx config to try and break out the different virtual directories so that the provisioning dir is secured by the self-signed cert, or the 1024 cert if I can get one, etc., while leaving the rest of the website secured by the LE cert. This voip server does some sort of magic I haven't quite figured out yet with the provisioning directory (it doesn't exist but it does), so I'd have to figure that out first... but it's doable.
2 Likes
Since I am not very deep knowledgeable in the encryption standards, it is new to me that there is a standard requirement about the Diffie-Helman and RSA key length equality. I always thought that they are quiet independent stuff, thanks for the info.
1 Like
Even if it's not "standard", is it possible (on those devices) to have a 2048-bit RSA key while still using 1024-bit DH parameters? (This is something I'm entirely unfamiliar with, so it may be that this question makes no sense.)
2 Likes
I’m still testing what is “possible”. As of now, I have tried a 2048-bit RSA cert from LE with 1024-bit DH parameters specified and it did not work (even after adding the custom CA rule on the phone to add LE’s CA chain). Unfortunately the phone’s debug statements do not tell me why the SSL connection is failing, even at the highest debug level, and a packet capture is also of no help. So it’s really trial and error for me at this point.
2 Likes
I don't think that is possible. Under HTTPS, the SSL Certificate selection happens before the client translates the URL - and the URL is encrypted. Only the domain/hostname is sent unencrypted (there may be other elements too, but the full URL is not part of the exchange).
You might be able to use multiple domains or something, but even using OpenResty to hook into the nginx request lifecycle, i don't think this is technically possible.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.