5 ms·

Crap. I had certs set to expire on 2/28! I was going G to be saved by wildcard. Off to make a bunch of DNS entries....

by berbec 9y ago

mustardo 9y ago
That's ok you still have almost 26 months ;-p
- tty7 9y ago
  slow clap :D
schoen 9y ago
Does your ACME client already support ACMEv2 and wildcards? I think only acme.sh has so far claimed to (happy to be corrected if another client has finished its implementation).
- berbec 9y ago
  I use certbot. I'm not sure as I was just planning on figuring it out for the night of expiration.
  - schoen 9y ago
    I'm part of the Certbot team and I can tell you that the ACMEv2 support is still being implemented by my colleagues now; even if it had been included in a release this week or next, you would have been cutting it pretty close! Many of our users don't have the most current release because distribution packagers don't ship it right away (or even for months or years, depending on circumstances). Certbot's own autorenewals (which I originally implemented and which I hope are currently working for you -- I'm happy to try to find a way to get them to work in your deployment if they're not!) try by default to renew certificates 30 days before expiry in order to give people a lot of time to notice and intervene if something goes wrong. Consistent with that, I'd encourage all of our users not to rely on anything happening less than 30 days before expiry as part of their plan for keeping certificates current on their sites.
    - berbec 9y ago
      Thank you for all your work. My renewal went through fine. I had commented it out of crontab, but went fine once I ran it. I was pleasantly surprised when tls-sni worked flawlessly.
      - schoen 9y ago
        Great! One thing to know about the TLS-SNI situation is that TLS-SNI-01 has been disabled for new issuance and only works for renewals. The selection of authentication methods is pretty transparent because the ACME protocol allows the CA to state which methods it will accept for a particular domain authorization (so for the renewals it can state that TLS-SNI-01 is permitted, while for new issuance it can state that it's not, and a client can respond accordingly). Apparently the ACME WG is working on a TLS-SNI-03 method that will be safer and that might be supported by Let's Encrypt (and ACME clients) at some point. But it's also possible that TLS-SNI-01 could be disabled in the future, even for renewals, even before TLS-SNI-03. So, if you happen to have anything in your setup that prevents the use of HTTP-01 on port 80 for authentication, you should be aware that renewals could potentially stop working at some point (although this isn't imminent), and that you might also have difficulty adding new domain names to your certificates. https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811 https://community.letsencrypt.org/t/important-what-you-need-... This unfortunate situation is a nice showcase of the ACME protocol's flexibility, because the CA has a way to tell the client very specifically what authentication methods to attempt or not to attempt for each domain (and if new methods are specified in the future, they can be rolled out incrementally without breaking compatibility).
        tialaramex 9y ago
        One thing that'd be good here for outside observers is for Let's Encrypt to bake a list of the Blessed Methods used into certificates as OIDs in the Policy section. Right now a researcher with 5 million Let's Encrypt certificates can see which ones use public keys with unusual patterns, how many are for names in the French .fr TLD, how many have longer key lengths, and so on, but they can't see whether the validation was done with Method 10 (which had this unexpected flaw) or some other method. Another CA (can't remember which one) was looking at doing this, and it seems like it'd be nice for Let's Encrypt too.
- cm2187 9y ago
  It’s not super hard to implement yourself, particularly given it is a variation of the first ACME protocol for which there is lots of code available, and the staging API for v2 is already up and running. The main challenge is that wildcards require DNS authorization, so a full automation is DNS api specific. My DNS (OVH) has a neat rest API. But given the variety of DNS providers and APIs it is going to be challenging to rely only on a reference implementation without wrtiting a little bit of code yourself.

Crap. I had certs set to expire on 2/28! I was going G to be saved by wildcard. Off to make a bunch of DNS entries....

by berbec 9y ago

Crap. I had certs set to expire on 2/28! I was going G to be saved by wildcard. Off to make a bunch of DNS entries....

mustardo 9y ago

That's ok you still have almost 26 months ;-p

tty7 9y ago
slow clap :D

schoen 9y ago

Does your ACME client already support ACMEv2 and wildcards? I think only acme.sh has so far claimed to (happy to be corrected if another client has finished its implementation).

berbec 9y ago
I use certbot. I'm not sure as I was just planning on figuring it out for the night of expiration.
- schoen 9y ago
  I'm part of the Certbot team and I can tell you that the ACMEv2 support is still being implemented by my colleagues now; even if it had been included in a release this week or next, you would have been cutting it pretty close! Many of our users don't have the most current release because distribution packagers don't ship it right away (or even for months or years, depending on circumstances). Certbot's own autorenewals (which I originally implemented and which I hope are currently working for you -- I'm happy to try to find a way to get them to work in your deployment if they're not!) try by default to renew certificates 30 days before expiry in order to give people a lot of time to notice and intervene if something goes wrong. Consistent with that, I'd encourage all of our users not to rely on anything happening less than 30 days before expiry as part of their plan for keeping certificates current on their sites.
  - berbec 9y ago
    Thank you for all your work. My renewal went through fine. I had commented it out of crontab, but went fine once I ran it. I was pleasantly surprised when tls-sni worked flawlessly.
    - schoen 9y ago
      Great! One thing to know about the TLS-SNI situation is that TLS-SNI-01 has been disabled for new issuance and only works for renewals. The selection of authentication methods is pretty transparent because the ACME protocol allows the CA to state which methods it will accept for a particular domain authorization (so for the renewals it can state that TLS-SNI-01 is permitted, while for new issuance it can state that it's not, and a client can respond accordingly). Apparently the ACME WG is working on a TLS-SNI-03 method that will be safer and that might be supported by Let's Encrypt (and ACME clients) at some point. But it's also possible that TLS-SNI-01 could be disabled in the future, even for renewals, even before TLS-SNI-03. So, if you happen to have anything in your setup that prevents the use of HTTP-01 on port 80 for authentication, you should be aware that renewals could potentially stop working at some point (although this isn't imminent), and that you might also have difficulty adding new domain names to your certificates. https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811 https://community.letsencrypt.org/t/important-what-you-need-... This unfortunate situation is a nice showcase of the ACME protocol's flexibility, because the CA has a way to tell the client very specifically what authentication methods to attempt or not to attempt for each domain (and if new methods are specified in the future, they can be rolled out incrementally without breaking compatibility).
      - tialaramex 9y ago
        One thing that'd be good here for outside observers is for Let's Encrypt to bake a list of the Blessed Methods used into certificates as OIDs in the Policy section. Right now a researcher with 5 million Let's Encrypt certificates can see which ones use public keys with unusual patterns, how many are for names in the French .fr TLD, how many have longer key lengths, and so on, but they can't see whether the validation was done with Method 10 (which had this unexpected flaw) or some other method. Another CA (can't remember which one) was looking at doing this, and it seems like it'd be nice for Let's Encrypt too.
cm2187 9y ago
It’s not super hard to implement yourself, particularly given it is a variation of the first ACME protocol for which there is lots of code available, and the staging API for v2 is already up and running. The main challenge is that wildcards require DNS authorization, so a full automation is DNS api specific. My DNS (OVH) has a neat rest API. But given the variety of DNS providers and APIs it is going to be challenging to rely only on a reference implementation without wrtiting a little bit of code yourself.