Quick Check on ADCS Health Using Enterprise PKI Tool (PKIVIEW)

PKIVIEW was first introduced in Windows Server 2003 Resource kit. The tool is installed by default when you install the Windows 2008 Active Directory Certificate Services Role, and had been re-branded as “Enterprise PKI”. The tool is implemented as a snap-in for the Microsoft Management Console.

Enterprise PKI gathers information through Active Directory about the CA certificates and certificate revocation lists (CRLs) from each CA in the enterprise. Then it validates the certificates and CRLs to ensure that they are working correctly. If they are not working correctly or if they are about to fail, it provides a detailed warning or some error information.

Enterprise PKI displays the status of Windows Server 2003, 2008 and 2008 R2 certification authorities that are registered in an Active Directory forest. You can use Enterprise PKI to discover all PKI components, including subordinate and root CAs that are associated with an enterprise CA. The tool can also manage important PKI containers, such as root CA trust and NTAuth stores, that are also contained in the configuration partition of an Active Directory forest.

Enterprise PKI is very useful when verifying the installation of an ADCS environment, or when a quick check is needed for the health of the distribution points and managed containers in Active Directory.

Launching Enterprise PKI

 At a server running Windows 2008 or 2008 R2 ADCS service, launch Server Manager, expand Roles, Expand Active Directory Certificate Services and then click Enterprise PKI


The same console can be displayed, by running PKIVIEW.msc from the Search or Run menus

Enterprise PKI can also be launched from a Windows Server 2008, Windows Server 2008 R2, Windows Vista or Windows 7 computer by installing the Remote Server Administration ToolsActive Directory Certificate Services Tools from the Features set.

Enterprise PKI in Windows 2008 ADCS determines the AIA and CRL locations of the offline CA by examining certificates issued by the offline CA. The AIA and CDP distribution points for the online CAs are gathered by contacting the online CAs directly.  This is different than the PKIVIEW tool behavior in Windows 2003 PKI, which relied on a CA Exchange certificate with a validity period of  1 week to gather the CDP and AIA distribution points of an issuing CA.





Running Enterprise PKI in Windows 2008 will still create the CA Exchange certificate, although as stated before, it is not used by the tool.

Understanding Distribution Points Health in Enterprise PKI


Enterprise PKI evaluates every URL included in the AIA and CDP extensions of the certificates in the CA hierarchy. The tool attempts to connect to each referenced URL and reports whether the certificate or CRL is reachable as well as whether the current version is reaching expiration.

Some of the most common mistakes encountered in PKI deployments are missing certificates or CRL files. When launching Enterprise PKI all the certification authorities in the hierarchy should be examined in the left hand pane.







The Right hand pane will include the CA’s certificate and the status of its publication points. Consider the following scenarios:

  • If a publication point is configured correctly, the status column will report a value of OK.
  • If the publication point is configured incorrectly or if the CA certificate or CRL is not copied correctly to the publication point, the status column reports a status of Unable to Download.


To troubleshoot Unable to Download publication points, right click the publication point and click Copy URL. Paste the URL in a browser to verify if it can’t be downloaded. A 404 “File not found” error in a browser indicated the file can’t be downloaded, or the file is missing


In general, this error can be attributed either to:

  1. A missing file (in my case above, it was the certificate file of the issuing CA). Copy the file to the distribution point and refresh Enterprise PKI.
  2. The HTTP URL is accessible through a Proxy. You should consider removing the proxy requirment for the computer security context
  3. There may be an access control list (ACL) blocking access to the file
  4. When dealing with Delta CRLs, the web site might block the download of the file due to double escaping. This issue can easily be solved by following the steps in How to avoid Delta CRL download errors on Windows Server 2008 with IIS7


  • Finally, if the CA certificate or CRL is near expiration, the status column will report a value of Expiring



There are several ways to troubleshoot this issue:

  1. Renew the CA’s certificate if it is about to expire and publish it to the AIA distribution points
  2. CDP is about to expire, examine which CDP in the chain is about to expire, issue a new CRL and publish it to the distribution points
  3. This might also be a superficial message, when you know your issuing CA’s CDP publication frequency is about to issue a new CRL, however the display in Enterprise PKI is showing it as Expiring. Adjust the Options in Enterprise PKI as follows:



  • The expiring certificate indicator: You can specify how many days before expiration of a certificate that the PKI Health Tool will indicate that a certificate is expiring. Consider using a much larger number than the default of 14 days. In fact, if you plan to issue certificates with a one-year validity period, you should use a notification of 365 days
  • The base CRL expiration indicator: The base CRL indicator should be set to a value that reflects the base CRL publication interval of your issuing CA. If you publish the base CRL at a weekly interval, consider keeping the default expiration interval of two days. If you publish the base CRL on a daily interval, consider a value of eight hours
  • The delta CRL expiration indicator Like the base CRL setting, you must choose a delta CRL interval that reflects your delta CRL publication. If you publish a delta CRL every day, the default of every four hours may be the right value for you. If you publish the delta CRL every eight hours, consider a value of two hours for expiration notification.

Examining and Understanding Active Directory Certificate Stores


Enterprise PKI can examine each of the Active Directory certificate and CRL stores by using the Manage AD Containers  dialog box by right clicking Enterprise PKI, and then clicking Manage AD Containers. All the containers are stored in the configuration partition of the Active Directory Forest where the CA hierarchy is installed. 


Certification Authorities Container:

Contains all the Root Certification Authorities in the Active Directory Forest. This container is accessed through the autoenrollment policies for users and computers and distributes the Root CAs to the local Trusted Root Certification Authorities store.  

The Certification Authorities container is stored in CN=Certification Authorities, CN=Public Key Services, Configuration, CN=Services, DC=ForestRootdomain. The container can be accessed using any LDAP capable tool, such as ADSIEDIT, LDP.EXE, etc….

Enterprise PKI tool allows viewing or removing Trusted Root Certification Authorities to this container, but will not allow adding new Root Certification Authorities. Use Certutil -f -dspublish RootCA.cer RootCA command to add a new Root Certification Authority to this container,




Enrollment Services Container:

Contains all enterprise issuing certification authorities in an Active Directory Forest. The container is CN=Enrollment Services, CN=Public Key Services, Configuration, CN=Services, DC=ForestRootdomain. The container can be accessed using any LDAP capable tool, such as ADSIEDIT, LDP.EXE, etc….


Enterprise PKI tool allows viewing or removing Trusted Root Certification Authorities to this container, but will not allow adding new or existing enterprise certification authorities. The only method to add a new enterprise certification authority to the Enrollment Services Container is by using the Active Directory Certificate Services Role in Server Manager


The NT Authority certificate object contains all entries for all CAs that can issue certificates used for smart card authentication and for Remote Authentication Dial-In User Service (RADIUS) authentication. The NTAuthCertificates object is stored in CN=NTAuthCertificates,CN=Public Key Services, Configuration, CN=Services, DC=ForestRootdomain. it can be accessed using any LDAP capable tool, such as ADSIEDIT, LDP.EXE.

Enterprise PKI tool allows adding, removing and viewing NTAuth certificates; in addition Certutil can be used to publish an NTAuth certificate if needed.


AIA Container:

Contains all CA certificates for all CAs in the CA hierarchy. The container is stored in CN=AIA, CN=Public Key Services,CN=Configuration, CN=Services, DC=ForestRootdomain. It can be accessed using any LDAP capable tool, such as ADSIEDIT, LDP.EXE.


Enterprise PKI tool allows viewing and removing certificate files from the AIA container, but will not allow adding new entries of new or existing certificates to the AIA container. A new entry can be added to the container using the Certutil -f -dspublish CertificateFile.cer NetBiosNameofCAServer.

CDP Container

Contains all base and delta CRLs for each CA in the CA hierarchy that publishes revocation information to Active Directory. This value is configured in the extensions tab of the LDAP extension.

For each CA publishing revocation information into Active Directory,  a separate container is created, containing the base and delta CRLs -if any for that CA. The container for each CA will have an object referencing the CA’s sanitized name of type cRLCistributionPoint. The actual container per CA is stored in CN=NetBiosNameofCA,CN=CDP, CN=Public Key Services,CN=Configuration, CN=Services, DC=ForestRootdomain.


Enterprise PKI tool allows viewing, removing and saving certificate revocation list files from the CA’s respective container, but will not allow adding new entries of new or existing CRLs. An entry can be added to the container using Certutil -f -dspublish CertificateFile.crl NetBiosNameofCAServer or by issuing a new revocation list at the enterprise  CA.

KRA Container:

Contains all Key Recovery Agent (KRA) certificates published to Active Directory Domain Services (AD DS) that are available for key archival operations on enterprise CAs. The actual container is CN=KRA, CN=Public Key Services,CN=Configuration, CN=Services, DC=ForestRootdomain. Each enterprise certification authority will have an entry of type ms-PKI-Private-Key-Recovery-Agent. Enterprise PKI tool allows viewing and removing certificate files from the KRA container, but will not allow adding new entries for new or existing key recovery agents. A new entry can be added to the certificate attribute of the enterprise certification authority using the Recovery Agents tab in the CA properties


Enterprise PKI provides a view of the status of your network’s PKI environment. Having a view of multiple CAs and their current health states enables administrators to manage CA hierarchies and troubleshoot possible CA errors easily and effectively. Specifically, Enterprise PKI indicates the validity or accessibility of authority information access (AIA) locations and certificate revocation list (CRL) distribution points.


Amer Kamal

Senior Premier Field Engineer



Comments (10)

  1. Anonymous says:

    Noted and corrected

  2. PatMCT says:

    Hello !
    Sorry for my bad english (i am french)
    A question on publish crl in AD …
    I publish the crl of an offline ca root with : certutil -dspublish -f mycrlfile.crl srvcaroot (where srvcaroot is my netbios name of my server where is my caroot)
    All is fine, and i saw the publication in the node sevices in the mmc "sites and services" under the cdp container (i have well a srvcaroot container created and mt crl in)
    The probleme is that when i do a Gpupdate on a computer in the domain and see in the mmc certificate if the crl is coming down in the entreprise carevocation list folder nothing comes … the revocation folder is not created at all
    If i install … manualy the revocation list on the computer of the domain … the folder appears and the crl is in it
    What is the problem ?
    Help please

  3. Anonymous says:

    Good article.

  4. Will Fahim says:

    Thanks Amer, this blog helps a lot of my clients. 🙂

  5. Abdullah says:

    Thanks for the post, really was helpful.

  6. Thanks Amer, very informative.

  7. JCSunday says:

    For the certutil -dspublish command, you show an example ("Certutil -f -dspublish RootCA.cer Root")  to add a new Root Certification Authority to the Certification Authorities container.  That example ends with "Root", but when I use certutil -dspublish /?, the closest option I see is "RootCA", not "Root". Is that a typo? Will either work, or does each one do something different?

  8. JCSunday says:

    Please keep this page here! It covers the subject very well, and I send the link to anyone who asks about the Enterprise PKI snap-in.

  9. Health Around says:

    Health Around is a great web utility and mobile app to locate any health related place around you.


  10. Pavel says:

    It looks like, this PKIView tool reveals some kind of security hole.

    I have just one Enterprise CA. There are no enabled (published) templates yet in my CA (LoadDefaultTemplates=0). I set CA’s policy module to "The Administrator must explicitly issue the certificate".

    I ran this PKIview and boom – there is immediately issued certificate based on "CA Exchange" template. How is this possible? Without published "CA Exchange" template? With manual issuing?

    Also I’m unable to find this issued Cert. It is neither in User’s store nor in Computer’s store. Any hint where could be this issued cert stored?

    BTW: nice blog, but there are some mistakes:

    * You can’t add cert to AIA container by: Certutil -f -dspublish CertificateFile.cer NetBiosNameofCAServer

    * In several places "Configuration" is missing the "CN="

    * …"CN=Configuration, CN=Services"… should be swapped