Hi, I try to get a wildcard certificate (with an EC based key) with the must-staple extension from the staging server. The certificate will be created but without the extension:
certbot certonly --manual --must-staple --preferred-challenges dns --server https://acme-staging-v02.api.letsencrypt.org/directory --csr csr.req
certbot 0.31.0
What am I doing wrong?
Thanks
Have you tried --staple-ocsp? I think you generally need to specify the --must-staple part on first creating the certificate and it won't have an effect for renewals. See also: Certbot enhance --must-staple - #3 by Xan
You're using the --csr option. That means "all bets are off" in a manner of speaking.
That option heavily modifies how Certbot works and which options are useful and which are not.
E.g., your "--must-staple" won't do anything, as Certbot can't modify your CSR to include it.
Good catch @Osiris !
@jfs I'd also add that your version of certbot is from a few years ago so you should ideally update that. I don't think that's affecting anything here though.
Thank you, After removing the argument from the cmd line and adding it to the CSR, it works as expected! 
Do you actually need to use the --csr option? It disables most of Certbot features:
/etc/letsencrypt/ location and they count up from 0000 I believe if new certificates are issued. There is NO symbolic linking to the most actual certificate/chain, so you'd either need to script something yourself to keep the actual certificate in the correct place, do that manually or manually reconfigure your service to point to the correct certificate. Note that certificates are only valid for 90 days and LE recommends to renew after 60 days.My advice is not to use the --csr option. Maybe you require an option not available in your older version as @webprofusion already stated and you are required to resort to the --csr option? In that case I recommend to upgrade your Certbot, perhaps not using the package of your distribution, but change to the "snap" distributed version. Or "pip" if snap isn't an option.
Hi @Osiris, I guess I need the --csr option as I'm not deploying a standard web server, but a homegrown one. The dns challenge is needed to obtain a wildcard certificate.
I fail to see why deploying a non-standard webserver would require the --csr option? I would urge not to use that option as it complicates almost everything.
If you really require a wildcard certificate (which is often not the case, even if people think they require a wildcard.. Let's Encrypt certificates can contain up to 100 hostnames per certificate, so lots of room for many subdomains..) then yes, the dns-01 challenge is indeed necessary unfortunately.
As part of the automation to get a wildcard certificate I call certbot now with the option --manual-auth-hook to do the requested DNS changes automatically, but LE caches successful verification per DNS for some time (30 days?) and my script will not be called. Is there a way to enforce validation again (instead of waiting until it expires)?
When Certbot is being run with the --dry-run option, it won't reuse already valid authorizations. The --dry-run option also uses the staging environment, which should also be the environment used for testing, so that's a win-win.
If your ACME client implements it, there is.
But you should really use --dry-run.
That's exactly what Certbot is using when ran with --dry-run @9peppe 
See:
Cool. I just assumed the staging endpoint had different caching period for authorizations (kinda... 0s?).
Nope, Certbot is actively deactivating the valid authzs. However, --dry-run also automatically implies using the staging environment 
Thank you both, for your quick answers and explanations!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.