Quick update here: We deployed a fix outside of the usual cycle to make sure this was addressed. The staging environment is now properly not reusing valid authorizations for both the V1 and the V2 API.
I've updated the draft post, mainly to make this sentence simpler and clearer:
TLS-SNI-01 validation in the production environment is reaching end-of-life. It will stop working temporarily on February 13th, 2019, and permanently on March 13th 2019. Any certificates issued before then will continue to work for 90 days after their issuance date.
(It used to try and explain how to check your certificate's NotAfter date from browser developer tools).
Heads up: This second round of emails will start going out today. We’ll be spacing them out slowly just in case someone reports a significant last-minute problem.
Well, I know what’s going on, but I have a lot of domains, and the last email didn’t give me even a hint which one(s) had a problem. So, I don’t care whether I get IP or domain name, just make sure I get at least one.
To give a “recipient’s perspective” on the second email:
It does now say which domain name and which IP address were affected (which is good), but crucially doesn’t say whether the same challenge will be attempted next time. In my case I got an email for one domain that I don’t believe will fail (I’ve just tried dry-run and it says it could renew using http-01) and didn’t (yet) for one that I believe will fail next time (it did tls_sni_01 last time and dry-run fails for all challenge types).
Perhaps if there’s a “third email” it should explicitly suggest dry-run as a way of checking? Of course, assuming people are checking for renewals regularly they should get 30 days notice of a problem when a renewal fails.
The harder problem to solve is explaining to people what they need to do next once they’ve found (e.g. by a renewal dry run) that they do have a problem. The email does link to this help site; there’s lots of information here but maybe encourage people to post “solved problems” here too (e.g. “I was previously using tls_sni on XYZ server and I fixed it by doing A, B and C”).
Isn’t the “fix” always to just request a brand new certificate? At least that’s what I did, and it worked for the one I knew was using the deprecated method. Got the email today and found that there was indeed a second.
Still, your point is sound. If that is the simple solution, mentioning it in the email would help
You may be right, but you are assuming (not necessarily correct) that all the sites have static IP. ^here are also those sites that use dynamic DNS and their IP changes. By the time you send the IP the respective domains already may have another IP because thy got rebooted or for any other cause. The only bullet proof method is to target domains and not IP. After all the certificate is per domain not per IP.
Hi all! I think this thread is likely to become a catch-all support thread, so I’m going to close it in favor of separate threads about specific problems. I appreciate the feedback on possible improvements if we need another round! Note that issuing another certificate is not necessarily enough; you need to also make sure your client is fully up-to-date, as described in the Certbot post linked from the email.
As a heads-up, we’re going to start sending out weekly batches of this notification email, only to the people who validated using TLS-SNI-01 during the last week. Each batch will be much smaller (~75k accounts, as of this week), and the data will be fresher since it only covers a week. If there are any changes you’d like to recommend, let me know – for instance by starting a new thread and tagging me.