certbot should really have available simple CLI means to
deactivate authorization(s)
E.g.:
$ certbot --deactivate-authorization -d DOMAIN [-d DOMAIN ...]
And along with that support relevant related options, e.g. to
specify account, --staging, --server, various directories and
configuration file, etc.
It shouldn't be the case that to force fresh authorization on
same domain, one needs create new account(s) and litter letsencrypt.org with such additional data, when one merely wants
to deactivate authorization for domain(s) / force fresh
authorization for domain(s). Should really be a simple CLI means
to deactivate authorization(s) that's highly compatible with certbot
and its data, but appears that doesn't currently exist.
I'm not familiair with these "many" requests. What's the use case for this feature?
Also, this category Feature Requests is not for Certbot, as Certbot isn't developed by Let's Encrypt, but by the EFF. Please see the Certbot Github repo.
First, @Osiris made good suggestion about making this request to the EFF
But, I'm just curious ... why do you often need to deactivate authorizations?
Certbot will deactivate auths when using --dry-run and the Let's Encrypt staging system, for example. If you are testing your auth procedure you should be using LE staging anyway.
And, it's possible this would work to do what you said. I just didn't try it (it rarely comes up)
The --dry-run option sets the LE staging by default. But, if you specify --server after that it might override that while still giving you the deactivation. Emphasis on might
why do you often need to deactivate authorizations?
testing, notably to (re)test/(re)validate and create authorizations. E.g. with certbot certonly --manual --manual-auth-hook authprog --manual-cleanup-hook cleanup prog
The hook programs aren't even executed with the authorization still in place - which as I understand it persists for (about) 30 days. Only work-around I'm aware of for that are use a different account that doesn't currently have authorization for the domain or use a different domain that doesn't have authorization (still) in place.
enhanced security - deactivating the authorization (moderately, at least) enhances security, by disallowing reuse of the existing authorization - thus requiring the authorization steps to need to be completed (again) before (re)issuing certificate, etc. - it's potentially an additional safeguard/control. Without being able to deactivate authorization, account authentication alone is sufficient to get cert(s) (re)issued for same domain(s).
Certbot will deactivate auths when using --dry-run
Thanks for the idea, but, unfortunately it does not at all, the existing earlier authorizations persist. In fact --dry-run likewise creates authorization, and that can even be used after without --dry-run, and it then reuses the existing authorization - no HTTP-01 nor DNS-01 verifications/checks are done, it simply reuses the existing authorization - and I presume that likewise persists for (about) 30 days.
While certainly certbot could offer better options for handling authorization deactivation, and I don't think that other clients necessarily make it much easier, your needs might also be served by picking the "tlsserver" profile that limits the Authorization Reuse Period to 7 hours instead of 30 days. The clients you're expecting to connect to your server (and your server itself) would need to not require the other backwards-compatibility features of the default classic profile, but it's possible that it would work for you as well.
Certbot isn't developed by Let's Encrypt, but by the EFF. Please see the Certbot Github repo
Okay, thanks, I'll have another look around there. When I was looking earlier didn't easily spot an particular pointers for "feature requests" or the like, but I'll have another look.
The deactivation is for the auth so is matched to the order (set of domains in cert and account)
But, --dry-run does deactivate requests both for its default LE Staging server and in combination with --dry-run --server for LE production.
Perhaps we are talking past each other but I just ran this simple test:
sudo certbot certonly --dry-run --manual --preferred-challenge dns -d www.example.com
As this was first order for this domain name there was nothing to deactivate. So, I was prompted for the TXT value, I placed it, waited for DNS servers to sync, and let Certbot proceed to issue the cert (from Staging). Now, Certbot doesn't retain certs when using --dry-run but the request was otherwise successful. It says so at the end and its log confirms
I then immediately retried the same command and the identical sequence repeated. Had --dry-run not deactivated there would be no need to ask me to place a new TXT record value because the order would have had valid authorization (in the cache).
I repeated the above test adding --server for LE production and it worked the same.
Posh-ACME has an explicit function for this.
Revoke-PAAuthorization
Documentation for the Posh-ACME PowerShell module
Thanks, and that may be quite useful to many.
Alas, since I'm on Linux, PowerShell isn't so useful in my case.
I'm mostly doing certbot CLI/TUI - typically with wrappers around it and hook programs.
sudo certbot certonly --dry-run --manual --preferred-challenge dns -d www.example.com
As this was first order for this domain name there was nothing to deactivate. So, I was prompted for the TXT value, I placed it, waited for DNS servers to sync, and let Certbot proceed to issue the cert (from Staging). Now, Certbot doesn't retain certs when using --dry-run but the request was otherwise successful. It says so at the end and its log confirms
I then immediately retried the same command and the identical sequence repeated. Had --dry-run not deactivated there would be no need to ask me to place a new TXT record value because the order would have had valid authorization (in the cache)
Sorry, but that's not at all the results I'm finding.
However, devil's in the details? I'm not using precisely the same set of options as your example, and also probably not using the exact same version of certbot (actually, I'm using two versions of certbot - but I get same results on either in at least that regard). But I'll dig further, maybe there's some bug/issue that with certain option(s) (and/or lack thereof) it fails to deactivate - yet it would seem you're getting it to deactivate? So, e.g., I'm generally using it with auth and cleanup hook options, and with an already prepared CSR - so possibly something there makes the difference.
And as for testing, so far I'm now kludging around the issue, using something of the flavor random.testsubdomain.example.com and/or subdomains thereof (and quite similar under another TLD), and, well, so long as I don't repeat random, I don't have any cached authentication to contend with ... not very pretty but suffices for testing to force (re)authentication - and also being sure for the environment I don't even attempt authentication for a *.testsubdomain.example.com wildcard cert - in case that might conflict/overlap on the authentication.
Personally, I consider ARI to be an essential feature for ACME Clients.
If you are operating at scale or providing a service you should definitely review ARI. And review this if you haven't yet: Integration Guide - Let's Encrypt
I actually use PowerShell from Linux quite often both personally and at work. It's open source, cross-platform, and has been available for both Linux and MacOS for almost a decade now. But I get it if you don't want to switch up your whole environment just to get a feature you're missing from an unrelated thing.
The --dry-run option sets the LE staging by default. But, if you specify --server after that it might override that while still giving you the deactivation
Thanks. Looks like that (--dry-run) can/may be partially useful in/for testing (and probably even against production environment if production server is specified via --server option and option argument). However, all my (fairly extensive) testing seems to suggest that it does not deactivate authorization(s). But rather what it does do, which may be useful, is cause the certbot client to go through its verification steps again, e.g. with --manual it spells out the step(s) to take and waits for user input to continue (presumably after user handles those steps), and if used with --manual-auth-hook and --manual-cleanup-hook, for those options, they execute their corresponding option argument programs. So, though it may seem like it deactivate(s) authorization(s), forcing one to redo the verification steps to (re)gain authorization(s), it only does the latter part. And I've checked, using mitmproxy - no {"status": "deactivated"} is ever sent to server. Likewise checking web server and DNS server logs, there is no repeat request/query to verify again.
So, while --dry-run may be at least partly useful (depending upon the specific needs - probably most useful for certain testing aspects), it appears it doesn't actually deactivate authorization(s).
Anyway, I'll check further to see if I can find effective "easy enough" means to actually deactivate authorization(s), as that's (also) quite desirable. I also suspect others are and will be looking for such, as this question/request does at least periodically keep coming up.
And yes, I'll likely also request the feature/capability with EFF (will also check if I can find if it's already been requested and/or other possible reasonably easy/convenient means to effectively do same).
In the Certbot log (/var/log/letsencrypt directory) you should see something like below when using --dry-run. Mind you, much is removed to highlight the key parts. This was from the earlier tests I ran
uniformity/modularity of processes/processing. E.g. I generate CSRs, and feed those to CA to obtain certs. And doesn't matter what CA, they basically will all accept that ... even for my own local CA for self-signed snake-oil certs, if/when I want that for some testing purposes or other use cases. So, makes for good drop-in replacement / modular bit to well connect to LE process, e.g. obtaining certs via certbot.
also allows one to easily avoid certain other side-effects that may be quite undesired (though perhaps there may also be alternative means?). E.g. I generally do not want certbot scheduling or attempting renewals (nor installations, rotations/removals, etc.). I run cerbot, in most all regards, as unprivileged user - so it can't do those things anyway. I have my own means to, e.g. monitor certs, renew, install, etc. - and across a variety of infrastructures. So far the only modest bit of elevated privilege I allow certbot, is when using the manual hook programs, those may use sudo to execute a helper program - and only that, and nothing more, and only with the group(s)/user(s) as specified and configured in sudo, and that helper program rigorously checks what's passed to it, and can only do quite what's needed for certbot - no more, no less.
Anyway, there may be additional reasons folks want to use --csr with certbot - I think it was included as option quite early on, and for darn good reason - and I certainly very much use it, and I presume many others do too.
Fair enough. If you haven't yet you should look to incorporate ARI in your renewal plan. The main public ACME Servers all support it.
I don't think it's as common as you think. Not all of the options in the CSR carry over anyway. Ones that conflict with CA/B forum requirements are dropped. Or, in some past cases have caused request failures.
We fairly regularly guide people to let the ACME Client make the CSR and they are generally pleased with result.
With Certbot, using --CSR means you must control the renewal which, now, should be implementing ARI. In the past it meant also checking OCSP for revocations for renewals prior to normal schedule. Most people don't want to bother with all that.
Thanks! Hmmm... digging through my certbot logs - I did find at least one of those. So ... more digging/testing to do on my part. If it's actually deactivating (logs would suggest at least sometimes it does so), and I can figure out exactly what's needed to be able to consistently do so when desired, that could then be highly useful.
While you probably can twist certbot into doing the things you want it to do, you might be better off searching for another client (or maybe using certbot's underlying acme python library directly). It's very much designed for the case of just running it once and it handles the installation and renewal scheduling and all that for you. Whereas it sounds like you're looking for none of certbot's features, but just something that can speak the ACME protocol for you that you can build your own infrastructure around. I'm not saying certbot is the worst choice for that, but there probably are better ones.
"solved"(?) (/workaround) for staging, but not prod(uction).
So, fair bit more testing, and I seem to have found:
--dry-run does appear to (at least generally?) actually deactivate authorization(s) in staging. (Yay! I'd earlier missed that in my MITM data collection (missed looking at all of it), and hadn't earlier spotted that in the logs). However, the bit that's a bit tricky with that, though perhaps unsurprising if one thinks about it reasonably closely, is to not have --dry-run (re)create authorization(s) (which are generally cached for 30 days). So, when doing --dry-run, do not (re)do/complete the validation steps, so, e.g. one may want to use something like: --manual --manual-auth-hook true
or even use one's program one might typically use with --manual-cleanup-hook and supply that as option argument to --manual-auth-hook
rather than, e.g. true. So, --dry-runwill (re)create authorization(s) - if not otherwise prevented from doing so, and those will be cached. It (as "advertised") merely doesn't save cert files (and perhaps likewise key and/or CSR files? I'd not checked on that aspect).
It appears --dry-run does not work for prod - at all, contrary to the documentation - at least for Debian 13 (current stable)'s certbot 4.0.0-2, so I'm presuming that's a bug - with at least that version, and likely a bug from upstream (haven't yet checked newer and/or upstream versions of that regarding that issue). Though the documentation states that --server (and relevant option argument) can be used with --dry-run to use other than --dry-run's default of staging, it looks like it still stubbornly insists upon using staging, and that's regardless of --server option and option argument being given before or after --dry-run option.
So, in brief, have an effective deactivate authorization(s) means for staging, not supper pretty, but works well enough. But appear to have no certbot deactivate authorization(s) means for production, and appears there's a bit of a bug in that regard, notably behavior not properly matching to the documentation.
At least that's what I've got so far. I may also check, e.g. newer versions. And I'll likely put in feature request with EFF - but will also check if such feature request may already exist, etc.
and its log confirms