But there's a similar solution, being that CSRs do not expire.
You can just run certbot again with the same CSR.
3 Likes
Certainly.
The issue then becomes making sure you're not requesting the same certificate over and over, the rate limits won't like that.
But checking the expiration is easily scriptable:
openssl x509 -checkend $((3600 * 30)) </etc/ssl/certs/ISRG_Root_X1.pem
Checking for revokations... it should be easy as well, but it's a mess. There's a reason they say not to roll your own encryption.
(yeah, that's 30 hours, I always forget to multiply by 24)
5 Likes
Sigh. It is not very configurable. Certbot is quite rigid.
It is very flexible thanks to all the extensible hooks, but it is pretty strict in terms of it's own capabilities and requirements for input and storage. You can use the hooks to accomplish many tasks, but you are stuck with doing things the Certbot way.
Versioning concerns can be "handled" with that hook, but one should leave Certbot's directory as-is. The certificate/key/chain should be copied from Certbot's native storage to wherever desired. The native storage should not be altered.
In terms of relevant hooks to this thread:
--pre-hookruns before Certbot--post-hookruns after Certbot--deploy-hookruns after successful certificate procurement
Also, since the placement of challenges was once mentioned... one can also run Certbot in "standalone" mode on a higher port (such as 8080), and proxypass traffic from port 80 onto that via a commandline flag like --http-01-port=8080. Certbot will then run it's own webserver on 8080 and handle the entire process. LetsEncrypt must still successfully reach out and connect on port 80 - hence the proxypass - but this avoids most configuration with the existing webservers.
I'll just reiterate though - under ACME2, a pre-generated CSR is used as a data-source by the client. Certbot will parse it for domains, generate an ACME order, and then only submit it during the "finalization" process to prove ownership of the Private Key. Stated differently: while the conventional way of obtaining a certificate was carefully crafting a CSR to "order" a certificate and trigger validations, ACME2 will first generate an order, validate the domains, then carefully craft a CSR to match the order details and best ensure issuance; the process is essentially reversed.
5 Likes
--post-hookruns after Certbot--deploy-hookruns after successful certificate procurement
Does deploy-hook only run after all certs have been renewed?
Maybe I am just missing it, but I can't tell from the docs.
From what I can tell (documentation and source code), deploy hooks are run immediately after certificate issuance. So if you renew 3 certificates, Certbot will first get the first certificate, run deploy hooks, if any, for that cert, then renew the second cert and afterwards run the deploy hooks for that one, if any, and so forth.
2 Likes
Nope. Once for each certificate. Different certificates can have different hooks (they are saved in certbot's config).
3 Likes
That's actually not a sufficient argument, as e.g. all the "per certificate" post-hooks are saved during renewals (which can also be saved on a "per certificate" basis) and only run at the end of Certbots renewal run.
That's strange, pretty strange. Some hooks define environment variables to help avoid this issue.
1 Like
Only --deploy-hook uses environment variables to use in the script I believe.
1 Like
It makes sense.
But you made me think about using pre/post-hook to open/close port 80, and that... has no reason to be global if you're only using it on a few certificates...
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.