A few ECDSA/RSA questions

I am very familiar with RSA Cryptography, but Elliptic Curve is new to me. I have been working on ECDSA support for my ACME client in anticipation of the forthcoming EC roots, and have a handful of questions. If anyone is knowledgable on these points, I would be grateful. I haven't found any good primers on EC that cover the types of information that I am looking to understand.

  1. LetsEncrypt Rate Limits

Does the Certificate Type factor into the DuplicateCertificate Rate limit? I assume it does not, but I wanted to check. ( Context: According to Certbot's docs, a given person might want to deploy both RSA and EC Certificates see User Guide — Certbot 1.11.0.dev0 documentation )

  1. One feature of our ACME-Client/CertificateManager is tracking Certificate and PrivateKey data. When dealing with only RSA keys, a simple and useful feature has been to track the modulus of Certificates and Private Keys. It has been very useful when troubleshooting deployments and configurations.

2-A. Is there anything comparable with EC keys? I have heard of people extracting the public key and fingerprinting that; and also using a tuple of the selected curve along with one of the internal payloads. I'm not sure what the reciprocal element of Certificate is. Is there a commonly accepted approach here?

2-B. What about mixed systems? It's possible for someone to use an EC Private key now, and get an RSA signed certificate. Is there any shared mapping that can be derived from these?

Thank you for your time reading this, and if you have any pointers I would be grateful for those as well.


I would answer with 99.999% confidence in the negative. The definition I wrote for the rate-limit overhaul page is that two certificates are considered duplicates of each other if they share the exact same SANs in any order regardless of the public keys they contain.

If I'm wrong here, I'd really like to know ASAP.

FWIW from PHP's openssl_pkey_get_details():

Well... personally I consider the parallel of the JWK key requirements when registering for an ACME account using RSA or ECC since only the public portion is presented there. I definitely get the nature of the problem of unique mapping as RSA's "n" is unique and represents duality clearly. I'd be curious if there's something more here too.

I might have to look into some of my work with encrypting fingerprint minutiae templates for a means of "fingerprinting" here. The algorithms I developed there were inexact/flexible while providing an almost certain matchability.


If all you are doing is tracking keys against their associated certificates, why not use the SPKI hash? It's easier to track and compare x509 -pubout and pkey -pubout than having to interpret what those bytes mean.

Being algorithm-agnostic also means you won't have to update the code to support future algorithms like EdDSA.


Yeah, purchasing RSA and ECDSA certificate for the same set of domains account into Certificate rate limit and once you reach 5, too many certificates already issued for exact set of domains error was seen during my testing period.


Welcome to the Let's Encrypt Community :slightly_smiling_face:

Purchasing what and from whom?

Considering that the Let's Encrypt server that will be issuing EC certificates (E1) has not yet issued any certificates whatsoever, I have no clue what you are talking about.

Testing period? What?

1 Like

You can get EC certificates already, they're just signed by an RSA intermediate. I've done this myself.


Sorry, @griffin I should have explained it better.

Nothing is being purchased here. I meant generating/obtaining a certificate for a domain from LE.

The client I use generates subscriber cert with ECC 256bit key. The root and intermediate are still an RSA Cert of LE.

I meant the testing period when I tried to test the support of hosting both ECDSA(subscriber cert alone) and RSA in our load balancer for a domain. Not something related to the new E1 certificate that is being set up in LE.


That makes much more sense. :slightly_smiling_face:

I was truly confused there and thought I really missed something.


The EC subject public key I knew about. I thought that santhoshmanikandan was talking about testing across R3-E1 issuance, which is currently not possible. This was a silly matter of definition difference. :slightly_smiling_face: When I read some of the other terms that santhoshmanikandan was using, I questioned whether santhoshmanikandan was referencing Let's Encrypt or an entirely different CA.

Turns out that @santhoshmanikandan was actually presenting empirical evidence that confirmed part of my original theory, for which I'm very thankful. :slightly_smiling_face:


I can't think of any reason not to! I'll give it a shot!

Sorry, I should have been more clear. I know this can happen, I'm just unsure if there are any nuances in fingerprinting when dealing with the mixed systems of a EC Cert/Pkey and RSA chain.


Thanks! I finally got around to testing this, and it looks promising.

Followup question, @_az, if you don't mind --what algorithm would you compute the hash with? Spoiler bit below, after you've thought of an answer but not typed anything. (I'm trying to not influence your answer)

All the examples I've seen regarding this are using SHA256, but this really looks to me more in-line with certificate pinning and browser certificate data - which typically uses SHA1.

1 Like

I don't know, I think I'd probably use SHA256 just because it's a good go-to cryptographic hash?

RFC5280 suggests using SHA1 to derive SKI/AKI values, which is roughly equivalent to what you're doing. Let's Encrypt uses SHA1 for that today.

On the other hand, SHA256 SPKI hashes are recommended in newer documents like HPKP.


Thanks! Maybe I'll track both for a bit and then decide which to keep.

1 Like