ECDSA certificate letsencrypt from csr HSM Luna Client

Hi

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='https://acme-v02.api.letsencrypt.org/acme/finalize/430523540/79468073200'
[Thu Apr 14 01:15:35 CDT 2022] _CURL='curl --silent --dump-header /root/.acme.sh/http.header -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.

2 Likes

could you give a parser that can be trusted? I am using the parser https://decoder.link/
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.

7 Likes

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

4 Likes

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
./acme.sh --signcsr --csr /tmp/test.csr --dns dns_cf  --server letsencrypt --keylength ec-256

Can you show this file?

1 Like

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBLjCB1AIBADByMSkwJwYDVQQDEyBjeHN0dWRpby1zdGFnaW5nLmNsYXJhYnJp
ZGdlLm5ldDELMAkGA1UEBhMCVVMxFDASBgNVBAoTC2NsYXJhYnJpZGdlMREwDwYD
VQQIEwhWaXJnaW5pYTEPMA0GA1UEBxMGUmVzdG9uMFkwEwYHKoZIzj0CAQYIKoZI
zj0DAQcDQgAEaoTT83lMaWwNijbsOUmweM1S/rpWNWH4KLMHFo/JizWJx0+CFXBE
lpMScRRC9ynRFZbcmePwdNEov7caWA3ZGqAAMAwGCCqGSM49BAMCBQADRwAwRAIg
Hlu+aItHhNU4aHFarukdbPheE4ZfvlidvYKqJV4RAx4CIHXYxx7VfBoKpOfZwKJu
nRTJ/ef45fgN7OI8kGFIpbSV
-----END NEW CERTIFICATE REQUEST-----

You should include:
--issue

1 Like

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

Try:
./acme.sh --issue --signcsr --csr /tmp/test.csr --dns dns_cf --server letsencrypt

1 Like

Done
image

Try:
./acme.sh --issue --csr /tmp/test.csr --dns dns_cf --server letsencrypt

1 Like