ECDSA certificate letsencrypt from csr HSM Luna Client


I'm trying to generate an ECDSA certificate via acme script from a csr file. And I see an error

[Thu Apr 14 01:15:35 CDT 2022] POST
[Thu Apr 14 01:15:35 CDT 2022] _post_url=''
[Thu Apr 14 01:15:35 CDT 2022] _CURL='curl --silent --dump-header /root/ -L -g '
[Thu Apr 14 01:15:35 CDT 2022] _ret='0'
[Thu Apr 14 01:15:35 CDT 2022] code='400'
[Thu Apr 14 01:15:35 CDT 2022] Sign failed, finalize code is not 200.
[Thu Apr 14 01:15:35 CDT 2022] {
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Error parsing certificate request: asn1: syntax error: sequence truncated",
"status": 400
[Thu Apr 14 01:15:35 CDT 2022] _on_issue_err

Whose side is the question?

Question about the correct filling of attributes?cmu requestcertificate
Question for acme script?
Question for letsencrypt?

1 Like

The CSR file was incorrectly generated.

1 Like

The same csr works fine for ZeroSSL. What is the fundamental difference between letsencrypt and ZeroSSL?
Utility cmu skips the country attribute when generating the file. Is this attribute required for letsencrypt?cmu requestcertificate

Easiest way to find out is to post the CSR.

Go's CSR parser doesn't like something about yours, and the only way to know for sure is to take a look at its contents.


could you give a parser that can be trusted? I am using the parser
And this parser doesn't like the country field

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