i have problem with configuring key archival in domain. all certifiacates works fine - i can enroll every certificate with no problem.Enterprise PKI shows no errorsthere is single offline rootCA on w2k8 R2 std and enterprise issuing CA on w2k8 R2 ent. i have created key recovery agent template, enrolled certificate for the user and added as KRA in certification authority now if i create a template and set 'archive subject's private key' and try to enroll i receive 'revocation function was unable to check for revocation for the certificate' /: PLEASE HELP!-o((: nExoR :))o-

Hello, Start by this Microsoft article about Troubleshooting Certificate Status and Revocation: http://technet.microsoft.com/en-us/library/cc700843.aspx#XSLTsection131121120120 More if you ask them here: http://social.technet.microsoft.com/Forums/en-US/winserversecurity/threads This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. Microsoft Student Partner 2010 / 2011 Microsoft Certified Professional Microsoft Certified Systems Administrator: Security Microsoft Certified Systems Engineer: Security Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration Microsoft Certified Technology Specialist: Windows Server 2008 Applications Infrastructure, Configuration Microsoft Certified Technology Specialist: Windows 7, Configuring Microsoft Certified Technology Specialist: Designing and Providing Volume Licensing Solutions to Large Organizations Microsoft Certified IT Professional: Enterprise Administrator Microsoft Certified IT Professional: Server Administrator Microsoft Certified Trainer

yeah.. i read this and several more. after making lab environment and heeeell a lot of tests i finally resoved the issue. still there are several mysteries. why it did not worked in very short the problem was that CDP and AIA on root ca were empty [only c:\windows... publication]. this was done according to some article on MS site stating that as this is offline, CDP and AIA should be empty. resolution was not easy one - needed to recreate all cert chain ): the effect was, that KRA certificate, although it was enrolled sucesfully, when checked with certutil -verify showed stated error. this was stopping enrolling EFS cert as the private key was to be encrypted with KRA cert mysteries why enterprise PKI did not show any errors? why all certificates worked fine and had no issues? isn't the cert path verified for all the certs? don't get thatnot direcly related but [CRLDistributionPoint] and [AuthorityInformationAccess] do not work. log file always shows win32 1 error. i found out that those fields requires attributes - may not be empty. in some book i found the solution to put 'empty=true' but it does not work either. that was tricky one...-o((: nExoR :))o-

answers: a) enterprise PKI didn't show any errors because it is quite correct for certificates to not have CDP (in your case, it was the IssuingCA that didn't have CDP in its certificate). If a certificate does not have CDP, it is in fact, that its CA (in your case the root CA) just says "this certificate cannot be CRL checked, so don't bother" - and enterprise PKI didn't bother correctly. b) the same case with other clients - not having CDP in a certificate is not an issue - it is only a matter of policy of your then CA that decided to not produce CRL lists c) why KRA requires full CDP chain? Because it is configured so. It is just metter of another policy that is more strict and the IssuingCA simply wants to see whether the KRA certfiicate is not revoked at most precise level possible. d) you do not need to configure the CRLDistributionPoint nor AuthorityInformationAccess for the rootCA. These fields set CDP into the RootCA's certificate itself and that neither required nor phylosophically possible. By default, any Windows 2003 CA and newer does not put CDP into root CA's certificate anyway. What you need to have is CDP in the IssuingCA's certificate. ondrej.

Ondjej - thx for the answers! still if can develop in more details c) ..."Because it is configured so.".. - is there a way to configure it not to check for CRL for KRA certs? i was looking for such an option in cert template in the first place but could not find anything like that. as for d) it does not work wherever i use capolicy.inf - installing on enterprise ca produced CDP and AIA as well. in all materials it is said that if you provide empty fields those extensions will be preconfigured after installation - i could not make it work. anyways it's quite a detail... thx-o((: nExoR :))o-

sorry, it is probably not "configured so", but rather "designed so" - I don't think it is possible to disable the CRL check. regarding the two [CRLDistributionPoint] and [AuthorityInformationAccess] settings look here: http://blogs.technet.com/b/askds/archive/2009/10/15/windows-server-2008-r2-capolicy-inf-syntax.aspx The two sections work only when you are installing RootCA, not any lower CAs. By default, the root CA does not have any CDP in its own certificate. That is good. RootCA should not have CDP in its own certificate. Although, RootCA should issue CDPs into certificates that it signs. You would use the two settings only if you needed to have the CDP in RootCA's own certificate, which I do not see any reason for. After you install RootCA or any other lower CA, you must go into its properties and define CDP paths. The CA will then put these into certificates that it will issue in the future. This setting cannot be configured by using the CAPOLICY.INF file. Wrap it up - the CAPOLICY setting applies to RootCA only and only for its own self-signed certificate, only at the time of its installation. Any other issued certificates will have the CDP according to what you configure in the GUI (or in registry by using CERTUTIL) of RootCA or any other lower IssuingCA. ondrej.

thx (: <solved>-o((: nExoR :))o-