Unable to force a secp256r1 signature

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:
/opt/certbot/bin/certbot certonly --cert-name EC_alt_LBV.com --dns-google --dns-google-credentials /etc/security/H5G-Infrastructure-DNS-Certbot.json --dns-google-propagation-seconds 240 -d luckybitsvegas.com -d ".luckybitsvegas.com"
-- also
/opt/certbot/bin/certbot certonly --cert-name EC_alt_LBV.com --key-type ecdsa --elliptic-curve secp256r1 --dns-google --dns-google-credentials /etc/security/H5G-Infrastructure-DNS-Certbot.json --dns-google-propagation-seconds 240 -d luckybitsvegas.com -d "
.luckybitsvegas.com"
--also
/opt/certbot/bin/certbot certonly --cert-name EC_alt_LBV.com --elliptic-curve secp256r1 --dns-google --dns-google-credentials /etc/security/H5G-Infrastructure-DNS-Certbot.json --dns-google-propagation-seconds 240 -d luckybitsvegas.com -d "*.luckybitsvegas.com"

It produced this output:
Signature Algorithm: ecdsa-with-SHA384
Public Key Algorithm: id-ecPublicKey
Signature Algorithm: ecdsa-with-SHA384

I need a secp256r1 signature.

My web server is (include version): not sure

The operating system my web server runs on is (include version): ubuntu 24LTS

My hosting provider, if applicable, is: Google Cloud

I can login to a root shell on my machine (yes or no, or I don't know):yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.7.4

The signatures are dependend on the signing key, not the public key inside the certificate itself.

2 Likes

Let's Encrypt does not have a P256 intermediate.

We only have P384 (and RSA2048).

Thus we cannot provide a P256 signature on certificates we issue.

5 Likes

Can you explain why you need this?

4 Likes

An EDI client reports that they cannot connect to my system because their host can't negotiate encryption beyond P256 or RSA 2048. I thought I should tell them that support for windows NT has passed, but I held my tongue. Thanks for the response.

Lots of love for Let's Encrypt. I wear my Lets Encrypt and EFF t shirts to all the b sides.

4 Likes

If you need compatibility with old systems, your best bet is to stick with RSA keys. Let's Encrypt currently signs RSA leafs with their RSA intermediates. Just add --key-type rsa to your certbot commands and use --rsa-key-size instead of --elliptic-curve.

It may be that you could find some other CA that uses P-256 intermediates, and would sign your P-256 leaf with it (or would sign your P-256 leaf with an RSA intermediate). But in general RSA still "just works" with obsolete systems much more so than the "new-fangled" (no, it's not that new) elliptic stuff.

5 Likes

Another thing you can do is setup a site just for that client e.g. edi-client.yourdomain.com and proxy it back to whatever service it's supposed to be talking to, that way you keep your overall defaults the way you like them but make a special case for the older client.

I think some services can also be configured with multiple certs (using different key types) and they negotiate whatever works but that could be harder to set up.

7 Likes

That won't work, as the server certificate selection will be based on the client cipher suites including ECDSA or not.
But if this client does support ECDSA, just not P-384, there's no way to distinguish that from the server side.

2 Likes

I perhaps wasn't clear, you can totally setup a custom server/service that's compatible with a client, if the client is important and you are providing them the custom url pointing to that service. I'm assuming in this instance the client is indeed important enough for a custom endpoint.

2 Likes

I added a 'special' IP address to the load balancer and used RSA2048 on the cert for that endpoint. So that part is solved.
I should report that the man pages and the certbot source report that P256 is a legit option, referring to RFC for details.

Thanks for all the help.

2 Likes

Sure, you can absolutely have your leaf certificate use ECDSA P-256, which is actually certbot's current default and what your original certbot command lines explicitly ask for. What you can't (directly) control is what key type the CA intermediate signs your certificate with. Currently, Let's Encrypt signs ECDSA certificates with a P-384 intermediate, and RSA certificates with a 2048-bit RSA intermediate. But they could, for instance, have chosen instead to sign everything with 4096-bit RSA, or everything with P-256 ECDSA, regardless of the key type used by the leaf certificate.

One of the challenges of certificate chains is that the system validating them needs to support all the signature types from the leafs up through the trusted root. You don't have much influence on most of those signatures beyond picking which CA to use, based on the CA's current policies. And you're of course limited by needing to pick one of the CAs in the trusted root store of whatever systems you want to be able to connect to you.

With custom old systems like what you're talking about, it may be worth looking into making your own small private CA and convincing your client add it to its trust store, and that way you do have control over the entire chain.

5 Likes

I don't think there's many legitimate uses for that option, if you can't use ecdsa you should get maximum compatibility with 2048 bit keys (and some legacy systems still won't support it, but at that point I'm not even sure CA/B Baseline Requirements allow going lower)

2 Likes

They are not a big enough client for me to spend time on. The issue is on their end and I've got actual work to do. :slight_smile:

3 Likes

This is why I chose for CertSage to request certificates with private keys of P-384 for ECDSA and 2,048-bit for RSA. Figured if it's good enough for LE then it's good enough for me (and it minimizes the number of "types" to support).

4 Likes