Last updated: May 3, 2021
ECDSA Root and Intermediates
We are issuing certificates from our production ECDSA intermediate to allow-listed accounts. There is no planned date for removing the allow-list.
I hope they finally fix it?
Or will EC certificates be signed by RSA after that anyway?
The work on ECDSA isn't really related to the DST Root CA X3 expiration (except so far as certificates signed by the ECDSA hierarchy don't include the ISRG-Root-X1-signed-by-DST-Root-CA-X3 cert in the chain returned by the ACME server). Currently, for most accounts, certificates with ECDSA public keys are signed by the RSA intermediates, but you can request to have your account added to the allow-list in order to have them signed by the ECDSA intermediates instead. Eventually (though no specific date is yet set), all certificates with ECDSA public keys will be signed by the ECDSA intermediates while all certificates with RSA public keys will continue to be signed by the RSA intermediates.
Thank you for your reply.
Can I ask you to sign my certificate https://www.immuniweb.com/ssl/ilya.pp.ua/Pyt5Wrru/ with ECDSA in more detail?
And is it free?
Please read ECDSA availability in production environment
Thank you! 
I'm having trouble filling out the form with the "ACME account ID URL" definition.
Do I understand correctly that if I never renew the certificate through dehydrated, but generate a new private key each time, and after that completely delete all the side files except the private key, signature request, and signed certificate, then this identifier changes every time, and I will not be able to use this service?
I'm having trouble filling out the form with the "ACME account ID URL" definition.
Do I understand correctly that if I never renew the certificate through dehydrated, but generate a new private key each time, and after that completely delete all the side files except the private key, signature request, and signed certificate, then this identifier changes every time, and I will not be able to use this service?
I'm not that familiar with dehydrated, but I'm assuming you're not actually registering a new account key with your email address and accepting the terms every time you get a certificate? I suppose you might be, but that sounds really unusual to me. I'm digging through their documentation, is it maybe stored somewhere in /etc/dehydrated/config/accounts?
I think I figured it out.
~/dehydrated/accaunts/dir_name/(accaunt_id.json, account_key.pem, registration_info.json)
dir_name, oddly enough, is always the same, although I delete ~/dehydrated after running the script
Isn't dir_name the same identifier?
I filled out the form, thought I should get a confirmation email, but nothing came.
I got a new certificate through dns. but it is still signed Signature algorithm SHA256withRSA.
Does it take a while for this to work or did I do something wrong?
It's probably the URL in that account_id.json file, yes, assuming it looks like the URL in the documentation that starts with https://acme-v02.api.letsencrypt.org/acme/acct/ followed by a number.
From the announcement,
We'll be processing allow-list requests in batches, most of which will go out Thursday with our normal Production updates.
So you'll get an email once they update the list in their server configuration. Right now it seems to be a pretty manual process for the Let's Encrypt staff, and I'm guessing there's a lot of scrutiny around them changing their configuration files for the servers.
Thank you, now I understand exactly how to determine this identifier, it is in ~/dehydrated/config/accounts/dir_name/account_id.json (id:number).
But unfortunately, as I assumed, this number keeps increasing when I get a new certificate, at least if I delete all the side files in my registration script, so I can't use this list.
And more questions regarding the intermediate certificate.
1 I don't understand why this id is needed, as well as all the other files except the signed public key?
2 I also don't understand if you have the ability to sign ECDSA keys with the correct intermediate key, why don't you do that for everyone, keep signing with RSA?
I thought the problem was that you were waiting for the intermediate certificate to expire, but now I don't understand why you delay it if you already have the correct certificate?
3 What's the worst thing that could happen if you start signing ECDSA keys with the ECDSA algorithm?
So… why are you deleting your account registration, then? That's a very unusual thing to be doing.
The id is your ACME account. Your account is used for sending expiration notices, and can be used to "manage" your certificates of a sort in the sense that it can revoke certificates that have been created by it, and if your client complete a challenge proving ownership of a domain name you don't need to repeat that challenge for 30 days if used by the same account. I wouldn't say that using a new account for each certificate renewal is wrong, really, it's just unusual, and it's not clear to me what you're trying to gain by doing it.
Well, signing with the ECDSA intermediates is really new, and just started last month. They're rolling out the feature gradually, wanting people to opt-in first.
I'm not sure why you're talking about "correct", which may be some terminology confusion. There's nothing incorrect about signing ECDSA-public-key certificates with RSA intermediates, and has been supported by Let's Encrypt for many years. While getting the certificate signed by an ECDSA intermediate might help some devices be able to complete the handshake quicker or with less resources, it's not any more or less secure (to my understanding at least).
Well, I think that's part of what they're trying to find out by letting people opt in to be the first testers. Though in general, they'd want to give as much notice as they can before changing what intermediates they are using to sign. But somebody might find that a device that needs to connect to them can't process, say, P-384-based signatures even though they thought it would. (For instance, my understanding is that there are some old versions of Android that support P-256 signed by an RSA key but not P-256 signed by a P-384 key, but I'm far from an expert on that topic.)
I guess my response is, what's the worst thing that could happen if you continue having ECDSA keys signed with RSA? That is, other than wanting to sign up to play with the latest fun toy (which is why I signed my personal account up), what problem are you actually trying to solve by getting onto the allow-list?
We plan to do that, with time. Right now, those ECDSA intermediates chain to ISRG Root X2, which is new and not yet in root stores. So when you get certificates issued from those intermediates, you're relying on a chain that includes a cross-sign from ISRG Root X1 to ISRG Root X2. That makes for a fairly big chain, and not a significant overall benefit. You're still relying on an RSA signature in that chain, too.
When we do start default-signing from ECDSA intermediates for ECDSA end-entity certificates, we'll still recommend that chain with the cross-sign, but people who want to live on the bleeding edge and sacrifice compatibility will be able to serve an alternate chain that goes only to ISRG Root X2.
So… why are you deleting your account registration, then? That's a very unusual thing to be doing.
I am removing the garbage behind the script. I don't like it when an application or script leaves some obscure file behind that is not configuration.
For an M$ Windows user this is probably not understandable, because their operating system consists mostly of garbage, which increases every day, and for them it is normal.
But for Linux system administrators, things are different.
I practically know the purpose of every file in the system, and if some script, whose only job is to take a certificate request in and return a signed public key in the output, leaves me unclear files, I treat them as garbage and make the script clean up this garbage.
The id is your ACME account.
I didn't even know that I happen to create an account every time, and I also keep it in my account.
If I understand correctly, you need it either to revoke the certificate or to transfer the rights to it to another user.
I would have such a need, if the term of the certificate would be at least one year (taking into account that the wildcard is only through DNS, and I have to manually specify each time the _acme-challenge field on the site of my registrar, the certificate for a year would be very handy), and so when the term is 90 days I do not even have a theoretical need to revoke the certificate. I just don't need that account.
I'm not sure why you're talking about "correct", which may be some terminology confusion.
Immuniweb disagrees with you.
SERVER CERTIFICATES ARE SIGNED WITH A WRONG ALGORITHM
The ECDSA certificate provided has not been signed using the proper algorithm according to HIPAA guidance.
Non-compliant with HIPAA guidance
SERVER CERTIFICATES ARE SIGNED WITH A WRONG ALGORITHM
The ECDSA certificate provided has not been signed using the proper algorithm according to NIST guidelines.
Non-compliant with NIST guidelines
what problem are you actually trying to solve by getting onto the allow-list?
My only problem I'm trying to solve is the complete passing of the HIPPA and NIST tests on immuniweb.
Well, now you do! I would call the account info "configuration" that I'd want to keep, but if you want to delete it and make a new account each time I don't think it really hurts anything. But I don't think you can easily use the ECDSA-signing allow-list unless you're using the same account each time.
Well, part of the reason for it being only 90 days is because Let's Encrypt highly encourages automation. You might want to look into seeing if your DNS provider has an API that can be used to make the changes automatically, or delegating the challenge records to something like acme-dns that is designed for automation.
Hmm… I'm not very familiar with those, but I'm surprised that ECDSA-signed-by-RSA would be a problem. Even if you did get a certificate signed by the ECDSA intermediate, you'd still have the RSA signature of ISRG Root X2 by ISRG Root X1 in your certificate chain for the foreseeable future.
Looking at the link from that test to "NIST Special Publication 800-52 Revision 2 - Section 3", I see in section 3.2.1 that "If the server supports TLS versions prior to TLS 1.2, the certificate should be signed with an algorithm consistent with the public key: Certificates containing RSA, ECDSA, or DSA public keys should be signed with those same signature algorithms, respectively." But at this point I'd expect that anything that cared about HIPAA and current standards would have already disabled TLS prior to 1.2 (as the scan of your site shows you've done). Table 3-1, showing the proper TLS Server Certificate Profile, says that Issuer Signature Algorithm can be sha256WithRSAEncryption or stronger for a CA with an RSA key, or ecdsa-with-SHA256 or stronger for a CA with an elliptic curve key, and both seem perfectly fine. There's a lot of technical detail in there, so it's likely that I've missed something, but what I've read through looks like it's equally happy with either RSA or ECDSA. It's really unclear to me why the standard (or a scan based on it) would be fine with a completely-RSA chain or a completely-ECDSA chain but not a chain with a mix of the two.
The test also links to "HIPAA of 1996, Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals" (what a mouthful) which seems to just reference NIST: "Valid encryption processes for data in motion are those which comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, or others which are Federal Information Processing Standards (FIPS) 140-2 validated.
Now, if you actually need HIPAA compliance, obviously you need to dig into this with more detail than what I as a random person on the Internet have skimmed through in these documents in my spare time. But I suspect that that scanning tool you're using isn't really telling the whole story of what it means to be "in compliance". But you may want to just switch to fully using RSA certificates in the meantime, if that makes it easier to prove that you're using approved algorithms.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.