Suggested steps to transition from paid to L.E

Hello,

I did a search of the forums for the terms "transition from", "moving from" and "leaving paid" but did not find a discussion that met with the info I was hoping to find.

Just simple - if you are already on a paid SSL service, and are wanting to move to L.E., what would be the most important two or three steps to do first to avoid your SSL / website suddenly becoming invalid as you make the move over?

1 Like

Hi @JHS

it's completely unrelevant if you have

  • no certificate
  • a paid certificate
  • an older Letsencrypt certificate

Install a client and create a new Letsencrypt certificate. Then install it.

1 Like

Thank you Juergen. So basically once I enable a Lets Encrypt cert, it will smoothly override the paid version we have with a different provider and won't cause any errors?

It will not override the paid / old version. It will override the links in your webserver configuration file.

The older certificate files aren't deleted if you install a new certificate.

Or, with Certbot: The config file isn't changed, the destination of the symlinks is changed.

Ok so if I understand correctly...

Installing the new cert will mean the certificate tells an arriving visitor that their system will speak to Lets Encrypt to verify the certificate authenticity.

The fact that I still have time left for a paid SSL with a different provider won't matter. I do not need to revoke the prior cert with the paid provider? Things will just start running from the new CA and that's all?

Welcome to the Let's Encrypt Community :slightly_smiling_face:

When you install a certificate from a new CA on your webserver, you are instructing your webserver to present/send that certificate to your visitors instead of the certificate from your old CA. The "subject" fields (e.g. common name (CN) and subjective alternative names (SANs)) will remain the same, but the "issuer" fields will change. More specifically, the CA certificate (or rather its private key) that issued/signed your new certificate will be different and thus the "chain" from your certificate to the CA "intermediate" certificate down to the CA "root" certificate will be different. Think of your certificate as a leaf with your new certificate being part of a different tree than before. Thus, your visitors' browsers will use the new CA's "intermediate" certificate to verify your certificate. As a matter of practice, the public key contained in your new certificate will typically differ from the one contained in your old certificate, but this is not a requirement.

There is rarely ever a need to revoke a certificate. Securely deleting its private key is usually sufficient. The only purpose of revoking a certificate is to prevent someone who has obtained the certificate's private key from masquerading as one of the SANs on the certificate.

Could you maybe clarify what you're worried about? Do you have a lot of certificates and use some sort of centralized management with your current provider that you're looking to replicate? Do you have a testing environment that you're looking to make changes in first? Or do you just have a server or two, and you've been uploading certificate files manually and you're not sure about the process of running software that installs the certificates for you?

No, revoking a certificate is pretty much only ever needed if somebody has the private key that shouldn't, or if you no longer own the domain. You just need to make sure they don't keep trying to charge you or automatically renew for you or the like.

Pretty much. You may just be overthinking this. Having certificates from multiple providers that are both unexpired at once is pretty normal, especially when transitioning from one CA to another.

1 Like

Fantastic, thank you. I was probably not describing it well further up. I had a feeling it would be that the new cert would then have a whole new chain of checks, but wasn't sure if I needed a Revoke for the old one once we move over. Now to begin the actual process... thanks again for your rapid replies and clarity!

1 Like

Hello @JHS,

For me, the things you should review before the transition are:

1.- The big difference between a certificate issued by Let's Encrypt and your current certificate could be the validity, Let's Encrypt certificates are valid for 90 days and maybe your current certificate is valid for 1 year so you should renew the certificate more often, ideally every 60 days so in case there is any problem you have 30 days to solve it.

2.- As Let's Encrypt certificates are valid for 90 days you should found a way to automate the process (renew the certificate and reload the services using it) without manual intervention (and that is one of the reasons LE certs are valid for 90 days, to force users to automate it).

3.- You should think how you will validate your domain to get a certificate, there are 3 types of challenges (http, tls-alpn and dns) so depending on your needs or the services you are using then you should know which one you will choose.

4.- What is the acme client you will use to get the certificates? There are tons of clients (the official one is certbot) so depending on your needs you should use one or another client. Once you choose the right client you should learn how it works, how to issue a cert using it, how to renew the certificate, how to reload the services with that client and so on.

5.- Test, test and test and once you are confident with the process, go ahead and switch to Let's Encrypt :wink:

Good luck,
sahsanu

2 Likes