ECDSA certificate letsencrypt from csr HSM Luna Client

There's nothing private in a CSR file, it's just your domain name and a signature.

This program uses the same parser that Let's Encrypt uses, but it's going to require a bit more digging than just running it to identify what is actually wrong in the ASN.1 data.

1 Like

I spent the last couple of hours trying to figure this out, but ASN.1 is pretty complicated and I haven't worked with it in depth before.

What I suspect is that the CSR is slightly malformed due to missing the field which would contain the set of certificate request attributes/extensions:

Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}

From the man page for openssl req:

More precisely the Attributes in a PKCS#10 certificate request are defined as a SET OF Attribute . They are not OPTIONAL so if no attributes are present then they should be encoded as an empty SET OF . The invalid form does not include the empty SET OF whereas the correct form does.

An absence (empty set) of attributes should be denoted by a 0xA0 0x00 tag and length (or other compatible tags I guess), following the subject and subjectPKInfo in the certificate request.

Let's Encrypt's ASN.1 parser is erroring on the missing empty set of attributes, because (I believe) it is written in a way where the field is not optional. I think this is probably the correct behavior for a parser which strictly follows RFC2986.

ZeroSSL probably uses a different CSR parser which is not as strict.

I assume you are using some HSM software to generate this CSR. I would probably ask the vendor about this. If you can possibly include some kind of attribute/extension into the CSR (such as Subject Alternative Name), that would avoid the problem as well.

Hope that helps.


Perhaps the lack of Subject Alternate Name has something to do with this.

1 Like

Hi @_az @rg305 Thank you so much! We will investigate this with vendor.

1 Like

Hi @_az
It was a bug in the latest version of the cmu utility.
Attribute a0:00 was lost

Now we are able to get the certificate.

You are batman


but our story with obtaining ECDSA did not end. We set all the parameters for obtaining an ECDSA certificate, and as a result we get RSA certificate. How to diagnose this issue?

Please show your settings.

1 Like
./ --signcsr --csr /tmp/test.csr --dns dns_cf  --server letsencrypt --keylength ec-256

Can you show this file?

1 Like


You should include:

1 Like

I have tried all the options. did not help
--keylength ec-256

./ --issue --signcsr --csr /tmp/test.csr --dns dns_cf --server letsencrypt

1 Like


./ --issue --csr /tmp/test.csr --dns dns_cf --server letsencrypt

1 Like

Try this just to compare CSR files:

./ --issue -k ec-256 --domain "justa.test" --server
openssl req -text -noout -in /root/
1 Like

syntax error

Usage: --issue --domain <domain.tld> --webroot

this procedure is not from a HSM scr file ))

Based on the information you've given I presume that you're able to submit a CSR with an EC key just fine, but the resulting certificate you get back is signed by Let's Encrypt R3, which has an RSA key.

That's because Let's Encrypt currently only issues from its ECDSA intermediate (E1) for allow-listed accounts. Please see these links for more information:

Also, based on data you've already issued 5 duplicate certificates this week, which means that you're now rate limited. Please use the staging enviroment for testing.

I should also note that the certificates you have issued are in fact ECDSA certificates. Let's Encrypt does not and cannot change the key type you use (it can only accept or refuse them). Therefore your certificates are perfectly fine ECDSA. They're just signed by an RSA intermediate. Let's Encrypt does offer a full ECDSA chain for selected accounts, see the links above.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.