Well, I won't repeat my earlier rant, but the official integration guide says to look at the API Announcements category of this forum. And I think that's fine, but it takes the form of "announcements" of course, so one needs to piece together the announcements to find the upcoming timeline, as well as what pieces are relevant to what one is doing. So somebody coming in fresh (whether new to Let's Encrypt or just trying to solve a problem without having paid attention to the forums for a bit) doesn't really know what's coming unless they dig through the past announcements.
I think that one big challenge is also that there have been a lot of changes recently and upcoming, between the new E1/R3 intermediates, working on ECDSA issuance, and dealing with the DST Root expiration (with the plan changing in there at some point with the longer cross-sign). It's a lot to keep track of, and just coming in with "how do I ensure my system won't break" is tough to answer without looking through a bunch .
Yes, I agree with this. I suppose I am asking for more clarification on what that official, obvious place should be that would reach the most people and do the most good. Specifically, it would reach ACME client creators.
Hey, @griffin, at least in the meantime, how would you feel about a topic maintained "by the community" (I think higher-level users can make a post a "wiki" type thing), rather than "by the Let's Encrypt staff"? And then when the official announcements happen, "we" (for some definition of "we" that may or may not include myself) update it to ensure the timeline is clear, the main and alternate chains are clear, and so on? If the data needed by people is all "there", somewhere, do you think it could be "crowdsourced" (though I hate that word) effectively to express it in better and perhaps more digestible ways?
I'm not sure how I feel about it, myself, since perhaps it really should just be in the docs section of the website and more people need to be submitting better pull requests, rather than faking it in the forums? I'm just doing some brainstorming.
I have no qualms maintaining that. The challenge is that it needs to be in a place where it won't get lost. I don't have permissions to modify the #api-announcements.
It's much easier to modify here than in the docs and only takes people seconds to turn around and ask their questions (in a separate topic with a reference, preferably).
I'll draft up something after lunch. I'll probably need correcting.
Can I make a quick request that I pass this by the comms team first? It would be really nice not to have another place as a reference point, I think that's part of the issue we are having right now.
Please give me the weekend and part of Monday, I'm happy to have something together shortly after that on one of the official, obvious channels that griffin mentioned. I want to be able to reproduce this each time so people know where to go every time for the information, if that makes sense.
I do think (or maybe hope is the better word) that we're going through an especially busy time for Let's Encrypt right now, with a lot changing at once. Most of the time, running an automated CA should be boring if all is going well. Once the chaos of this year's changes is over and clients have all caught up with dealing with multiple certificates being returned in the chain, ECDSA issuance is a normal thing, and DST Root's expiration is long past, then there won't be nearly so much need for organizing the upcoming timeline of events (since it'll just be "normal" things like intermediate rollovers until ISRG Root X1 expires in 15 years, right? right?). But for now it's easy for people to get confused. (And that's just the people who are seeing changes coming and trying to prepare for them for now. When clients start breaking over the course of this year for one reason or another this forum will be busy.)
For sure, this year is definitely an anomaly for us in our short 5 year history! I just want to use this change as a growing point for comms too - knowing the best way to do things and having a process we can reproduce that we can say "hey, we know this works" is important for future comms too!
Also, we are dealing with chaining changes that aren't necessarily connected, so keeping those stories and changes separate is part of it too!
Busy busy! But you got my word I'll get back to you ASAP (and as Griffin knows, always feel free to ping me too!).
I just wanted to add that I'd definitely benefit from a clear single location of the chain information and dates of change. For example, I was actually caught off guard to realise that we are still being issued the DST Root CA X3 by default as opposed to the ISRG Root X1 chain.
I've really been struggling to find clear information on the changing dates and I think this is because everything is getting lost in conversations, announcements and blog posts which need to be pieced together, i.e. finding the latest statements and separating them from discussion and ideas. I'm also unsure as to whether I should be using --preferred-chain or not (I'm not) to continue supporting old devices pinned to DST Root CA X3, or to find what the options actually are for the --preferred-chain option.
I appreciate some of these points might be out of date. But that's the point right? I thought the DST expiry was over and done with, but I'm still not fully on the right page!
Thank you so much! That looks great, and is really helpful.
The only other thing I might suggest adding, though I'm not sure of the best way to word it, is something along the lines of "If you don't know what certificate type you're using, it's probably RSA", and maybe include the words "elliptic curve" somewhere near the term "ECDSA" just in case that's a more recognizable term to somebody. but this is really me nitpicking. I really like separating out by certificate type first, and then by timeline (rather than how I proposed it above organizing by date first), since I think it's much clearer that way.
And oh, It's probably a good idea to include that intermediates could switch to the backup ones at any time, just in case people think that listing the chains means they should hardcode R3 everywhere.
I thought about adding the fact that intermediates should change, but then I was wondering how much more this could easily become a "best practices for chains" post - which I didn't want it to be. We tried to keep it as close as we could to "here are the chains" without getting involved in best practices - which are other docs and I think we should keep those docs separate (in case those best practices ever change, here would be yet another place we would have to update it!).
@jillian what do you think about adding Elliptic Curve Digital Signature Algorithm (ECDSA) to the first mention of ECDSA in the post? I'm not sure about adding the language "if you're not sure what chain you are using, you are probably using RSA" when it's pretty clear how to get an ECDSA cert. I think in future posts that would definitely fit, especially when we move away from an ECDSA allow-list!
Thanks for all of your feedback and help with this, community! And remember, subscribe subscribe subscribe to the API Announcements category (sign into the forum and click that bell!): API Announcements - Let's Encrypt Community Support
Fair enough. I have off-and-on been thinking about writing an "Intro to WebPKI" documentation page, designed to cover things like that. I went so far as to actually start work on writing it a few weekends back, though I haven't got very far yet and haven't touched it in a while.
I love that! If there is anything that could ever live in the docs on our website, it would be incredible to add it there as well. We are always working to make those docs better, but we would love to have community help as well! If you do make PRs on our website to update docs, @ me (jaykaypea on GitHub) so I can help get the changes through.
Also this is one of my favorite docs to recommend to folks (thanks to Matt Holt and the rest of the contributors!) for best practices, along with the integrator doc on our website: docs/acme-ops.md at master · https-dev/docs · GitHub
If you have any others that you like to recommend, let me know! Always looking for great resources our community can use and information to incorporate into our own docs as well.
Thanks again for this recommendation! I hope this helps everyone.
Once the chaos of this year's changes is over and clients have all caught up with dealing with multiple certificates being returned in the chain, ECDSA issuance is a normal thing, and DST Root's expiration is long past, then there won't be nearly so much need for organizing the upcoming timeline of events (since it'll just be "normal" things like intermediate rollovers until ISRG Root X1 expires in 15 years, right? right?). But for now it's easy for people to get confused. (And that's just the people who are seeing changes coming and trying to prepare for them for now. When clients start breaking over the course of this year for one reason or another this forum will be busy.)
