ECDSA certificate issuance failure in both staging and production


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 for either of these two subject names:

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

Parsing account key…
Parsing CSR…
Registering account…
Verifying verified!
Verifying verified!
Verifying verified!
Verifying verified!
Verifying verified!
Verifying verified!
Verifying verified!
Verifying verified!
Verifying verified!
Verifying verified!
Verifying verified!
Verifying verified!
Signing certificate…
Traceback (most recent call last):
File “/root/”, line 196, in
File “/root/”, line 192, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER,
File “/root/”, 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).


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

Please try again.


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



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


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. :smile:


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?


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


P-256 and P-384.

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


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


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


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


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


Firefox, Opera and Safari support it.?


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.


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