so the ultra paranoid p521 doesnt? too bad.
1 Like
From the first tests currently nothing work on staging, so no longer an unmarshall issue
ECDSA curve P-384 not allowed
ECDSA curve P-256 not allowed
ECDSA curve P-521 not allowed
2 Likes
Now it works on staging 
1 Like
Sample result for an EC Certificate (T rating because of statging)
This show that the certifcate works
https://dev.ssllabs.com/ssltest/analyze.html?d=ec384.suche.org&hideResults=on
3 Likes
Yup working here too --csr and webroot-path webroot-map errors thanks to an assist from @Osiris
1 Like
@jsha is there already an timeline when this new feature will become available in produktion ?
1 Like
would be really nice to know.
then I can get close-to-tinfoil encryption more or less (rather less) easily.
1 Like
suspect need some documentation done first
1 Like
Well, as long as the official client doesnāt support it, you might say itās an easter egg if itās pushed to production without documentation 
After all, itās not like the --csr switch is documentated in the User Guide 
1 Like
true, though when i mean production I mean on client side support too
1 Like
@Osiris No for the CA the definition is the protocol. And there was no place in the protocol that say only rsa may be used. So it is not an easter egg.
1 Like
I donāt quite understand what you mean with thatā¦ I just meant if staging would now be pushed to production, it would be a hidden featureā¦ Or no, not even an hidden featureā¦ Perhaps you mean that. Before this, ECDSAās simply werenāt implemented and Boulder responded with an error message, but thereās not really a reason to deny ECDSA keysā¦ So no documentation would be required, unless itās somewhere stated only RSA keys can be usedā¦
1 Like
Just a question about the ACME protocol with RSA and ECC.
Now (in staging) there is only a RSA signing key, so if I send a CSR i can get
- a RSA-signed RSA certificate
- a RSA-signed ECC certificate
When (hopefully) LE will have an ECC based signing key there will be 4 possibilities:
- a RSA-signed RSA certificate
- a RSA-signed ECC certificate
- an ECC-signed RSA certificate
- an ECC-signed ECC certificate
1 and 4 will be the most popular ones, but will 2 and 3 be supported?
If no the server can simply look into the CSR and give the client a RSA-signed certificate if the public key is RSA (1) and an ECC-signed certificate if the public key is ECC (4).
If yes the ACME protocol need a flag in order to let the server know if the client want a RSA-signed certificate or an ECC-signed certificate.
2 Likes
Our current thinking is that 2 and 3 won't be supported, and so no flag is needed in the ACME protocol. Interested in hearing about situations where 2 or 3 would be needed, though!
2 Likes
I personally donāt see any.
The only thing I see, if the current configuration on staging (1 and 2 allowed) goes live, when LE will have an ECC root (so 1 and 4 allowed) the intermediate certificate will change after first renew (from RSA intermediate to ECC), so one must be sure to use the intermediate certificate returned by the ACME protocol (this is a good practice anyway because sooner or later the intermediate certificate will expire).
Do you plan to allow 2 temporarily while waiting for a trusted ECC root?
2 Likes
Yep, that's what we're planning on.
5 Likes
ECDSA account key support is now available on the staging server.
2 Likes
Nice!
Too bad my lack of coding skills wonāt help https://github.com/letsencrypt/letsencrypt/issues/2209 
1 Like
You see that it was already implemented in https://github.com/letsencrypt/boulder/pull/1357 ?
1 Like
Boulder vs. client.
The issue Iām referring to is support in the client. The PR youāre linking to is for Boulder support.
1 Like