Continuing the discussion from Elliptic Curve Cryptography (ECC) Support:
Could you provide the series of commands you're using to reproduce? Thanks!
Ofcourse:
osiris@server custom $ openssl ecparam -genkey -name secp384r1 > privkey-p384.pem
osiris@server custom $ openssl req -new -sha256 -key privkey-p384.pem -subj "/CN=le-test-04.example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:le-test-04.example.com")) -outform der -out csr-p384.der
osiris@server custom $ letsencrypt certonly --text -vv --agree-tos --test-cert --email ${email} --csr /etc/letsencrypt/custom/csr-p384.der --webroot --webroot-map '{"le-test-04.example.com": "/var/www/vhosts/le-test-04.example.com/htdocs"}'
Same goes for all other curves, just chose another one from openssl ecparam -list_curves in the first command 
I don’t know if the complete error log for the unmarshall error is very helpful? The error is raised in _check_response in /acme/client.py (line 552) where it gets the HTTP 400 error response from Boulder… In exactly the same client phase of the ECDSA curve not allowed error… Guess that makes sense if you see where the unmarshall error is raised in Boulder: https://github.com/letsencrypt/boulder/blob/staging/wfe/web-front-end.go#L716 Just before GoodKey() 
Maybe i can check it with my java client tonight, but @Osiris can you provide from the debug log where the request is visible with the public key that gets rejected ?
Hi, i took the CSR from your debug log but no online tool where ableto decode the CSR.
Not even the ASN.1 decoder so something seems to be wrong. Also if i do an decode and rencode base64
with the default charset it did not work. My thought was an problem with maybe compressed curve points.
I will try it not for my own implementation.
https://www.sslshopper.com/csr-decoder.html
https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp
http://lapo.it/asn1js/
Did you account for the Base64 variant used by JSON Web Signature?
Yes “Also if i do an decode and rencode base64 with the default charset it did not work.”
Just replace _ with /, - with + and don’t forget to add == for padding, because OpenSSL requires it… It’s exactly the same as the PEM CSR I fed into Let’s Encrypt
Same with my implementation https://acme-staging.api.letsencrypt.org/acme/new-cert independed of the ec size
ECDSA curve P-384 not allowed
ECDSA curve P-256 not allowed
ECDSA curve P-521 not allowed
So @jsha please check what happend on staging.
Very good paper of speed comparison between RSA and ECDSA for webserver with different use cases.
1 Like
Too bad “Table 1: Public Key Cryptographic Operations” (and therefore the rest of the tests) doesn’t consider ECDSA public key signed with an RSA intermediate cert certificates like LE will generate 
1 Like
I’ve tested with ECDSA P-256, and get the same error. It seems to me like the config change in staging hasn’t been made. Thinking about it, since the config defaults to RSA only, if there were a typo in the config there’d be no error.
The key policy used gets logged on startup, so might want to check there. @jsha
3 Likes
Yep, I agree the change didn't take effect on staging, looking into it some more now.
2 Likes
Okay, we found the cause (a comma in the wrong place in the config), and staging should now have ECDSA properly enabled. Thanks!
1 Like
Yes! It works 
osiris@server custom $ openssl x509 -noout -text <0001_cert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
fa:69:54:6a:23:ba:b5:80:79:a8:20:f3:a2:c1:74:9b:8c:e9
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=happy hacker fake CA
Validity
Not Before: Jan 15 23:39:00 2016 GMT
Not After : Apr 14 23:39:00 2016 GMT
Subject: CN=le-test-04.example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:f2:4b:ac:f6:71:3e:2a:62:0c:ca:d7:17:9e:94:
6e:28:9f:ff:26:14:bd:79:e0:6c:fb:67:6d:57:80:
b3:90:6a:26:b5:4f:d2:0f:64:76:e5:fc:ee:9f:bd:
e6:b8:46:c6:db:d3:11:35:8f:f1:42:2e:74:92:d7:
a2:b6:42:3a:c1:bb:70:f9:a5:87:3b:0e:01:2a:23:
3f:4d:da:7e:07:36:3d:0c:85:6e:98:03:f9:b4:28:
bf:b6:98:02:68:00:e8
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
7B:55:9F:88:60:A5:B3:BA:FD:E3:AC:C6:8F:41:EE:06:E5:26:59:BE
X509v3 Authority Key Identifier:
keyid:FB:78:4F:12:F9:60:15:83:2C:9F:17:7F:34:19:B3:2E:36:EA:41:89
Authority Information Access:
OCSP - URI:http://ocsp.staging-x1.letsencrypt.org/
CA Issuers - URI:http://cert.staging-x1.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:le-test-04.example.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
Signature Algorithm: sha256WithRSAEncryption
bb:05:86:c3:7b:92:5d:1b:04:fe:71:53:d0:71:4d:5e:1a:ff:
21:7a:bd:da:be:13:a6:c6:c1:91:c0:85:a8:cf:36:28:f1:d3:
a1:81:dc:c9:16:39:47:ea:7a:2c:9f:a7:01:01:00:b9:bc:40:
1c:aa:e9:8d:2f:33:76:0c:b3:c3:16:81:d3:2d:ee:26:3b:82:
e9:78:bf:71:11:67:7c:e2:a5:62:d7:1f:7f:ac:88:ec:28:99:
e4:40:5c:a0:16:c8:37:b8:22:ac:fb:89:19:3f:07:d4:22:d9:
7a:93:a6:0b:48:08:ba:f9:09:3d:4d:2d:24:47:c4:96:41:73:
7d:8f:8b:69:a5:a7:ae:84:80:52:dd:c2:34:a2:f9:95:72:d7:
5d:1d:71:38:96:17:dc:d4:0a:fa:cf:a2:8d:16:3a:8a:c2:0d:
c5:7e:74:8b:c5:ad:b1:4d:14:c6:c6:58:ad:68:49:b5:41:c1:
e6:01:5a:7a:27:09:2c:4a:45:95:bb:42:de:84:4e:de:ac:8b:
dd:94:a2:af:28:4a:e7:be:18:46:d7:c6:b0:d5:1f:30:a0:5f:
1c:cf:90:c3:73:d0:06:a5:10:2f:dd:53:26:ec:c6:71:c5:3e:
17:1f:b9:d3:6f:03:0b:32:6c:95:d5:ee:d3:7f:28:e0:48:ce:
a0:c1:9a:22
osiris@server custom $
Updated ACME from commit ebfcd90d729c39b004b1ac851a6e1a37a4c092fe to 10214e26686a362896357568bbb94b34a55a86ae and the LE client itself from 7e741f9b1acc24011de49d9f435af5b929b15a5f to 10214e26686a362896357568bbb94b34a55a86ae. Those versions work.
secp521r1 confirmed not working (as intended by LE officials unfortunately): Invalid key in certificate request :: ECDSA curve P-521 not allowed, prime256v1 works splendidly (just as secp384r1 above) and results in “working” (happy hacker fake CA ) certificate.
Other curves like brainpoolP512r1 still results in an The request message was malformed :: Error unmarshaling certificate request error message from Boulder.
Any more tests I could do @jsha ?
There was only one pull request with 6 commits merged since the branching off of the master branch for the 0.2.0 release, so I guess the 0.2.0 release won’t have the bug(s) I had earlier and will do fine The 0.1.1 release… I dunno… My ACME release was from Dec 17th and the first 0.1.1 was released on the 16th… My guess is the 0.1.1 release will not work with ECDSA CSR’s.
1 Like
acmetool’s ECDSA support is working nicely.
Since the staging server doesn’t have support for ECDSA account keys yet, one needs to create an RSA account key and then change the key type preference to ECDSA:
$ sudo acmetool quickstart
$ sudo acmetool quickstart --expert
$ sudo acmetool want foo.example.com
1 Like
[quote=“Osiris, post:15, topic:8809”]
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
[/quote]RSA certificates should have both “Digital Signature” and “Key Encipherment” key usages, but ECDSA certificates should have only “Digital Signature”.
Glad it’s not production…
1 Like
Hmm, interesting… But the only source for this I can find is an (old) IETF draft: Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public Key Infrastructure Certificates (draft-ietf-pkix-ipki-ecdsa-02.txt): Section 3.1.3 (Key Usage Extension in ECDSA certificates).
However, this draft has never reached a RFC status and is expired.
Do you have another source?
1 Like
From IETF mailing list:
https://www.ietf.org/mail-archive/web/tls/current/msg10179.html
It mentions “key agreement”, but research have shown such bit allowing TLS server to be impersonated under certain circumstances, so it MUST NOT be set.
1 Like
Would be nice to habe more Details about this point.