HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\TCA Root CAġ:C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crtĢ:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services, %6%11ġ:c:\Windows\System32\Certsrv\CertEnroll\%3%8%9.crlġ0:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10Ī good idea would be to review Vadims Podans excellent post on this. In your CA setup you would run something like this - note that " file:" is not used: Secondly, use a web server to make the CRLs highly available when they are copied from your CA servers after publishing the CRL. These are from the registry on the Issuing CA shown below. But it's cleaner to also reissue the previously issued certificates, and if you add another CDP (http for instance) or do any other mutations,įinally, looking at your CDP list, you may want to consider adding an http CDP and get it above the LDAP position, same as you have with the AIA.įirst, the location of the CRLs are listed in a certificate in the Details tab\CRL Distribution Points. In thisĬase the point is somewhat moot, as the file:// protocol is no longer supported and lookup will fail either way. This CDP is listed to be included in the CDP extension of issued certificates and this does not change for existing CAs when you change the extensions, which means these certificates will still have it in their attributes. Refresh the PKIView.msc, both locations will disappear. You will find that if you remove the entry altogether from the extensions and restart the CA service (which you will be prompted when clicking Apply), then The appearance of CDP Location #2, the checkbox Include in CRLs. The checkbox: Include in the CDP extension of issued certificates triggers The extensions screenshot is from your issuing CA, right? It's the bottom one, that you partly censored that corresponds with both the DeltaCRL Location #1 and the CDP Location #2.
0 kommentar(er)
