Move SAN domain from one certificat to another

I have about 15 domains in SANs on one certificate. I am migrating over to a new server and will be moving them over in ones and twos. What is the proper procedure to peel one SAN domain off one certificate and put in on another?

I am concerned about running into certificate issuing limits if I start just removing them off one CSR and adding them to the other.

2 Likes

The actual certificate files can't be modified once created. So what you're really asking here is how you should tell your client to add or remove names from a future certificate request/renewal. And that is ultimately going to depend on what client you're using and how you got them in the first place.

It should also be noted that you don't necessarily have to do this piecemeal. Here's how I would probably approach it.

  • Force a renewal on the old server just prior to your first migration in order to give yourself a full 90 days to complete the migration.
  • Backup your ACME client's config on the old server and restore it on the new server.
  • Disable any scheduled renewal jobs on the new server until you're done with the migrations.
  • Your new and old servers now both have the same copy of the certificate that is valid for all of the SANs and even though the new server isn't configured to renew the cert yet, it will still be valid for 90 days.
  • Migrate your sites and modify DNS records as necessary until all of the sites on the old server are now living on the new server.
  • Shutdown the old server
  • Enable and test the renewal job on the new server.

If you reach the 60'ish day point where the old server tries to renew the old certificate and fails because some of the domains are no longer pointing to it, don't worry about it if you think you'll be done before the old certificate expires. If it is going to expire before you're done, then you can deal with modifying the client config on each side to remove the domains each one is no longer valid for. Then you'll have to continue to modify the new server config and request new copies of the cert as you move the rest of the domains to it.

3 Likes

Which rate limits are you worried about exactly? Because the most relevant rate limit here is the maximum number of 50 certificates per registered domain per week.. But you're saying you've got 15 domains. If those 15 domains are actually 15 separate registered domains and not subdomains, you won't get into trouble if you transfer one domain at a time. 15 is less than 50 :slight_smile:

The rate limit of 5 duplicate certificates per week isn't an issue too, as every new certificate will contain a new set of hostnames, i.e., no duplicate.

It's also highly unlikely to hit any other rate limit.

3 Likes

Yes, it's the duplicate certificate issue I was concerned about. I was envisioning moving the domains over one-by-one as I completed the migration and running into the limit for duplicate certificates for the domains remaining on the old server.

Old Server:

  • oldserver_staying.ca
  • togo01.ca
  • togo02.ca
  • togo03.ca
  • ..
  • togo15.ca

New Server:

  • newserver_temp.ca

I envisioned migrating over togo01.ca - togo15.ca one by one. As I removed each from the old server's CSR and added them to the new server's CSR and requested new certificates I was concerned about running into duplicate limits for staying.ca and temp.ca, for example.

I blinked a couple times when I read your reply. For some reason I had it in my head that the certificate was tied to the IP address of the server that domain ownership was verified on. I know it's not, but the part of my brain that thinks in network just automatically sees the IP as the real destination and the domain name as ephemeral and didn't even consider the obvious answer. Of course it makes sense to make a superset certificate and install it on both servers, then I can point the domains over one by one as I make them ready.

I still have this feeling of being naughty, though. Like I'm putting something over on the world by getting a certficate in one spot and using it somewhere else. Shhh. Don't tell.

Thanks, btw!

2 Likes

if you can move entire thing in two month, just copy entire certificate(and privkey) into new server. (keep mind of permissions!) it doesn't strictly need to be sit on a single server.

2 Likes

Exactly. :grin: The only caveat is the 90 day lifetime because if you're using HTTP based challenges, you won't be able to renew the one certificate with all of the names until all of the names are either on one server or the other.

3 Likes

I regularly have my certificates made on one server (an AWS Lambda function using a DNS challenge) and then actually install them on another server. It's really not that unusual, particularly in the servers-as-cattle approach (if you script how to set up a server and delete or spin up servers whenever you need them), for the creation of a certificate to be completely separate and in a different place than where it ends up getting used. One "just" needs to be careful and protective about how one stores and distributes the private keys, of course.

2 Likes

I concur with @petercooperjr's assessment. If it were naughty to acquire certificates on one server then use them on another, every traditional CA requiring submission of a CSR via a website to acquire a certificate would have a 100% naughtiness rating.

1 Like

Not quite the same level of naughtiness, as traditional CAs still don't have access to the private key, and we're discussing here the possibility of sometimes transferring the private key too. Some people certainly would consider ever moving a private key from the system it's created on as an act worthy of being put on the "naughty list", though. I personally think as long as one is paying attention and using secure means of transferring the key (sftp or the like) it's fine. But my threat model isn't necessarily the same as your threat model.

2 Likes

Paranoia is a security requirement.

:nerd_face:

2 Likes

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