Windows Certificate Authority move from 2003 to 2008

I'm migrating our older windows 2003 DCs to our new 2008.  i want to bring up a new CA on one of the new 2008 DCs, and noticed that 2 of the older ones are CAs.  I'm having trouble determining the type of CAs they are, Enterprise/Stand-alone/root, and if they are needed for anything.  I want to figure out if I need to migrate them or their specific roles, and if so how.  The CA will be used for Exchange 2007 certs and wireless PEAP clients.

Thanks
mbrombAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ParanormasticCryptographic EngineerCommented:
certutil -getreg ca\CAType

0 = Enterprise Root CA
1 = Enterprise Subordinate CA
3 = Standalone Root CA
4 = Standalone Subordinate CA
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ParanormasticCryptographic EngineerCommented:
If there are 2 CAs then look at each on the server by opening certsrv.msc (Certification Authority MMC), expand CAName - select Certificate Templates - this will tell you what templates are being used, you can usually tell by the name what they are for.  After checking that, then select Issued Certificates and see if there are a lot of certificates or not, if there are not too many then just look.  If there are a lot, try applying a filter to search after 1 year ago to get a better feel and sort by template name.  If there are still a lot, let me know and I can show you how to query by template.
0
mbrombAuthor Commented:
results:
CAType REG_DWORD = 3
  ENUM_STANDALONE_ROOTCA -- 3

So, it looks like they're both stand-alone roots.  I'm not sure why my predecessor would have done that rather than a Enterprise root and subordinate.  

There are a bunch of templates, but each only has a single issued cert to the computer's own account of template type CA Exchange .  They are both Effective date 3/31/10 - Expiration 4/7/10.  Are these their own renewed private keys for issuing certs?
0
INTRODUCING: WatchGuard's New MFA Solution

WatchGuard is proud to announce the launch of AuthPoint, a powerful, yet simple, Cloud-based MFA service designed to eliminate the vulnerabilities that put your data, systems, and users at risk.

ParanormasticCryptographic EngineerCommented:
>>Are these their own renewed private keys for issuing certs?
Pretty much.  CAExchange certs are used to encrypt the session for archiving private encryption keys.  They are internal to the CA issuance process, yes.

The old admin was probably trying to do something he didn't know how to do properly - maybe 2 different people or they forgot they did it once before.  Having a standalone root is a good thing if it is offline (which all roots should be, really), then have a 2nd CA that is online as an enterprise subordinate CA.
0
mbrombAuthor Commented:
Is it safe to say that these CAs are unused and can be removed?  I would then install an Ent. root CA on the 2008 DC?  We have a secure internal network, so I wouldn't be too concerned about it staying online, but I suppose I could keep the service down, and bring up a subordinate on another DC.  My impression is that the wireless PEAP clients will need access to a live CA.
0
ParanormasticCryptographic EngineerCommented:
If all that are issued are CA Exchange certs, and maybe domain controller certs yes its safe to decom without worrying about migrating and just start fresh again.

I advise against installing the CA on a DC - its just not a good idea even though it is so common to do so.  If you have another 2008 Enterprise server, you are probably better off with that.  DC & Exchange servers just should not be CA servers.  Also, preferably the root should be an offline standalone CA on standard edition OS with the issuing CA being an enterprise subordinate.

How to decom a CA server properly from AD:
http://support.microsoft.com/kb/889250
0
mbrombAuthor Commented:
I've upped the points

We don't have any 2008 Enterprise installations, including the DCs.  I was going to put the CA on a DC so that there is never an issue of it disappearing.  It's not a good idea because of the security issue of having it there, right?  it's not about anything else?  That's why I was asking if it would be acceptable to just disable the Certificate Services service to keep it "offline".  It may be possible to put it on another server that is used for other utilities and system admin stuff.  

Sorry, i'm a little confused, and i should do some more reading to get the bigger picture.  I was trying to expedite because I have enough reading/research to do at the moment.  Some further questions:

In lieu of doing what you suggest, "the root should be an offline standalone CA on standard edition OS with the issuing CA being an enterprise subordinate.", would this work, on 2008 Standard, install a single CA as a standalone root?  Or would an Enterprise Root be necessary since there would be only one CA?
The Enterprise Subordinate you suggest is so there is integration with AD and so the root is unavailable for security reasons?  Does the issueing CA need to be an Enterprise CA?

For a 2008 CA, it seems that i should avoid using the CNG CSPs, those with # in the name?  It seems that some PEAP clients have issues with it, and there maybe other issues.

I intend to bring up a new CA depending on the outcome of this thread, and then when decommissioning the CAs that are in place on the 2003 servers, just shut them down for a week to make sure there are no issues.  Then bring them up for decom.

thanks for the article!
0
ParanormasticCryptographic EngineerCommented:
Part of the reason is security, the other is that the CA doesn't like to be renamed - like if you need to run dcpromo to demote the DC for all the various reasons you need to do that.  You need to backup the CA and uninstall certificate services in order to run dcpromo.  Having the root offline helps with the security to a point, but it does not help the hassles of living on a DC.  Exchange server is another bad idea since there is already enough going on with an exchange server, you don't need the hassle of a CA to add during a restore, etc., plus exchange tends to live on the perimeter which is bad for security too.

Note that without Enterprise Edition OS, you will be missing out on autoenrollment & certificate tempaltes - these are usually a big selling point for an enterprise CA.

Properly done, the root should be completely offline - i.e. on a dedicated installation (typically standard server is fine for this) that is never ever connected to the network or joined to the domain.  You cannot revoke a root certificate because it is self-signed.  VM tends to come in handy here so you can keep it properly off the network and physically remove the external hard drive hosting the server snapshot and lock it up when not in use (to issue CRLs a couple times/year).

All an enterprise root CA should be good for is easing a little bit of configuration and issuing an enterprise subordinate CA cert.  If you cannot afford the license for an offline standalone root CA, then the next best thing would be to install an enterprise root CA and do not issue any templates to it at all.  Then on another server, create the enterprise subordinate CA.  Keep the certificate services for the root shut down normally and if you are able to afford a smartcard to keep the private key on then I would recommend doing that for a lot of extra protection for the root key. Smartcards are not going to keep up with an online CA, but for offline CAs they are a cheap way to get a lot of security for that root cert.  USB smart tokens are an easy way of doing this - you can implement that for under $100 for the smart token and software license with no smartcard reader to buy.  If you do this, during the CA install when you get to choose the CSP then point it to the smartcard's CSP.

PKI is a very simple concept - trust a root CA and inherit that trust for everything signed under the root CA, unless it is on the revocation list that was signed by the CA.  However, the implementation and best practices are very complex and most admins don't take the time to do more than 'get it up and running' for what is one of the most important pieces of security in your entire infrastructure.  It is the basis of all trust for everything in your network - you need to trust your CA to trust everything else represented by it.

I get a little wordy sometimes... go with the enterprise root kept shut down and an online enterprise subordinate.  do the smartcard thing if you can for the root - its really worth it.  Avoid CNG for probably another 3-5 years.  Its cool stuff, but you need everything to support it and there are still a lot of things that don't yet (like pre-Vista clients).
0
ParanormasticCryptographic EngineerCommented:
Yes, the 'enterprise' makes it so it is AD integrated during installation - you will need enterprise admin rights to install.  Stand-alone is usually used for offline CAs and also for CAs that are issuing certs only outside of the internal network.

If you need install guides, you can use these from my new site for guidelines to get started:
http://www.pki101.com/InstallRootCA_2008.html
http://www.pki101.com/InstallSubordinateCA_2008.html
0
mbrombAuthor Commented:
ok.  Good info!

For Exchange I'll need to produce SAN or UCC certs.  Can that be done with a Ent. Root CA on 2008 standard?  We have no 2008 Ent installations.
0
mbrombAuthor Commented:
An MS article: http://support.microsoft.com/kb/931351 
Indicates that a standalone can be used to issue Exchange 2007 SAN certs, and that templates are not necessary.

This excerpt I've seen in multiple articles.  It's not clear to me if the command does work on a template, or if it works on any CA.
----------------------
By default, a CA that is configured on a Windows Server 2003-based computer does not issue certificates that contain the SAN extension. If SAN entries are included in the certificate request, these entries are omitted from the issued certificate. To change this behavior, run the following commands at a command prompt on the server that runs the Certification Authority service. Press ENTER after each command.
 
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
----------------------
0
ParanormasticCryptographic EngineerCommented:
The command is run on any CA server to enable the SAN attribute.  It can work for any cert, however to use it on the certsrv page if memory serves you need Enterprise edition because this is only available with templates.  In the Attributes field, put in something like this:

SAN:dns="server1"&dns="server1.domain.com"&dns="192.168.0.1"&dns="autodiscover.domain.com"&dns="mail.domain.com"

For standard edition OS without templates, or for a standalone CA, you can still issue SAN certs, its just the process changes a little bit on the request end.  The easiest way is to create a request.inf file to use when creating the CSR file.

Create the CSR file:
certreq -new request.inf servername.txt

Then install the cert by right-click - install cert method and manually select the store -browse - select 'show physical stores' then place in Personal - Certificates.  Open the Certificates MMC snapin (local computer) then locate the cert in Personal - Certificates and open it up - see if on the General tab if the private key message is there at the bottom.  If not, then go to Details tab and copy the serial number, paste into notepad and take out the spaces and copy again and run this:
certutil -repairstore My %pasteserialnumber%
Refresh the MMC and you should now see the cert with the key there when opened.   Go to details tab and click the copy to file button and export including private key and save as a .pfx file.  You can then go into IIS or whatever and select to install from .pfx file (a.k.a PKCS #12 or p12) and point to that file.


The request.inf file should look like this:
[Version]
Signature="$Windows NT$"

[NewRequest]
Subject="C=US,S=YourState,L=YourCity,O=YourCompany,OU=YourOCS-OU,CN=Servername.domain.com"
PrivateKeyArchive=FALSE
Exportable=TRUE
UserProtected=FALSE
MachineKeySet=TRUE
ProviderName="Microsoft RSA SChannel Cryptographic Provider"
ProviderType=12
UseExistingKeySet=FALSE
RequestType=PKCS10
;HashAlgorithm=sha1RSA
KeyLength=2048
KeyUsage = 0xF0     ; Digital Signature, Key Encipherment, Nonrepudiation, Data Encipherment
KeySpec=1
SMIME=TRUE

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

[RequestAttributes]
SAN = "dns=Servername.domain.com&dns=mail.domain.com&dns=autodiscover.domain.com&dns=SERVERNAME&dns=192.168.0.1"
0
mbrombAuthor Commented:
OK. I've been able to get some more research in and figure things out.  It turns out that 2008 R2 Standard includes the V2 and V3 templates and autoenrollmentwith an Ent. CA.  So, i'll be going that route.  thanks for all the info.  it's been an education.

Matt
0
mbrombAuthor Commented:
Thanks for the education
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.