Upcoming Features - Let's Encrypt 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. Completed Features Multi-Perspective Validation Enabled: February 19,... 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.

[image] petercooperjr: but you can request to have your account added to the allow-list in order to have them signed by the ECDSA intermediates instead. 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?

[image] Ilya_indigo: Thank you for your reply. Can I ask you to sign my certificate ilya.pp.ua SSL Security Test | ImmuniWeb with ECDSA in more detail? And is it free? Please read ECDSA availability in production environment

[image]Help thread for DST Root CA X3 expiration (September 2021) Please read ECDSA availability in production environment 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.

[image] petercooperjr: account_id.json 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?

ECDSA intermediate issuance

Help

Nummer378 May 18, 2021, 11:06pm 4

Please read ECDSA availability in production environment

Topic		Replies	Views
Questions re: Production ECDSA allow-list Issuance Tech	56	10060	October 14, 2021
Let's Encrypt New Intermediate Certificates Issuance Tech	60	6933	January 8, 2024
Let's Encrypt new hierarchy plans Issuance Tech	29	10661	August 13, 2020
ECDSA Root and Intermediates ISRG/Organizational	28	8516	June 11, 2020
"EC XXX bits (SHAXXXwithRSA)" versus "EC XXX bits (SHAXXXwithECDSA)"? What's the difference? Does it matter? Issuance Tech	24	6815	August 5, 2022

ECDSA intermediate issuance

Related topics