Removing OCSP stapling with forced reissue of cert

Where an existing cert has been issued with certbot using the --staple-ocsp flag, would re-running certbot without the --staple-ocsp flag and electing to renew the certificate obtain a new certificate without the OCSP stuff?

In other words, if there's an explicit, forced cert renewal request outside of the scheduled system renewal without the OCSP functionality, does that carry through to the issuing server?

I fear this might be an obvious answer, but I'd be grateful for clarity from someone smarter than I.

Thank you, and best wishes.

That seems likely. Maybe someone else knows for sure but I'd have to try it and report it here. Probably easier for you to do that :slight_smile:

If you want us to look at it first please show:

sudo certbot --version
and contents of the
/etc/letsencrypt/renewal conf profile for that cert.

3 Likes

I'm not certain :man_shrugging: It could be Certbot would see the existing renewal configuration file and just uses that.. But it could also be (and I think that's more likely) it'll rewrite the renewal configuration file with the new input. E.g., if --must-staple and other flags are missing, Certbot won't implement them. But I'd say it's 60/40 which behaviour will happen..

Certbot really sucks when it comes to modifying existing certificates. Just not enough thought and effort went into that. I suggested and made some PRs for some simple enhancements (e.g., a --no-...feature.. flag which disables a previously enabled flag, but noooo..

2 Likes

Yeah, I wondered that too. But, if you re-do the original command it seems it should follow the default of not doing Must-Staple. And, hopefully update the renewal conf appropriately.

I am a little surprised the Certbot team did not publish a short advisory on this. I guess we'll just have to work each one case by case. :frowning:

2 Likes

I'm not sure they got a heads-up from Let's Encrypt about this.

Also, seeing how little time the team has for Certbot, I'm not that surprised at all to be honest. A little bit disappointed, yes, surprised, no. No blame though.. It's not their full-time job I'm sure.

1 Like

Thank you @Osiris and @MikeMcQ - I really appreciate your feedback.

I'm going to answer my own question with the pointer provided to the renewal config (today I learned), I wasn't aware of that before now.

$ sudo certbot --version
certbot 2.1.0

This is the renewal config for a cert issued before the OCSP changes:

$ cat ./darwin.tlsvps.com.conf 
# renew_before_expiry = 30 days
version = 2.1.0
archive_dir = /etc/certbot/archive/darwin.tlsvps.com
cert = /etc/certbot/live/darwin.tlsvps.com/cert.pem
privkey = /etc/certbot/live/darwin.tlsvps.com/privkey.pem
chain = /etc/certbot/live/darwin.tlsvps.com/chain.pem
fullchain = /etc/certbot/live/darwin.tlsvps.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = ca7de859d4178e2e1805a9507b47aeff
rsa_key_size = 2048
must_staple = True
config_dir = /etc/certbot
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = webroot
webroot_path = /var/www/heartbeat/_well-known,
key_type = ecdsa
[[webroot_map]]
darwin.tlsvps.com = /var/www/heartbeat/_well-known

Here's my command for the server FQDN with --staple-ocsp removed (excuse the variables):

sudo /usr/bin/certbot \
certonly \
--agree-tos \
--cert-name "$fqdn" \
--config-dir /etc/certbot/ \
--domains "$fqdn" \
--email "$certbot_email" \
--key-path /etc/certbot/live/"$fqdn"/ \
--no-eff-email \
--rsa-key-size 2048 \
--server https://acme-v02.api.letsencrypt.org/directory \
--webroot \
--webroot-path "$www_prefix"/www/heartbeat/_well-known

As expected, this prompts for a renewal:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Simulating renewal of an existing certificate for darwin.tlsvps.com
The dry run was successful.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Certificate not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/certbot/renewal/darwin.tlsvps.com.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the certificate (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for darwin.tlsvps.com

Successfully received certificate.
Certificate is saved at: /etc/certbot/live/darwin.tlsvps.com/fullchain.pem
Key is saved at:         /etc/certbot/live/darwin.tlsvps.com/privkey.pem
This certificate expires on 2025-04-28.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

…and, for completeness, the post-renewal renewal config looks like this:

$ cat ./darwin.tlsvps.com.conf 
# renew_before_expiry = 30 days
version = 2.1.0
archive_dir = /etc/certbot/archive/darwin.tlsvps.com
cert = /etc/certbot/live/darwin.tlsvps.com/cert.pem
privkey = /etc/certbot/live/darwin.tlsvps.com/privkey.pem
chain = /etc/certbot/live/darwin.tlsvps.com/chain.pem
fullchain = /etc/certbot/live/darwin.tlsvps.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = ca7de859d4178e2e1805a9507b47aeff
rsa_key_size = 2048
config_dir = /etc/certbot
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = webroot
webroot_path = /var/www/heartbeat/_well-known,
key_type = ecdsa
[[webroot_map]]
darwin.tlsvps.com = /var/www/heartbeat/_well-known

When I diff the before & after, the only change is the removal of must_staple = True.

So, no more OCSP.

Thank you again @MikeMcQ & @Osiris - I really appreciate your guidance.

4 Likes

Terrific. I see your new cert but looks like your nginx server still using the prior one. Server probably just needs a reload :slight_smile:

3 Likes