Solved

Move Win 2003 Enterprise CA - different server name

Posted on 2008-10-28
4
1,667 Views
Last Modified: 2013-12-04
Hi Experts,

I have a few questions regarding the following scenario:

I have a enterprise CA running on a Windows 2003 DC that needs to be replaced. I have about 100 smartcard logon certificates issued by that CA (used for Token auth)  and a few other certs (webservers and such).

My questions are:

- If I move that CA to a new server hardware with same OS and identical server name, do the certificates continue to work or will I have to re-issue?

- I already have installed the replacement server with a different server name as a DC. Forest and domain level are Windows 2003. Will I be able to rename that DC and restore the CA successfully?

- I have found an article (http://windowsitpro.com/article/articleid/97565/moving-a-certificate-authority-ca-to-another-dc.html) that states that I can use a different server name when I change the CAServername setting before I import the reg key on the new server. Does anyone have experience with this? I assume if this really works the certs will become invalid, correct?

If anyone has some useful information and maybe some tips and tricks I would really appreciate.

Thanks in advance
Daniel
0
Comment
Question by:The_Kirschi
  • 2
  • 2
4 Comments
 
LVL 31

Expert Comment

by:Paranormastic
ID: 22822640

1) IF the servername is the same (OS & hardware doesn't matter as much), then you can export the existing CA cert with private key, the CA database, etc. and move it to the new CA.  If this is the case, existing certs should not be affected.  If you must rename the CA, you must issue a new CA cert, in which case your existing certs will need to be reissued.  If you were decommissioning a CA, you could publish a longer CRL for the end and not expire the existing CA cert from the root (assuming 2-tier infrastructure) and they would be valid until expiration.

2) I highly recommend against installing your CA on a DC.  You could rename it, but to do so you would have to demote the DC, rename it, then promote it again, then install the CA.  Better to just use a member server for the issuing CA and an offline non-domain server for the root.

3) Correct.  This would mainly allow you to decrypt the previous database and start issuing using the same keyset using a new CA cert.

4) How to move a CA to another server:
http://support.microsoft.com/kb/298138
Again, if you do not have a seperate root, this would be a good time to get things set up correctly.  Do not join the root to the domain and keep it offline and physically secured.  You would have to move CRL's manually or set up a private LAN to the 2nd NIC of the issuing subordinate CA to move the root CRL via sheduled batch script.  It is really best to keep the CA off of the DC so that naming systems are not affected and so that you can run the same CA box in its own timeframe than the DC.  There are many reasons to not install on the DC, these are just a couple of them.
0
 
LVL 16

Author Comment

by:The_Kirschi
ID: 22937956
Sorry for not getting back to you earlier but I had some more urgent issues. Thanks for your answers and explanations anyway.

Ok, so you say I should not install the CA on a DC. I understand this but what about the root? What do you mean by an offline non-domain server? Do mean a server that is not a DC or a server that is also not a member of the domain? What sense does the latter make? And what is offline? Are you saying I should have two CA servers actually? One that is the root, that will not do anything and one that is issuing the certs? But they have to be connected as root and subordinate CA, don't they? How will this be accomplished if one is a non-domain server?

I would highly appreciate if you could clear things up a little bit and also provide some information on how you come to these recommendations.

Thanks a lot!
0
 
LVL 31

Accepted Solution

by:
Paranormastic earned 500 total points
ID: 22986502
Don't install any CA on a DC - root, subordinate, or otherwise.
By offline non-domain server I mean just that - a server that is not connected to the domain that is not live on the network.  You can connect it to the live issuing CA over a private LAN with a hub/small switch but do not route to it.  Doing the private lan would make it easier to move the CRL over via script, reducing that overhead - this shouldn't happen very often so it is easy to forget to do.

There are a number of reasons for doing this, some of which include:
1) The ability to revoke your issuing CA without removing the root CA certificate.  This is handy when you want to remove a CA from service either because it is time or because it was compromised.  Usually your root certificate should be available for a very long time with a strong key strength.

2) Expandability - if you ever need to increase your PKI by adding another CA, you don't need to deploy another root certificate to all of your servers and workstations.  This could include a new domain name, launching a newer upgraded CA prior to decommissioning the old CA, or setting up a CA to be used with business partners and/or customers, for examples.

3) Keeping it offline protects the root CA - if your issuing sub CA gets cracked you can revoke it without affecting your infratstructure as a whole.  If it is offline, your root is not likely to get hacked unless they have physical access to it.

4) Since it is offline, your domain accounts would expire unless you bring it back online every month or so to keep the accounts fresh.  Since it would not be joined to the domain, you can use local accounts that will not expire if kept off the wire.

5) Keeping it offline also protects the root from other admins that could possibly compromise it, if that is a concern (I know it usually isn't, but it is for a few of us).


To actually do this, you can do things in two different ways:
1) For a higher security environment:
Keep the root completely offline - period.  If you are looking for this level of security, you might consider looking at an HSM to store the private key for both of your CA servers.  They are a bit spendy, but technically the best way to protect your CA since the private key is stored off the server, so even if the box gets hacked they would not be able to get to the private key.
After creating the sub CA's CA certificate request, copy it to a dedicated thumb drive and use that to transfer the CSR (Certificate Signing Request) file over to the root, sign it there and copy the signed certificate back and the root CA's certificate to the USB drive and move it back to the subordinate to install.  Do the same with the root CA's CRL as needed.

2a) For normal environments:
Create a private LAN using a small hub or switch (e.g. Linksys, NetGear, etc.).  Do not route to the root CA from the sub CA.  The Sub CA would have 2 NICs - one connected to the corp LAN and the other to the private CA LAN.  You can increase the security here by powering down the root CA when not needed or unplugging the LAN cable, but could be left connected if needed to facilitate scripting of the CRL issuance.  I would recommend powering it off or disconnecting it and just setting a calendar reminder to yourself and another admin to publish manually (certutil -crl) a few days or weeks prior to the CRL expiring.
2b) Similar to 2a, except using a Virtual Machine (VM) - store the snapshot on a USB drive and run it from there.  This makes transferring things pretty easy, the private LAN would be the VM private LAN, and so forth.  Since it is on a USB drive, you can take it out, put it in a static bag, and lock it up in a safe to keep it secured.  Copying to a 2nd drive makes for an easy disaster recovery plan.  You can do this for both of your CA's and save a bit on the hardware costs - CA's don't take much for hardware to run in most environments - our busiest CA issues over 200,000 machine certs renewing every quarter and does fine off a P3.  If doing VM, just take the normal planning step for getting enough memory in the physical box - that's a VM thing, everything else is a non-issue for a CA.

Hopefully this clears things up a bit.  If not, please ask.
0
 
LVL 16

Author Closing Comment

by:The_Kirschi
ID: 31510671
Thanks a lot. That was very precise and useful. Guess I will do the VM thing.
0

Featured Post

What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

Join & Write a Comment

Suggested Solutions

SHARE your personal details only on a NEED to basis. Take CHARGE and SECURE your IDENTITY. How do I then PROTECT myself and stay in charge of my own Personal details (and) - MY own WAY...
In a recent article here at Experts Exchange (http://www.experts-exchange.com/articles/18880/PaperPort-14-in-Windows-10-A-First-Look.html), I discussed my nine-month sandbox testing of the Windows 10 Technical Preview, specifically with respect to r…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…
This video explains how to create simple products associated to Magento configurable product and offers fast way of their generation with Store Manager for Magento tool.

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now