I have a three tier CA architecture (offline root, offline policy and enterprise ca) all running Windows Server 2008 Enterprise. I have many XP and Server 2003 devices to support so I could not use CNG. Let me restate - the first build, I did use CNG. Win7 and 2K8 worked great; 2K3 and XP didn't work at all. I removed the CA and implemented a second one without CNG. I did a simple implementation - the only items specified in the CAPolicy.inf are CRL times and certificate validity terms. I did not specify any special issuance policies, EKU's etc. I followed the implementation path as descibed by Brian Komar in his book and everything seemed to be OK, until I got a cert from the Enterprise CA. The certs being issued have a warning on the general tab stating that all the intended purposes of the cert could not be verified. The chain is good, the details look good, but this warning remains. Upon investigation, I think I found the cause of the issue. The Root CA has this in the EKU Field: Unknown Key Usage (2.5.29.32.0). The wierd thing is that 2.5.29.32.0 should be known - it is the OID for the "All Issuance" policy, at least in Server 2003. The issued certificates work for 802.1x Wired network access for XP and Win7 and for SSL in IIS6. IIS7 and OCS2007 running on Server2008 can't use the certificates. My company doesn't have a lot of plans outside of 802.1x for the certificates, but I feel that I'd be painting myself into a corner by moving forward with no certificate support for IIS7. I also don't know if the certs would work if we roll out external connectivity for our OCS. Does anyone have a fix for this? If I have to rebuild the CA architecture, does anyone have any idea where I went wrong and why OID 2.5.29.32.0 isn't recognized? Thanks in advance.

This OID is usually relaing to a [Policy] not an EKU. Curious that it ended up there - the client is reporting it correctly as unknown since it doesn't belong there. For an example of proper usage, search the OID number on this page: http://technet.microsoft.com/en-us/library/cc728279%28WS.10%29.aspx I'm wondering that since it isn't specified within the capolicy.inf file that it may be in the registry somehow? You might try searching around here: HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\CAName If you see something like a key with that OID's # then you might try exporting it and then removing it and renewing your CA cert again. The below is untested, but I think it is worth giving a try to see if you can remove it via the capolicy.inf file if you can't find it in the registry. Try adding this and then renewing your ca cert. Defining "empty=true" is used for the CDP & AIA sections when setting up the root CA normally, I'm not sure if they work elsewhere in the .inf or not. Please post results back as I am curious myself. [EnhancedKeyUsageExtension] empty=true As a side note: If you haven't updated to the latest service pack for your older clients, you might try doing that to make use of CNG or if necessary you could apply the appropriate hotfixes if you can't do the full SP.

Thanks for the reply, Steve. I followed your instructions regarding changing the CAPolicy.inf file on my Root CA. After re-issue, the certificate does not have that error. I think I need to renew the certs down the chain on my Policy CA and Issuing CA because new certs still reference the older CA cert. I am going to renew all certs and I'll let you know how it goes.

I reissued all CA certs in the chain and everything is fixed. Thanks a lot Steve for your help. I have had to rebuild my PKI once and I am extremely relieved that I don't have to rebuild it again.