Not a problem...
so long as the final writing is formally presented in iambic pentameter complete with heroic couplets.
Reach deep... find a word that rhymes with orange...
Not a problem...
so long as the final writing is formally presented in iambic pentameter complete with heroic couplets.
Reach deep... find a word that rhymes with orange...
Two comments on your key rotation:
I did not pick this up on your post last year, but the
Account Key rollover is fairly new. I think it went live with LetsEncrypt in 2016 or 2018 - I can’t remember. As such, clients written before then did not initially support it, and not many current ones do either. it’s one of the last things client devs support; certbot does not support this and has no plans to (it was milestoned in 2017, then deprioritized in 2020)
In terms of Private Key cycling, with complex integrations I prefer to cycle keys by day or week. I.e. all certs procured on a certain day/week share the same private key as long as the domain traffic is below a threshold. This is simply to lower the memory load on the terminating SSL server. IMHO, this doesn’t pose a larger security concern, because our security response plan assumes all managed keys are compromised if any one key is compromised. The threshold rule is in place to minimize the potential for traffic analysis/brute force.
This randomly popped into my head this morning:
When it comes to "Duplicate Certificate" limits, my own approach has been to telling people their integration has problems, and then recommend the bypass trick of adding a new domain to the certificate as a temporary measure.
What I randomly realized today, is that a lost/never-downloaded Certificate might be recoverable and usable from crt.sh if the Private Key is still saved to disk. I haven't looked to see which, if any, clients save or log the private key when the CSR is generated - but I assume some might.
Several of us here have tried to go down this route on more than a few occasions when helping people who have deleted their certificates. The majority of the time, the private keys are gone. I've never seen a client log a private key as I suspect that most probably just dump the private key onto non-volatile storage as soon as it and the CSR are generated. I don't think I would like a client to log the private key as I feel like this "second copy" could end up somewhere with worse permissions than the home of the "original copy". Imagine if people were posting client logs containing private keys...
On the rare occasion that the help-seeker has retained a private key and downloaded the desired certificate from crt.sh, the next step is always making sure it's the right private key. Much of the time there are many keys for many duplicate certificates, which makes this process a barrel of laughs. Clearly the openssl command line comes in handy here though I've found that looking at dates along with installation trial-and-error are often faster and less error-prone.
It is because of all of this, of course, that the following came about:
Hopefully we will soon be able to say: just fix the problem, you can try again in an hour.
If there are two people who do the most posting, you're given a message to "get a room" (PM).
Oh no! Another one with multiple personalities? On one forum we had one person with 35! The only way to tell them apart is that they were numbered.
This has popped up a few times:
“Your system is not supported by certbot-auto anymore.”
Inspired by something @Osiris said about cloud hosters, what would be a neutral and friendly way to ask, "Are you sure you checked all your firewalls on your virtual machine"?
Perhaps prefaced with something like this...
Can you reach your website/device from your phone?
If not, neither can we.
This is usually very helpful, but maybe less so with things like those Synology NASes—where it's pretty likely that the user's phone is on the same LAN as the NAS box.
We probably want something like check-your-website / letsdebug / etc. as a backup in this case.
I was meaning a smart phone on a wireless/cellular network.
Yes, but there's a lot of incentive to get your smart phone to join your home LAN. My phone even gives me a warning if an app uses more than a certain amount of mobile data, whereas there is no such warning for wifi (possibly based on the common situation where mobile data is metered or capped, while wifi is connected to a fixed broadband link that isn't metered or capped, or much less noticeably so). Signal also built-in features that suggest, for example, autodownloading media over a wifi link but not over mobile data. So smartphones are probably nudging their users... "please, please, let me onto the home wifi! it will be so much better!".
Edit: so we could just emend this to
"Can you reach your website/device from your phone, with wifi turned off on the phone?"
That's a good idea to be more precise. It saves time on bad assumptions.
Should there be server-specific sections? Like today someone received the "maximal certificate requests reached" error message and apparently that's a thing that happens with Synology, judging from the keyword search I just did of these forums. Like, would the commands you run if you have a Synology server be different from what you'd run on a different type of server?
It's unfortunately going to really depend on how they go about it. The official Synology DSM Let's Encrypt documentation has historically been... questionable. I wrote a clarification/critique a while back in an attempt to provide a starting point for Synology DSM users. I'm not sure if it's correlated or not, but after that writing an update to the official documentation seems to have addressed/dodged almost every concern that I mentioned.
You have aptly identified what is likely the most common case of that rate limit occurring. It isn't specifically limited to Synology DSM, but it is very common due to many/most users trying to acquire/renew a certificate for a subdomain name of a very popular apex domain name.
The main limit is Certificates per Registered Domain (50 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name
www.example.com
, the registered domain isexample.com
. Innew.blog.example.co.uk
, the registered domain isexample.co.uk
. We use the Public Suffix List to calculate the registered domain. Exceeding the Certificates Per Registered Domain limit is reported with the error message too many certificates already issued, possibly with additional details.
How do I check the status of my certificate through OCSP?
How do I enable OCSP stapling on my web server?
Under what circumstances should I request a "must staple" certificate, and how do I do so?
What is the "alternate" chain and under what circumstances should I have my ACME client request it?
I see a couple requests from Let's Encrypt's validation servers in my web server logs, but I'm still getting an error that Let's Encrypt can't connect to my server. How many connections from validation servers should I be expecting?
How do I check that my DNS servers are working correctly with the DNSSEC/IPv6/0x20-case-randomization/EDNS/TCP/etc. options that Let's Encrypt uses?
What is the email address that gets entered into my ACME client used for?
Whose email address should I use?
[I'm not sure exactly how to word this, but something about how it should be the person who is responsible for the certificate itself, so it might not be the "owner" of the website but instead a contract mail for the hosting company. For instance, the acme.js library documentation tries to distinguish between "maintainerEmail" (who wrote the code), "subscriberEmail" (who has control over the private key and should be able to fix renewal issues), and "customerEmail" (who actually doesn't matter to Let's Encrypt at all) as some way to try to help people understand the parties involved.]
The wrong email address is getting expiration warning emails from Let's Encrypt; how do I update it?
How do I set up different expiration-notice email addresses for different domain names?
What are best practices for monitoring that my ACME client is in fact renewing and installing everything automatically and getting alerted when there's a problem?
I've actually been considering making a copy of my CertSage ACME client and stripping out the certificate acquisition components to make a simple ACME account email address updating tool. It would basically end up being a super small PHP program that just takes the account URL, account private key, and new email address.
I wish that Let's Encrypt would send a notification email when an email address is added/changed for an ACME account. It would provide some reassurance to users that they will receive future notifications. I suspect there might be an initial deluge that indicates unnecessary behavior of some ACME clients, but in the end I think it will really be beneficial.
I've toyed around with starting to make a standalone page for compromised-private-key cert revocation, all browser-side, but haven't gotten very far with it. I suspect that the hardest part of an email-updating tool like that, though, is helping people find their account private keys since that's different per client, and the ones that'd need a tool like that most are probably the less-popular clients. (I mean, if they're using certbot they can just use certbot's command for it.)
I think I've mentioned that myself somewhere around here; along with a notification email when the account private key is changed.
I'm not quite sure what you mean here; you think there are clients that update account email addresses to different values regularly?
You read my fear.
Some ACME clients update the email address every run. CertSage only updates it if the user actually enters an email address in the form on subsequent runs. Granted, it would be relatively easy to filter non-updates (to the same email address). There could be ACME clients out there doing all sorts of strange things, like creating a new account with every run. I suspect the misfits are a small minority, but wherever there is the possibility of "spamming someone", caution should be taken.