Hi, I'm testing, what I think is a simple process: converting a self-signed, Windows 2003 SP2 Enterprise CA to a Subordinate Issuang CA under a Windows 2008 R2 Policy CA. The process seems simple enough: 1) Create a testca.inf file with the following parameters to generate a CSR from the existing CA: [NewRequest] KeyContainer=TESTCA KeyLength=2048 KeySpec=2 KeyUsage=0x86 MachineKeySet=TRUE ProviderType=1 RequestType=PKCS10 Subject="CN=TESTCA,DC=strongauth,DC=com" UseExistingKeySet=TRUE [RequestAttributes] CertificateTemplate=SubCA 2) Generate a CSR using "certreq -new testca.inf testca.csr" 3) Take the CSR to the PolicyCA and issue a SubCA certificate 4) Accept the certificate with "certreq -accept testca.crt" Unfortunately, even though the commands execute without error messages, even after restarting the "legacy" CA, the new certificate does not replace the existing self-sigend certificate. Any ideas why? Thanks. P.S. In order to get to this stage without errors, had to do many things on the W2K3 machine: a) Install the SHA256 hotfix (http://support.microsoft.com/default.aspx/kb/968730?p=1); b) Import the new self-signed Root CA with "certutil -addstore -f Root rootca.crt"; and c) Import the new PolicyCA with "certutil -addstore -f CA policyca.crt". The new chained certificate shows up in the legacy CA's database, when viewed with "certutil -store"; however, it does not replace the old, self-signed certificate. I feel I'm missing a critical undocumented step; would appreciate some suggestions on next steps. Thanks.

You can't simply convert an Enterprise Root CA to an Enterprise Subordinate CA by creating and submitting a certificate request manually by using certreq. You'll need to remove Certificate Services from the computer and then reinstall it as an Enterprise Subordinate CA. Paul Adare CTO IdentIT Inc. ILM MVP

Hi Paul, Good to be talking to you again after a long time. I'd like to understand why it is not possible to convert an Enterprise Root CA to an Enterprise SubCA? The cert-chaining issues are contained within the certs themselves, so there's nothing within the certs that designate them as Enterprise Root or SubCAs. To the best of my understanding, its only AD, the local cert-store and the registry settings that indicate if a CA is a Root CA or otherwise. All these locations were populated with the new chain; all the old templates will eventually be removed from AD and substituted with templates from new Issuing CAs. The registry settings pertain to publishing URLs, validity periods, CPS, etc. So, I'm not clear what "hooks" exist in an Enterprise Root CA that force its uninstallation and re-installation to convert it to a SubCA. Thanks.

Have you looked at the definition of a root CA certificate. You are incorret when you say there is nothing in the certificate that defines them as a root CA. A Root CA is self signed. You cannot convert a self-signed certificate to a Other CA signed certificate without reinstalling Brian

Hi Brian, Yes, I am familiar with the definition of a Root CA. I believe if you look closely at what I said, you'll notice I said "there's nothing within the certs that designate them as Enterprise Root or SubCAs". Converting a self-signed CA to a SubCA (with most other PKI software I've worked with over the years) is as simple as generating a CSR with the keys of the self-signed CA and getting a certificate from another CA. Replacing the self-signed certificate with the newly-issued certificate automatically changes the hierarchy - none of the keys change, none of the certs issued by the old self-signed CA change - just the certificate-chain. There may be policy-related issues to address, but from a mechanical point-of-view, it is as simple as I described. What I'm trying to understand is why Windows 2003 CA requires an uninstallation when certreq is supposed to do what I want it to do - generate a CSR from an existing key-set (which it does) and accept a certificate for an existing key-set (which it does) - but it does not replace the existing certificate in the store-entry for that key-set . Either this is a bug, or there are "hooks" in the CA installation/uninstallation process that are not addressed in the certreq tasks when it comes to the certificate of the CA - and I'm trying to understand what those "hooks" are. Thanks.

Arshad, I think that your statement regarding suggesting "There's nothing in the certificates that designate them as Enterprise Roots...." is perhaps where you're getting a little confused. You're right in one sense, there isn't an extension along the lines of: "Type: Enterprise Root", but by virtue of the fact that the subject name and issuer are one and the same, ergo, you have a root CA. I can't imagine what software it is you have previously used which would allow you to change a CA from a root to a sub-CA. Even though you could manufacture a new sub-CA certificate using an existing (from your old root CA) key pair, it will indeed be a new CA certificate so it won't be possible to build a valid certificate chain from the previously issued leaf certificates as the AKI will fail (amongst other things). Dave

I appreciate your trying to explain this to me, Dave, but I assure you, I'm not confused about what makes a CA a Root or a Subordinate CA. I will accept Paul's assertion that the only way to convert a Microsoft Enterprise Root CA to an Enterprise SubCA is to uninstall it and install it as a SubCA - it does work as he stated (and if you're doing all the right things, you can preserve everything from that instance except the self-signed certificate). But I still hold by my own assertion that certreq -accept does not work as stated. The certreq documentation states as follows: The -accept parameter of certreq.exe links the previously generated private key with the issued certificate... If the CSR was generated with an existing private-key, certreq should have associated the new certificate with the existing key, and by implication, replaced the older certificate. This does not occur and appears to fail silently. That the older self-signed certificate will be replaced by a new SubCA certificate (issued by some other CA) is the desired outcome and not meant to be an unintended consequence. But, I will accept Paul's response as an answer and carry on. Its not the most elegant way of solving this problem, but it works. Thanks. Arshad P.S. BTW, when you take a self-signed Root CA certificate (which has an identical SKI and AKI) and replace the certificate with another that makes the Root CA into a SubCA (but using the same keys), the SKI does not change in the new SubCA certificate - only the AKI does (which is the SKI of the new Issuing CA). However, since the old, self-signed Root CA's keys did not change, the AKI in all certificates it issued does not change. Thus, all leaf certificates issued by the old Root CA continue to validate as long as they can see the new SubCA certificate and the SubCA's issuer's certificate in the chain (assuming the SubCA's issuer has a self-signed certificate). This works with MSCA and ADCS too (as it should since this is basic PKIX and nothing specific to any vendor's implementation).

Arshad, Thanks for the PS - glad to have learned that one. I now realise that I'm dumber today than I thought yesterday! Regards, Dave

I would actually say you are smarter than you give yourself credit for, Dave - and it has nothing to do with the discussion on PKI. Thanks for your input to the discussion.