ECDSA certificate issuance failure in both staging and production

[robmoss2k]

I'm having some difficulty with ECDSA certificates today. I'm using the acme-tiny script to issue an ECDSA and an RSA certificate with 11 additional SANs. Testing against the staging server saw the ECDSA certificate rejected but the RSA certificate issued. I found an old thread which said there was a configuration problem on the staging server and that staging was failing to issue certificates with ECSDA keys but production was OK, so I hoped for the best and tried again with production. Same problem.

Furthermore, I can't see anything in the logs on https://crt.sh/ for either of these two subject names:

crt.sh | test.ac-grandoptical.com

crt.sh | qa.ac-grandoptical.com

The error I'm getting on the console when using the script is:

Parsing account key...
Parsing CSR...
Registering account...
Registered!
Verifying test.filialnetzde.iweardirect.com...
test.filialnetzde.iweardirect.com verified!
Verifying test.ac-grandoptical.com...
test.ac-grandoptical.com verified!
Verifying test.butikk.interoptiklinser.com...
test.butikk.interoptiklinser.com verified!
Verifying test.lojas.multicontact.pt...
test.lojas.multicontact.pt verified!
Verifying test.interoptiklinser.com...
test.interoptiklinser.com verified!
Verifying test.brillelandlinseservice.com...
test.brillelandlinseservice.com verified!
Verifying test.al-generale-optique.com...
test.al-generale-optique.com verified!
Verifying test.magasins.al-generale-optique.com...
test.magasins.al-generale-optique.com verified!
Verifying test.eyego.pt...
test.eyego.pt verified!
Verifying test.lojas.eyego.pt...
test.lojas.eyego.pt verified!
Verifying test.multicontact.pt...
test.multicontact.pt verified!
Verifying test.magasins.ac-grandoptical.com...
test.magasins.ac-grandoptical.com verified!
Signing certificate...
Traceback (most recent call last):
File "/root/acme_tiny.py", line 196, in
main(sys.argv[1:])
File "/root/acme_tiny.py", line 192, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)
File "/root/acme_tiny.py", line 161, in get_crt
raise ValueError("Error signing certificate: {0} {1}".format(code, result))
ValueError: Error signing certificate: 400 {
"type": "urn:acme:error:malformed",
"detail": "Error parsing certificate request",
"status": 400
}

Is anyone else able to get a certificate signed using ECDSA at the moment, or is it just me? I'm unsure whether to bug LE or acme-tiny at the moment, but I'm guessing it must be LE as it's working for RSA keys. The ECSDA and RSA CSRs are identical apart from the private key used to create them (i.e. same openssl.cnf).

[Neilpang]

I just tried with acme.sh .
There is no problem with ECDSA cert.

Please try again.

[robmoss2k]

Still got the same problem upon retry. Here’s the CSR, in case it helps:

-----BEGIN CERTIFICATE REQUEST-----
MIICsDCCAlcCAQAwdzELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFu
Y2hlc3RlcjENMAsGA1UEBwwEQnVyeTEZMBcGA1UECgwQV2VhdmVhYmlsaXR5IEx0
ZDEhMB8GA1UEAwwYdGVzdC5hYy1ncmFuZG9wdGljYWwuY29tMFYwEAYHKoZIzj0C
AQYFK4EEAAoDQgAEpn1gKnRNo/YG/uMV0RmhmUU3XL89wwevtWLk/PQbC3IDyn7M
RTlqUYMnSxCiw6DVQVSLu4aENYtW2t4boFvDfaCCAX8wggF7BgkqhkiG9w0BCQ4x
ggFsMIIBaDCCAUwGA1UdEQSCAUMwggE/ghx0ZXN0LmFsLWdlbmVyYWxlLW9wdGlx
dWUuY29tgh90ZXN0LmJyaWxsZWxhbmRsaW5zZXNlcnZpY2UuY29tgiB0ZXN0LmJ1
dGlray5pbnRlcm9wdGlrbGluc2VyLmNvbYINdGVzdC5leWVnby5wdIIhdGVzdC5m
aWxpYWxuZXR6ZGUuaXdlYXJkaXJlY3QuY29tghl0ZXN0LmludGVyb3B0aWtsaW5z
ZXIuY29tghN0ZXN0LmxvamFzLmV5ZWdvLnB0ghp0ZXN0LmxvamFzLm11bHRpY29u
dGFjdC5wdIIhdGVzdC5tYWdhc2lucy5hYy1ncmFuZG9wdGljYWwuY29tgiV0ZXN0
Lm1hZ2FzaW5zLmFsLWdlbmVyYWxlLW9wdGlxdWUuY29tghR0ZXN0Lm11bHRpY29u
dGFjdC5wdDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DAKBggqhkjOPQQDAgNHADBE
AiBiG3iFjFFsSaqoY8e3QYyJPOLSAITO2mLRKtA+pCYhMQIgRvTVzU2H3Ynndle7
kjXUymZU8FV09MblsZ0Xiad+0V4=
-----END CERTIFICATE REQUEST-----

[Osiris]

You should use the prime256v1 curve for the 256 bit keys.

[pfg]

Hmm, the CSR seems to indicate that you’re using the secp256k1 curve, which I believe is not supported (NIST P-256 would work).

I’m pretty sure, however, that you’d get a more specific error message if that was the problem. There might be more than one problem. Either way, this is probably worth checking just in case.

Comparing your CSR with a known-good CSR shows a couple of other differences, though there’s nothing that looks like it should be causing this (especially given that it seems to work with a RSA CSR created based on the same config). If changing the curve doesn’t fix the issue and you’re willing to dig into this, try removing/changing them one by one to see what’s causing the error:

• The Version field seems to be set to zero, the known-good CSR has this set to 2. (I think this might be related to the openssl version).
• The known-good CSR does not set any Subject field other than CN. This should be fine and the CA server should just ignore those fields.
• The value of your CN field contains a domain that’s not included as a Subject Alternative Name. I’m not sure if the CA server will “fix” this.
• The known-good CSR does not include a Basic Constraints and Key Usage extension. Again, I don’t see why this should be causing any issues, but I’ll include it anyway for completeness sake.

[robmoss2k]

To confirm, switching from the secp256k1 curve to the prime256v1 curve makes things work flawlessly - thanks very much! I wasn’t aware that only certain curves were supported. Seems strange that prime256v1 and secp384r1 are supported and secp256k1 isn’t - is there a rationale behind that?

[My1]

talking about that, is there a list of what curves work?
possibly with all known names because it gets confusing quickly.

[Osiris]

P-256 and P-384.

Naming isn’t very logical indeed. Use the Google Luke!

[My1]

well I havent found yet a nice list of all the different names used by the implementation

well I think that more work. I mean prome256v1 works, secp384r1, following the logic then secp256r1 should technically work as well so we would have p256, p384 and prime256…

also why not do p521, it’s longer and therefore potentially longer secure than p384

[Osiris]

Only NIST curves are allowed in certs according to the CA/B. secp256r1 isn’t a NIST curve.

[My1]

okay I thought P256 is secp256r1 because of the same naming scheme of p384 (secp384r1) and that prime256 is something different.

what’s what I mean the names are way too scrambled and nowhere there’s a proper list of what is what

[wangqiliang]

SECP 521 R1 is too long and no longer used in major browsers and on boulder.

[Osiris]

Firefox, Opera and Safari support it.?

[The_Decryptor]

Firefox is in the process of removing it and replacing it with x25519, Opera would presumably do whatever Chrome (Which also replaced it with x25519) does since they share a common core.

As for Safari, who on earth knows what Apple is doing.

Edit: And Edge doesn’t support it at all, but they’re looking at other curves instead of x25519 I think.