# Candidate second email **URL:** \ **Category:** Site Feedback\ **Created:** [January 20, 2019, 6:45am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328 "2019-01-20T06:45:34Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [January 20, 2019, 6:45am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/1 "2019-01-20T06:45:34Z")
Hi folks, I’ve been working on the wording for our second round of TLS-SNI deprecation emails, plus some of the underlying code. My current thinking is that it’s better / easier to include the affected IP addresses in the email rather than the domains. There are a lot of accounts that have a large number of domains, but typically they only use a single IP address. The plan for multiple accounts that have the same email address is to consolidate into a single email, and include up to ten IP addresses. Feedback on both the message content and the overall plan are welcome! Thanks to everyone for the hard work you’ve been doing answering questions. * * * Hello, _Action may be required to prevent your Let’s Encrypt certificate renewals from breaking._ If you already received a similar e-mail, this one contains updated information. Your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days. Below is a list of names and IP addresses validated (max of one per account): [example.com](http://example.com) (10.100.10.100) on 2018-11-24 [example.net](http://example.net) (10.11.10.11) on 2018-11-26 TLS-SNI-01 validation 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. You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire. Our staging environment already has TLS-SNI-01 disabled, so if you’d like to test whether your system will work after February 13, you can run against staging: [https://letsencrypt.org/docs/staging-environment/](https://letsencrypt.org/docs/staging-environment/). If you’re a Certbot user, you can find more information here: [How to stop using TLS-SNI-01 with Certbot](https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210) Our forum has many threads on this topic. Please search to see if your question has been answered, then open a new thread if it has not: [https://community.letsencrypt.org/](https://community.letsencrypt.org/) For more information about the TLS-SNI-01 end-of-life please see our API announcement: `https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209` Thank you, Let’s Encrypt Staff ```auto ``` ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [January 20, 2019, 6:49am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/2 "2019-01-20T06:49:23Z")
> [@jsha](#): > > My current thinking is that it’s better / easier to include the affected IP addresses in the email rather than the domains. There are a lot of accounts that have a large number of domains, but typically they only use a single IP address. > > The plan for multiple accounts that have the same email address is to consolidate into a single email, and include up to ten IP addresses. Would it work to include up to 10 sample domains? If people have multiple ACME clients, or multiple servers behind NAT, it might help them pinpoint it. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [January 20, 2019, 6:51am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/3 "2019-01-20T06:51:55Z")
> [@jsha](#): > > My current thinking is that it’s better / easier to include the affected IP addresses in the email rather than the domains I'm not sure if I am interpreting this right, but wouldn't this potentially be unhelpful for the many domains behind CDNs and AWS ELB/NAT-like endpoints? I agree with @mnordhoff that it would be very helpful to have upto 10 certificate names as well. This would give the recipient some hope of identifying which "logical group" of domains are affected. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [January 20, 2019, 6:54am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/4 "2019-01-20T06:54:09Z")
> [@mnordhoff](#): > > Would it work to include up to 10 sample domains? It's possible, but I'm trying to balance out implementation time and complexity. If I include domains, I have to choose some method to pick 10 of them, and most methods are likely to leave out some useful information. If I go with IP addresses, they are in theory more information-dense, and any given strategy to pick 10 should be fine. Doing both definitely adds a certain amount of complexity and implementation time. > [@\_az](#): > > I’m not sure if I am interpreting this right, but wouldn’t this potentially be unhelpful for the many domains behind CDNs and AWS ELB/NAT-like endpoints? I think domains behind CDNs in general can't use TLS-SNI, unless the validation is performed by the CDN itself. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [January 20, 2019, 6:55am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/5 "2019-01-20T06:55:07Z")
Oh, good point. Doesn’t seem so bad then. Edit: but in general I do think that upto 10 domains + total count would is definitely still be much more helpful. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [January 20, 2019, 6:57am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/6 "2019-01-20T06:57:11Z")
I'm having a hard time thinking of what people who _don't_ already know what's going on need to be told. 😖 But... > [@jsha](#): > > Your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days on these IP addresses: > > [up to ten IP addresses per user] I think it should clarify when some IP addresses are being left out. People might think they have _only_ ten servers using TLS-SNI and not investigate their others. > [@jsha](#): > > If I include domains, I have to choose some method to pick 10 of them, and most methods are likely to leave out some useful information. Whichever 10 are fastest to extract from the database? 😃 ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [January 20, 2019, 6:59am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/7 "2019-01-20T06:59:40Z")
One nit about ambiguity: is it the IP address that the VA connected to that is reported, or the IP address of the ACME client that requested the certificate? ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [January 20, 2019, 7:02am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/8 "2019-01-20T07:02:07Z")
My thinking was that a list of domain names might be most useful to people who _don’t_ have a lot of domains or servers. E.g. “Is it my Synology or my home server?” It’s theoretically easy to check only a few servers, but sometimes they don’t have good logs making it actually harder to figure out what’s going on. Someone with hundreds of web servers and thousands of domains should _usually_ know what their systems are doing anyway. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [January 20, 2019, 7:02am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/9 "2019-01-20T07:02:52Z")
> [@\_az](#): > > is it the IP address that the VA connected to that is reported, or the IP address of the ACME client that requested the certificate? Current plan is that it would be the IP address the VA connected to, since it's easiest to collect that information alongside the list of validations that used TLS-SNI-01 - it's in the validation logs. To be really precise, for each given account, I'll have the most recent IP address validated using TLS-SNI-01 (a limitation of our log querying software). Then I'll be merging accounts with the same email address, so if you have clients on three different IP addresses (each with a different account ID), you'll get a single email with three IP addresses. I think it's hard to convey that nuance really precisely in the email, but definitely interested in better ways to talk about it. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [January 20, 2019, 7:06am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/10 "2019-01-20T07:06:18Z")
> [@jsha](#): > > Please make sure to search for similar problems before starting a new thread: I'd like to hear what other people think, but this sentence concerns me. In some ways it's easier to manage a flood of repetitive threads than a smaller flood of people necroing other, semi-related threads. Edit: Confession: Discourse's tool to split threads is fantastic, but coming up with titles is hard! ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [January 20, 2019, 7:08am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/11 "2019-01-20T07:08:00Z")
> [@mnordhoff](#): > > In some ways it’s easier to manage a flood of repetitive threads than a smaller flood of people necroing other, semi-related threads. That's a good point, I hadn't thought of that! What do other folks think? Also, what documentation can we add that will make it easier to point people at help? ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [January 20, 2019, 7:17am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/12 "2019-01-20T07:17:43Z")
> [@jsha](#): > > Your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days on these IP addresses: Wrt the IP address thing, I'd perhaps update this copy to: > In the past 60 days, your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue certificates for domains hosted on these IP addresses: > [@jsha](#): > > Also, what documentation can we add that will make it easier to point people at help? I think the post at [How to stop using TLS-SNI-01 with Certbot](https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210) could be improved with an example of how to actually perform a dry-run and identify that TLS-SNI is indeed not being used during that run. There was also one thread where dry-run gave a false positive result on staging due to cached authz (port 80 was clearly inaccessible but there was a previously valid http-01 authz). Maybe it's asking too much, but killing the authz caching on staging for a few days could help? I'd be pretty mad if Certbot lied to me like that and my cert expired :|. I think perhaps that the Help template could temporarily be modified to include an explicit prompt for `certbot --version`, since it seems necessary to ask that in every Help thread. In a similar vein, [How to stop using TLS-SNI-01 with Certbot](https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210) could perhaps promote `certbot --version` to a proper styled code block, with example output indicating the correct version, so that it doesn't get buried in the prose. Re: necro, I think it's possible to greatly reduce that problem by making @bmw's post a bit more "step by step" in nature, to match the audience who are looking for very prescriptive advice/instructions. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [January 20, 2019, 2:04pm UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/13 "2019-01-20T14:04:16Z")
> [@\_az](#): > > the post at [How to stop using TLS-SNI-01 with Certbot](https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210) could be improved with an example of how to actually perform a dry-run and I'll work on getting this added. > [@\_az](#): > > killing the authz caching on staging for a few days could help? This is a cool idea! I think it's doable; I'll check with the team. > [@\_az](#): > > Help template could temporarily be modified to include an explicit prompt for `certbot --version` Done! I think I phrased this in a way that covers multiple clients, so it's a pretty good candidate for keeping long term. > [@\_az](#): > > promote `certbot --version` to a proper styled code block I like this. For now I put `--version` in a code block to make it stand out, but I'll rework it some more in a bit. > [@\_az](#): > > I think it’s possible to greatly reduce that problem by making @bmw’s post a bit more “step by step” in nature ✔ ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [January 22, 2019, 3:08am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/14 "2019-01-22T03:08:21Z")
After some more thinking and experimenting I think the way that makes sense to organize this information is that we’ll report one domain and one IP address per account. This limits the size and complexity, is consistent and easy to explain, and since most of the time one account is operated by one piece of software, that should be sufficient to inform people about all the places they need to update. I’ve edited the sample post to reflect this. What do you think? ---
**Author:** ![bmw](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bmw/32/7797_2.png) [@bmw](https://community.letsencrypt.org/u/bmw)\ **Post date:** [January 23, 2019, 12:35am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/15 "2019-01-23T00:35:59Z")
> [@jsha](#): > > Our staging environment already has TLS-SNI-01 disabled, so if you’d like to test whether your system will work fine after the deprecation date, you can run against staging. I think it may be worth providing a link about the staging environment here. [Staging Environment - Let's Encrypt](https://letsencrypt.org/docs/staging-environment/) works, but I kind of want to remove the suggestion to use `--staging` with Certbot in favor of `--dry-run` if we're going to be including a link to this page in the email. (If you naively use `--staging`, you can end up with staging certificates installed in Apache/Nginx!) > [@jsha](#): > > > I think it’s possible to greatly reduce that problem by making @bmw’s post a bit more “step by step” in nature > > ✔ Thanks @jsha. I like your post a lot better than mine. I'm tempted to delete all/most of my post before the email goes out in favor of people reading jsha's. What do people think? ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [January 23, 2019, 12:45am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/16 "2019-01-23T00:45:03Z")
> [@bmw](#): > > I think it may be worth providing a link about the staging environment here. [Staging Environment - Let's Encrypt](https://letsencrypt.org/docs/staging-environment/) works, but I kind of want to remove the suggestion to use `--staging` with Certbot in favor of `--dry-run` if we’re going to be including a link to this page in the email. That's a great idea. Can you send a PR at [GitHub - letsencrypt/website: Let's Encrypt Website and Documentation](https://github.com/letsencrypt/website)? > [@bmw](#): > > Thanks @jsha. I like your post a lot better than mine. I’m tempted to delete all/most of my post before the email goes out in favor of people reading jsha’s. What do people think? Thanks! 😊 I would be totally fine if you wanted to hoist my post into yours with an edit, then we could just delete mine. Feel free to do that directly. ---
**Author:** ![bmw](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bmw/32/7797_2.png) [@bmw](https://community.letsencrypt.org/u/bmw)\ **Post date:** [January 23, 2019, 12:50am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/17 "2019-01-23T00:50:25Z")
> [@jsha](#): > > That’s a great idea. Can you send a PR at [GitHub - letsencrypt/website: Let's Encrypt Website and Documentation](https://github.com/letsencrypt/website)? > > ![](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bmw/40/7797_2.png) bmw: > > > When you use \`--staging\`, Certbot basically works the same way as it does when u…sing the production server. There are a couple very basic sanity checks around things like changing a certificate lineage from production to staging certs, but for the most part, Certbot treats this server like any other ACME server. This can result in things like staging certificates installed into someone's Apache or Nginx config. > > I think a better option for people to use here is \`--dry-run\` which doesn't allow users to test certificate installation (which isn't affected by the choice of ACME server anyway), but works for the \`certonly\` and \`renew\` subcommands and doesn't save the resulting untrusted certificates to disk. > > On the Certbot side, we never tell anyone to use \`--staging\` and always recommend they test with \`--dry-run\`. > [@jsha](#): > > Thanks! 😊 I would be totally fine if you wanted to hoist my post into yours with an edit, then we could just delete mine. Feel free to do that directly. Great. I'm going to give people on the Certbot team who worked on that post with me a brief chance to object, but if they don't, I'll do that. ---
**Author:** ![bmw](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bmw/32/7797_2.png) [@bmw](https://community.letsencrypt.org/u/bmw)\ **Post date:** [January 23, 2019, 2:13am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/18 "2019-01-23T02:13:34Z")
I also wanted to add that I think this is a good idea: > [@jsha](#): > > > killing the authz caching on staging for a few days could help? > > This is a cool idea! I think it’s doable; I’ll check with the team. I'm not sure how many people will have reusable staging authzs and how significant the increased load would be on Let's Encrypt to disable authz reuse in staging to some degree, but I think authz reuse really negatively affects people's ability to test here. With Certbot, if you test against staging but have a valid authz, all that was tested is it is possible for Certbot to set up the challenge (e.g. standalone could bind to port 80, we could modify your Apache/Nginx config, etc.). You could have bad firewall rules, your ISP is blocking port 80, etc. and you would have no idea. I would expect other clients to have similar problems here. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [January 23, 2019, 5:26am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/19 "2019-01-23T05:26:37Z")
Yep, we’ve [disabled authz reuse in staging as of today](https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209/2). ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [January 23, 2019, 6:34am UTC](https://community.letsencrypt.org/t/candidate-second-email/83328/20 "2019-01-23T06:34:01Z")
> [@jsha](#): > > Yep, we’ve [disabled authz reuse in staging as of today](https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209/2). I'm not seeing it yet. I did a `--dry-run` on a certificate, and then I issued two staging certificates for a new hostname, and it still did normal authz reuse. E.g.: [https://acme-staging-v02.api.letsencrypt.org/acme/order/5707995/20873270](https://acme-staging-v02.api.letsencrypt.org/acme/order/5707995/20873270) [https://acme-staging-v02.api.letsencrypt.org/acme/order/5707995/20873389](https://acme-staging-v02.api.letsencrypt.org/acme/order/5707995/20873389) [https://acme-staging-v02.api.letsencrypt.org/acme/authz/7YmNRiwOX0ztD0yWNnipuavUpfd-nHFZ3TV\_1jW6fQk](https://acme-staging-v02.api.letsencrypt.org/acme/authz/7YmNRiwOX0ztD0yWNnipuavUpfd-nHFZ3TV_1jW6fQk) Edit: The `--dry-run` was: [https://acme-staging-v02.api.letsencrypt.org/acme/order/5707995/20870483](https://acme-staging-v02.api.letsencrypt.org/acme/order/5707995/20870483) [https://acme-staging-v02.api.letsencrypt.org/acme/authz/GlvZwP6rNTtBlOW82jZrhRswyZk8fKRNgVgTlWDN4do](https://acme-staging-v02.api.letsencrypt.org/acme/authz/GlvZwP6rNTtBlOW82jZrhRswyZk8fKRNgVgTlWDN4do) [https://acme-staging-v02.api.letsencrypt.org/acme/authz/xNntDCuXKLFWhF\_0WABE2FjO2Uj1AUDJv-DJFlPKAJw](https://acme-staging-v02.api.letsencrypt.org/acme/authz/xNntDCuXKLFWhF_0WABE2FjO2Uj1AUDJv-DJFlPKAJw) Edit: The `--dry-run`'s authzs' original order was: [https://acme-staging-v02.api.letsencrypt.org/acme/order/5707995/19095710](https://acme-staging-v02.api.letsencrypt.org/acme/order/5707995/19095710) [Next page](https://community.letsencrypt.org/t/candidate-second-email/83328.md?page=2)