New Certificate to overwrite/invalidate the old one

Hi, i just wanted to ask a quick question regarding generating new certificate.

I have migrated my site from server (VPS) A to B, both running Apache, with /etc/letsencrypt copied to server B as instructed here, no problem since the cert hasn’t expired. Then i turned off Server A completely (as i suspect there’s been a breach) with the intention to delete the server later.

Now if i want to be safe and generate new certificate on Server B by installing Certbot, should i delete or revoke the old certificate on Server B prior to that?
Does the process of installing Certbot and generating new certificate automatically invalidate the old one? What should i do to make sure the old one is permanently inactive?

Thank you.

1 Like

You can revoke the certificate, if you want. Issuing a new one won’t invalidate the old one - they will both be valid simultaneously.

That said, if you believe the server was compromised, then it’s more than just your certificate private key which is compromised, it’s also your Let’s Encrypt account, which is at least as bad.

Better to start over with a fresh /etc/letsencrypt, or at least, certbot unregister and certbot revoke to invalidate your old account and then revoke your certificate from your new account.

3 Likes

This will be a fresh Certbot install, only the /etc/letsencrypt is from the old server.

I’m planning on using the same email address i used when generating the old cert, that shouldn’t be a problem if i understood correctly? I’m also not sure if a cert equals an account.

If i generate before revoking the old one, wouldn’t i be revoking my new cert since the path to the cert is unchanged and the old cert is overwritten? or am i misunderstanding how it works?

If i revoke and wipe /etc/letsencrypt prior to creating new one, i’d be temporarily changing my virtual server config to http–which is fine since i’ll immediately generate a new cert, but it would be better not to, if possible. But i guess it’s the only way to be sure if the old one is invalidated and leave no trace on my server.

Any thoughts?

1 Like

Stop.

Just install certbot and get a fresh new certificate, as if it was the first time you got one.

Leave the old server and its /etc/letsencrypt directory alone… just copy the old certificate and corresponding private key if you need to bootstrap the new server.

1 Like

Let me rephrase my main question:

  • Old server had been compromised. Backed up /etc/letsencrypt. It’s now inactive pending delete.

  • Fresh built new server, no Certbot installed, used backed up /etc/letsencrypt on new server, expires in 4 weeks.

  • Just to be safe, i want to revoke the cert and generate new one, and make sure the old one’s non usable.

Should i let it expire, if expire means automatic revocation. Or revoke manually?

I want to get it over with asap, so might do the 2nd option, but does anyone have suggestion or am i missing something important?

Is there a way to create new certificate with same domain name alongside the old one, use the new one, and then safely revoke the old one, so the process is seamless without editing my server config like if i do the revoking first?

1 Like

This is up to you. If old server is compromised this choice can be taken away from you by whoever has your account key (that is not your certificate key). This is the reason you must not reuse the old /etc/letsencrypt directory: whoever compromised the old server can revoke any certificate you issue on that acme account. If you have a lot of certs and you don’t want to start over, at least make a new acme account: certbot register should tell you enough.

1 Like

Since there’s no thorough documentation regarding Account management that i could find, i assume whenever you create (not renew) a certificate, that’s assigned to a unique account regardless of the email address?

I’ve identified my Account ID/URI for the only certificate that i want to revoke, i have no other certs for any domain in this server. Is it safe to just abandon the account and just revoke the cert?

So the steps i should take, correct me if i’m wrong, are:

  1. Revoke the cert
    certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem

  2. Unregister the account for that cert
    certbot unregister --account accountid

  3. Delete cert dependencies in /etc/letsencrypt
    certbot delete --cert-name example.com

  4. Edit my virtual server config to run on HTTP

  5. Create new cert (automatically associated with new unique account)
    certbot --apache

  6. Update config to redirect traffic to HTTPS

No. Accounts are represented by an actual private key.

ls -R /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/

If that private key is compromised, it can be used to revoke your certs.

Follow @_az’s advice in the first reply.

1 Like

Ah, ok.

So which of the following actions will create a new account (private key)? I’ve never used #3 so #1 or #2 must have created my account.

  1. Fresh Let’s Encrypt/Certbot install
  2. certbot --apache or create new cert
  3. certbot register

Will the following actions do to purge my account?

  • Revoke the cert first

  • Then do certbot unregister

  • Finally, delete everything inside /etc/letsencrypt/

What does the certbot unregister command output on successful account deletion?

1 Like

Actions 1 and 3 will create a new key. Action 2 won’t. I don’t know what happens if you run certbot register with an account already present, though.

My suggestion: start fresh on the new machine. After your’re positive it works, log in on the old machine, and there on the old machine, revoke and unregister.

1 Like

The new server is already up and running using the old cert with no Certbot installed, so it’ll expire in 4 weeks. Old server is gone.

My plan was to install Certbot and unregister the account, but idk after knowing that installation creates new account.
Why is this not in the documentation?

1 Like

Install certbot on the new server, forget about the old one. In four weeks both the certificate, its private key, and the old account key will be of no use to anybody.

If you still want to revoke the old certificate, you don’t need the account key, the private key is enough (I’d have to search how it’s done, though).

My new advice: configure the new server with a fresh install of certbot and stop worrying.

1 Like

Alright, so i’ll start from scratch and delete everything inside /etc/letsencrypt so Certbot installation will create a new account & private key, then create a new cert.

And if i want to revoke my old cert (already backed up), i’ll do this from my new account.
Once it’s revoked, can someone with my old account’s private key still use it to sign certs? how do i prevent that if i didn’t delete the account?

1 Like

They can use any valid authorization on the account. Authorizations expire 30 days after you perform a challenge. If you didn’t perform any challenges in the last 30 days you’re fine. (keep an eye on crt.sh to see if they’re issuing certs)

1 Like

Do expiration checks count? Probably already more than a month without expiration checks since i disabled it on the old server. Last successful renewal was 2 months ago.
How will the old account expire if i just ignore it?

What in particular should be the red flag? I searched by thumbprint and domain name, and they seem fine.

I’m not expecting a private key compromise, just being cautious and a bit paranoid. Just want to make sure there’s no zombie causing trouble in the future.

1 Like

If you see certificates you do not recognize that’s the red flag. :smiley:

1 Like

Only with the domain name that my old cert was for, am i correct? not any other domain?
As long as i ignore and not renew the old cert, this would not happen right?

Any domains you are concerned about, really. Any domains you made a certificate for on that machine.

My confusion is regarding the old account and its key, if someone has access to the key, is it safe enough for me to ignore the account knowing that the account key is never invalidated?

yes, as long as they have no ability to perform challenges. (For example, if you have dns records pointing to a compromised machine, or if the old machine had dns api credentials on it)

2 Likes