Migrating an SSL Certificate from one host to another during site migration

Question

We are helping a new client migrate their site from a previous unreliable host, over to a new host (cloud based). They run an ecom site with an SSL Certificate (GeoTrust SSL). We plan to move their site for them and then just update the D.N.S to the new server.

The issue here is that the current host is not playing ball (with us or the clients). Our client owns the domain name but did not register the ssl certificate. We don't have access to their current server.

Would we be able to get another certificate issued (but keep the old one running)? Does this vary by provider?

Answer 1

Presumably, the current certificate, for which you don't have access to the private key, was issued at least using domain-validation (i.e. an e-mail asking for confirmation should have been e-mailed to the address with which the domain is registered, obtained via whois).

When you say "Our client owns the domain name", the key is to make sure your client receives the e-mails for all the necessary contacts (in particular, that those e-mails won't go to the hosting service you want to leave).

I would suggest the following course of actions (in this order):

• Contact the CA that issued the current certificate. Check with their terms and conditions, they might be able to revoke the current certificate and re-issue a new certificate within the same package, sometimes at no extra cost.
• Failing that, get a new certificate with another CA (or perhaps the same).

In both cases:

• You will have to generate a new certificate request (CSR), which will give you access to the private key. (Ideally, it's something that your client themselves should do, if they have the technical staff to do so.)
• You should really contact the current CA and explain the situation. As the legitimate owner of the domain (with which the certificate was presumably validated), your client should be able to have the current certificate revoked. You should effectively treat the current certificate as compromised, to prevent anyone who has the current private key to run that site in parallel (although presumably, you will at least have changed the DNS to your new host).

Regarding your concerns in comments:

Do they communicate among themselves, or are they happy to issue certificates as long as they can be installed within a certain period of time? My worry is that we will go and get another SSL certificate and it will be revoked because the dns will not be switched over for a week to 10 days after we install it on the new server.

The CA will issue a certificate for a host name you control. It's normally their business to check that you control the host name at least (via whois register), but this has nothing to do with the specific DNS entry that resolves this host name into an IP address. You can change the IP address and/or not have the server online: it's not the CA's concern.

Given that our client does own the domain name, can they just go to a different SSL provider and get another certificate? (what would stop me just buying an ssl certificate for some random website in that instance) I'm worried about revoking and issuing a new certificate unless that something that can be done within hours. We can afford a couple of hours downtime overnight, but no more than that.

You can definitely have two different certificates for the same host name from two different CAs at the same time. It generally only makes sense when to you to switch provider, since you can only install one at a time on a given server. There doesn't need to be any downtime at all. (The longest downtime is likely to come from the global propagation of the DNS updates when you switch to the new provider.)

what would stop me just buying an ssl certificate for some random website in that instance?

It's all about who controls the domain (and for EV certs, there's a bit more paperwork too): check your client's whois entry.

Answer 2

You should be able to generate a new ssl key and get a new certificate that answers to the hostname in question if you control the domain dns. End users will not notice that change as long as the new ssl cert is valid - IE issued by a CA like Entrust

Answer 3

Depends on the SSL provider.

You definitely should be able to get the cert from the hosting provider (break out the lawyers!), but if that fails, some certificate authority companies will revoke the old and issue a new cert (with the same expiration date) for no extra fee.

Of course, if the host bought the SSL cert, and not the client, then they might not be in any better position to request a new cert than to get the current one.

Answer 4

If I understand your question correctly your situation is that the old hosting provider will not give you the SSL certificate and private key you are currently using? That seems VERY shady to me.
Having worked at an ISP/MSP that did hosting and SSL Certificate registration I can see no legitimate reason why they would not give you the key pair for your certificate (provided your account isn't in arrears).

In this case I would take two steps:

1. Contact the CA that issued the original certificate (the info will be available if you look at certificate details in your web browser) and let them know what's going on.
   Request a new certificate be issued, but that the old one be left functional until you advise them otherwise.
   If they can't do that for you contact a different CA and get a new certificate issued.

2. When you migrate the site to the new host (using the new certificate) contact the CA that issued the original certificate and ask that they consider that certificate compromised and revoke it.
   This will prevent your previous host from using that certificate for any malicious activity.

Answer 5

Export the SSL certificate from the server with the private key and any intermediate certificates. Convert the certificate to a different format if you are putting it on a different type of server. Import the SSL certificates and private key on the new server and configure your sites to use them.