Had to revoke some certs, now I'm stuck

Help
1

I have some 50+ domains. And, I have some offsite storage. I usually use rsync to make backups and made an oops when making some backups as there are two forms of the command I generally use, one for internal backups on an internal network and one that does full encryption when going to an offsite storage area. ... And, yeah, I inadvertently sent the information in the clear to the offsite backup.

So, as the first time I had to revoke certificates, which I understand I'm obligated to do under the terms of service for receiving the certs in the first place, I followed the revoke procedure... Thankfully, it wasn't for all 50+ domains!

Anyway, I followed this advice.

However, when I went to issue new certificates, I've created a catch 22 problem which appears to be caused by the fact that I listened to the advice certbot gave and told it to delete all the existing cert files. -ugh!-

I BELIEVE THIS TO BE BAD ADVICE.

Why? It prohibits Apache from running (starting) and therefore certbot can't / won't authenticate, and the old files are now gone so you can't authenticate from the old private keys.

Creating all new certificates is a huge headache because certbot always trashes the apache configuration file. SURE, it works OK for the most basic configuration but do something out of the ordinary and it breaks and has to be fixed by hand.

I just cannot afford to spend hours fixing all the broken configurations of some 50+ domains.

So, AS THE ONLY WAY OUT without having my web sites all down for a long time, was to RESTORE THE BACKUP, thereby using the revoked keys again and this time issuing:

certbot certonly -d ...

This SEEMS to have worked, but I've only tried one domain and its subdomains...

But surely I am doing / have done it wrong?! Surely you wouldn't have given us all this terrible advice?

(Yes, I'm frustrated by this lost time and unnecessary downtime.)

So, how is someone SUPPOSED to do this?

2

The Catch22 can be broken by two things:

  • Temporarily disable the HTTPS VirtualHosts in Apache;
  • Generate a self-signed certificate file (sometimes called a "snake oil certificate") and configure your Apache HTTPS VirtualHosts to use that certificate temporarily, so Apache at least starts. Your users will see a certificate warning if you keep the HTTP to HTTPS redirect in place tho, so you might want to disable that redirect.

And yes, I agree: the fact certbot is able to do the HTTP to HTTPS transition when getting a certificate, but NOT being able to transition back from HTTPS to HTTP when deleting a certificate is, well, in my opinion very bad. It probably has something to do with the fact that appending a configuration file to Apache is easy, but deleting something, which might contain edits by the user after the HTTP to HTTPS transition is difficult, as those edits are not as easily recognisable.

I've made an issue on the certbot github page about the lacking warning: Warn user for broken webserver configurations when deleting a certificate (after revoking) · Issue #8755 · certbot/certbot · GitHub

1 Like
3

Hi @stwm

you have to revoke the certificates.

But before doing that:

Create a new certificate and replace the certificate you want to revoke. So that certificate isn't longer used.

Then you should have no trouble.

2 Likes
4

Is that something easily done with certbot? I can imagine that you'd just use certbot renew with some kind of option to force renewal.. But then revoking gets relatively hard, as you'd need to point to the leaked certificate(s) from the /archive/ directory.

Or you would need to get new certificates with new --cert-name options, which is quite a hassle for 50+ certificates.

I personally would probably write a small Bash script identifying still valid but not the most recent certificate in /archive/ and revoke them if I had 50+ certificates to revoke :stuck_out_tongue:

1 Like
5

... It's clear to me now that "revoke" is somewhat broken:

It needs a feature that permits the creation and deposit of a new cert to replace the old one WHILE at the same time revoking the old one.

This may not cover all circumstances, such as a site that's been broke in to, but for a case like mine, it would be perfect.

... When I have some more time, I'll be making a product enhancement request!...

Thanks for the suggestions, guys.

1 Like
6

... I propose certbot do that for us! After all, if you're compromized, you're probably under stress, and if you have lots of domains and those have lots of subdomains, what you propose is non-trivial, even to script unless you did it in advance... BUT, certbot has direct access to the original certs, can see what belongs and can BOTH delete the bad cert and replace it forth-with...

That is, revocation should accompany creation of replacements whenever possible.

I've now proposed this officially! It'd be nice if it got some "up-votes" or however that attention happens! :slight_smile:

7

Revocation is often not accompanied by creation of replacement certificates by the controller of the revoked certificates.

This is the case with:

  • decommissioning hosting instances
  • releasing control of domain names
8

As an aside, Let's Encrypt http validation will follow invalid certs during the domain validation process, so to recover any webserver configuration that has missing cert files you can apply an invalid cert (i.e. set/copy one for a different domain or a self signed one) then ask your acme-tool (certbot in this instance) to force renewal.

2 Likes
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.