Feedback wanted: DST Root CA X3 expiration all-subscriber email

[petercooperjr]

Generally looks pretty good, but of course I can find things to nitpick about.

@jsha

certificate for {{hostname}}

Is this just going to show one hostname per account? If I have several hostnames, and only get an email relating to one, it may be confusing as I might think I only need to pay attention to that one host. I'm not sure of the best way to work around this, as I'm sure that listing all the hostnames for an account would also be terrible for some users, but maybe be clearer that the account may have other hostnames and it's something affecting all Let's Encrypt certificates?

@jsha

If you're receiving this in error

I think more likely the message needs to be that if they're not understanding it they should forward it to whatever technical person is maintaining their web site. (I mean I see why you need to reference unsubscribing as well, but I don't know how often someone is listed as the contact but has no idea what a Let's Encrypt is.)

@jsha

If you provide an API or have to support IoT devices

I don't know how technical an audience this is going for, but using these acronyms without defining them might confuse some people (though more likely to confuse the people who don't need to worry about it). I guess I'm just thinking that there's a lot of jargon associated with certificates already, so avoiding any more jargon than one needs to might be helpful. Here you're using terms that aren't even in the official glossary.

@jsha

If you provide an API or have to support IoT devices, you'll need to make sure of two things:

For the second step here of using OpenSSL, the other option is to have their ACME client use the alternate chain, right? I'm thinking that in many of these scenarios it'd be easier to get the server's ACME client to use the alternate chain rather than getting the embedded-device-type client to upgrade their version of OpenSSL. I'm not sure of the best way of wording it, but I think that "use the alternate chain if your clients don't handle a chain with expired roots" needs to be in there somewhere, even if it's just a footnote or a page in the documentation that this links to or whatever.

@jsha

If you have any questions, we recommend asking on our community support forums

I don't know if this email should be linking to the forums in general, rather than to a specific forum thread or a help page of some sort. If it turns out that there's some other thing one wishes got put in the email (or there's some other update to the transition or whatever) it may be nice to there to be a good "landing page" with any updates.

@schoen

(I'm wondering whether it's worth being a little more explicit that there may be malfunctioning clients or control panels that hard-code the chain even without being told to prefer a particular chain... this is potentially helpful information to the minority of people using such a client, but may be confusing or distracting to the majority who don't.)

Yeah, this message is very focused on the Sept. 30 date, but when I first saw the thread I originally assumed that this would be informing people of the May 4 date when any client that's not expecting multiple certs in the chain will fail. Though obviously both are important for people to know about.

Some other thoughts:

• Is this getting localized into various languages?
• I definitely agree with the above comments that "How do I test this?" and "How do I know what to look for" should probably get addressed. Maybe there should be some mention of the staging environment, though the message is already getting really long as it is.