15 เมษายน 2555 15:33
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 errors
- there 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' /:
-o((: nExoR :))o-
- ย้ายโดย Bruce-LiuModerator 16 เมษายน 2555 1:32 (From:Directory Services)
15 เมษายน 2555 19:25
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
- แก้ไขโดย Mr XMVP 15 เมษายน 2555 19:26
15 เมษายน 2555 20:00
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
- 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 that
- not 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-
16 เมษายน 2555 6:55
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.
- ทำเครื่องหมายเป็นคำตอบโดย Bruce-LiuModerator 17 เมษายน 2555 6:34
16 เมษายน 2555 10:30
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...
-o((: nExoR :))o-
16 เมษายน 2555 10:48
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:
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.
16 เมษายน 2555 11:53
-o((: nExoR :))o-