Pkiview Unable To Download Cdp
Fusberta Loparo
Things are mostly fine, but the OCSP location has the status "Error" in the pkiview console. When I check a certificate with certutil (certutil -URL test-certificate.cer or certutil -urlfetch -verify test-certificate.cer) it shows up as verified. So the responder does seem to work.
This worked fine for clients in in the past, and still does. But seems to cause the error in pkiview. In the past, the ocsp location was not added to endpoint certificates. It was just used for one application that had the urls in it's config file. So it did not show up in pkiview.
I'm implementing a new PKI environment and after running pkiview.msc to
check the health of the pki, I noticed a syntax error on a subCA in one of
the ldap paths for the AIA resulting in the "unable to Download" error.Since then, I've gone to the SubCA and modified the AIA path as well as
adding a second location to the extension. Howerver, pkiview still shows the
error and lists the old path, not to mention not picking up the additional
location.I've verified that the extention location changes were updated in the
SubCA's registry. I've also restarted Certificate Services as well as going
so far as to reboot the SubCA Server but pkiview STILL shows the old paths.Exactly how is pkiview getting it's information and how to I get it to
obtain the newly corrected locations?Also, since I've made the changes I published a test certificate from this
SubCA and enrolled it from my desktop, everything in the cert checks out, the
chain is good and the AIA and CDP paths reflect the corrected paths I
changed. So if this is the case, why is pkiview still squawking that it's
broken?
Should I Revoke the current CA Exchange certificate first?
I've tried adding the CAExchange template to the subCA, then enrolling it
via web enrollment from itself, but it didn't correct the issue, and the
newly issued CAExchange certificate is different than the original one listed
in "Issued Certificates". The original shows that it was requested by the
SubCA as servername$ whereas the newly issued cert shows as being requested
by my Enterprise Admin account. pkiview is still not showing the corrected
paths for the AIA.Did I do something wrong?
Thanks again Brian!Mentioning where pkiview looks for these paths might be something worth
adding to your latest revision of the W2K3 PKI and Certificate Security book.
I happen to have a copy of that book and prior to posting this question here,
I looked to it for an answer to this. I also found multiple people out on
the web (through Google searches) who also posed the same question in other
forums but nobody could give them a good straight answer.
I did a "renew Cert" on one of my Enterprise subCAs, and it's totally messed up my results on Enterprise PKI in MMC. In the Certificate Authority snapin, there are now two certs (Certificate #0 and #1). The AIA (ldap) is showing "Unable to Download", with the "original CN=". The CDP (ldap) location has a (1) on it, as does the DeltaCRL. Every time I renew the revocation, it makes both the original cert's crl and a (1). The CDP/DeltaCRL (http) also both show "unable to download", even though the files exist in the directory. The only AIA location that shows OK is the http location.
The event as above does not necessarily means that the MSCEP RA certs are expired or not present (deleted), but can also be because of Expired CRL or NDES server unable to retrieve the CRL, though the events as above do not specifically state such.
Hi Martin!
The Enterprise CA certificate is added to the NtAuthCertificates container in AD during CA install. Domain Controllers then look in that AD container during smart card logon verification. But that certificate is not propagated to the NtAuthCertificates container locally on clients/servers. That certificate will however be propagated to the Intermediate Certification Authorities container on clients.
To view/edit the NtAuthCertificates container in AD, start pkiview.msc, right-click Enterprise PKI, choose Manage AD Containers and select the tab NTAuthCertificates.
Hope that helped!
If you are absolutley sure that there are no more certificates stored in the object called NTAuthCertificates, you could delete it, but if you do not see any certificates by running pkiview.msc, right-clicking Enterprise PKI, choosing Manage AD Containers and select the tab NTAuthCertificates, there is no need to delete the object.
I have recently moved a Windows 2008 R2 CA to a new Server 2019 OS with a new host name. The move went well with one major issue. I am unable to create a SHA-2 CA cert and on SHA-1. This is causing all of our internal sites and other issued certs to issue Weak Cipher warnings and other issues.
Event ID: 48
Level: Warning
Revocation status for a certificate in the chain for CA certificate 0 for My CA0 could not be verified because a server is currently unavailable. The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).
Event ID: 100
Level: Error
Active Directory Certificate Services did not start: Could not load or verify the current CA certificate. My CA The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).
Revocation status for a certificate in the chain for CA certificate 0 for My CA could not be verified because a server is currently unavailable. The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).
In the Certificate Authority snap-in under Failed Requests I see the request 25 with the following:
The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).
This indicates that the Gateway was unable to establish trust with a remote system. This could be because the Gateway does not trust the issued certificate implicitly or it does not trust the issuer of a certificate. To resolve this issue:
This indicates that the API Gateway was unable to match the CN value of the certificate presented by the remote system to the host name of the remote system being contacted. If the CN value of the certificate being presented does not match the hostname of the system being contacted, this error will occur. To resolve this:
This indicates that the API Gateway is trying to make an outbound SSL connection to a remote system and the API Gateway was unable to find an agreed upon an SSL/TLS version to use for the connection. Most typically, this occurs when the API Gateway is trying to connect to a remote system that is requiring SSLv3. SSLv3 support has been disabled on the API Gateway and special steps must be taken to utilize SSLv3. You can re-enable SSLv3 in the Route via HTTP(S) assertion under the "Security Tab." If you require instructions for enabling SSLv3 globally, please contact Support for more information.
Most likely causes:
The worker process is unable to read the applicationhost.config or web.config file.
There is malformed XML in the applicationhost.config or web.config file.
The server cannot access the applicationhost.config or web.config file because of incorrect NTFS permissions.
Hello there. Thank you for developing this useful tool! I ran it to try to figure out why my Windows 10 clients are unable to connect to my Windows Essentials 2012 R2 server. On the server, the tool reports the following error:
Yes and can be accessed both internally and externally as a remote app (I have third party FQDN SSL Certs on both Mail and Remote). Exchange Redirect in the Dashboard setup fine and is confirmed working. DNS and DHCP check out. DeltaCRL, AIA, CDP and CRT check out fine from pkiview.
This document provides instructions for generating a Certificate Signing Request (CSR) on Microsoft Windows using the MMC console. If you are unable to follow these steps, DigiCert recommends that you contact Microsoft Support.
760c119bf3