If I have multiple different servers (for different purposes, not redundant), should I mirror the account credentials across them, or can I have multiple accounts on the allow-list?
2 Likes
@maxh, I suspect, there are pros and cons for each.
If there aren't too many systems (single digits), then both would work and it shouldn't be too much trouble to manage either way.
[there are no wrong answers - sometimes there are wrong decisions... (this shouldn't be one of those)]
2 Likes
You can have multiple accounts on the allow-list. If you just have a handful of accounts, I'm assuming that's easiest and perhaps marginally more secure (just because account keys aren't being transferred/re-used).
The ACME spec states that "Compromise of the private key of an account key pair has more serious consequences than compromise of a private key corresponding to a certificate." While I (and others) think that may be overstating things somewhat, it is probably reasonable to think of securing your account keys as being similar to securing your certificate keys. So, if you're fine with copying your certificates keys to all your servers from a central location (as I know some people do), then I think doing the same thing with account keys is perfectly reasonable. If you use the "a certificate key never leaves the system it was created on" sort of approach, then doing the same thing with your account keys also seems perfectly reasonable to me.
3 Likes
I went ahead and requested the second account be added, and… the form explicitly asks if you want to add multiple accounts. So I guess that answers it too.
2 Likes
For you who have enabled ECDSA, have you noticed problems with some clients?
It seems I can't find my correct account info. None of the fields match Finding Account IDs - Let's Encrypt information.
I am using certbot 1.19.0 and this is the info I have:
/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/de0e5eaceee6f3ea13952a5cad683ccc/regr.json
{"body": {}, "uri": "https://acme-v01.api.letsencrypt.org/acme/reg/8564122"}
(in the v02-folder the subdirectory "directory" is just a symbolic link to "/etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory")
/etc/letsencrypt/renewal/wiki.tnonline.net.conf
# renew_before_expiry = 30 days
version = 1.19.0
archive_dir = /etc/letsencrypt/archive/wiki.tnonline.net
cert = /etc/letsencrypt/live/wiki.tnonline.net/cert.pem
privkey = /etc/letsencrypt/live/wiki.tnonline.net/privkey.pem
chain = /etc/letsencrypt/live/wiki.tnonline.net/chain.pem
fullchain = /etc/letsencrypt/live/wiki.tnonline.net/fullchain.pem
# Options used in the renewal process
[renewalparams]
account = de0e5eaceee6f3ea13952a5cad683ccc
rsa_key_size = 4096
authenticator = webroot
server = https://acme-v02.api.letsencrypt.org/directory
webroot_path = /var/www/domains/wiki.tnonline.net/htdocs,
preferred_chain = ISRG Root X1
[[webroot_map]]
wiki.tnonline.net = /var/www/domains/wiki.tnonline.net/htdocs
Can it be confirmed which ECDSA curves are supported for leaf certificates? Unless I've missed where they are documented. I can see that secp384r1 is used for the root and intermediates, with 256 for the test sites. Just want to confirm that 256 and 384 are supported. I'm assuming secp521r1 is not, given it's removal from Chrome.
1 Like
Based on the CP, secp256r1, secp384r1 and secp521r1 are allowed.
However, I believe that even though it's stated in the CP, secp521r1 isn't actually supported by LE. At least that's what the acme.sh documentation states, haven't checked lately. P-256 and P-384 are definetly both supported.
Edit: Having looked at boulder source code, the above is correct (P-521 unsupported, the other two supported).
5 Likes
You can use secp256r1 or secp384r1 for certificates, and you can even also use them for account keys. But I ran into some odd issues when using secp384r1 for my account key, in that somehow the spec requires signatures on it to use SHA-256 but at least some libraries don't see secp384r1/SHA-256 as a "secure" combination since (at least according to some standard or other?) the hash "should" be at least as long as the key, so the acme.js library I was using only supported secp384r1/SHA-384. So I couldn't actually sign messages to send commands using that library when using secp384r1 as my account key, and I think that if you use secp384r1 for your certificate key you may run into some similar issues if you ever need to revoke it using that certificate key. (That is, you should be able to revoke it using a non-secp384r1 account key, but you may not be able to revoke it using the certificate private key itself.)
It may just be a weird quirk of the library that I was using, and probably isn't as much of an issue for certificate keys, but I just somehow got the impression that usage of secp384r1 through ACME just isn't as tested/robust as the more "common" options (and maybe even needs some clarifications to some specifications). I don't think that there's any reason that it shouldn't work, just that in practice it may be weirder than you would expect, just because it isn't as used by others. I'd suggest playing around in the staging environment with it for a while before using it for a "real" production certificate, is I guess all I'm really trying to say.
4 Likes
I just tried this with acme.sh and all seemed to work with with 384 keys (issuing, revoking, account keys).
It is generally correct that - when signing stuff - certain hash function outputs are "suitable" for key sizes, and it generally is implemented/standardized this way (e.g TLS usually uses SHA256 on 128 bit keys and SHA384 on 256 bit keys).
RFC6979 also explains this (when talking about signatures):
Signature generation uses a cryptographic hash function H and an
input message m. The message is first processed by H, yielding the
value H(m), which is a sequence of bits of length hlen. Normally, H
is chosen such that its output length hlen is roughly equal to qlen,
since the overall security of the signature scheme will depend on the
smallest of hlen and qlen; however, the relevant standards support
all combinations of hlen and qlen.
Still, I disagree with the decision of the authors of that library.
- The RFC8555 standard specifically says to use SHA-256. It doesn't say "use only keys of length n", it says "use SHA-256, no matter the key". The authors are violating the standard here by implementing it differently.
- While I'm new to all that JWK stuff, there seems to be no signatures involved - it's just a hash for the public key. This means the key in this context is just the message m, and the output length of a hash function should not depend on the length of your message - because that makes no sense and does not help you in any way. If you "don't want to lose entropy", well then why do you hash at all? The authors would have been correct if this were a signature, but not for a simple message hash. I also argue that the standards people knew what they're doing - much more than the author of some library with highly contradictory statements.
About testing, maybe some libraries don't test as good as others. I wouldn't generally say that P-384 keys are "less tested" - after all, LE uses them themselves and their issuance handles them just fine.
4 Likes
I have registered 2 weeks ago in ECDSA-chain program, there was no confirmation on email. Tried to register again a few days ago - no reply either.
Yesterday requested for the new wildcard certificate via DNS challenge - the new one came with the old RSA-chain.
The certbot command is like this:
certbot certonly --agree-tos --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory -d '*.my.domain' ,'my.domain' --csr ec.csr
May I am doing something wrong?
You're probably just not being patient enough. If you haven't received the confirmation email yet, you probably aren't yet enrolled in the ECDSA-signing program. It's a manual process, and I suspect the Let's Encrypt staff has been pretty busy over the past couple weeks.
3 Likes
Thanks for your kind reply. Yes, maybe you're right, I need waiting ..
4 Likes
I think I managed to convince the authors of this library to rethink their current implementation regarding JWK thumbprint.
I have only played around with the code a little, so I don't know if patching the thumbprint is all it needs for EC-384 keys. Still if it gets fixed, it's one less issue to worry about.
3 Likes
Thank you! I feel like I know just enough about crypto to be dangerous (and thus I know to just use existing libraries and not try to write them myself), so I appreciate you digging into the thing that didn't work for me. (It's not like I really needed a P-384 account key or anything, but I'll probably be much more excited than I ought to be if I get it working in my cobbled-together Node.js AWS Lambda "client".)
2 Likes
Apologies, that's on me! They will be going into this week's release, I will send an email when they are live in production!
-JP
4 Likes
Thank you very much, Jenessa.
Yes sure, I and the others will wait as long as necessary. Expired DST Root CA X3 added some works for Letsencrypt....
One more question: unfortunately I have to use some RSA certificates on my servers for old Androids. With the new ECDSA-signing program will the new RSA certificates be signed by the new intermediary?
2 Likes
Only CSRs with ECDSA public keys will be signed by the ECDSA intermediate E1. RSA CSRs will be signed with R3, just as they are now. The only thing changing is that ECDSA containing CSR will be signed with E1 instead of R3.
5 Likes
Very clear. Thank you very much!
3 Likes
I submitted the form listed at https://forms.gle/ftKeqkj6AJgXUDPJ8 a couple weeks ago, but have yet to receive any confirmation.
Please let me know if I should submit it again, or wait a bit longer.
Thanks!
5 Likes