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.
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.
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.
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.
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.
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.
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.
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.
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)
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).
