none
Certificate Revocation checks, CDP and AIA failing from a different subnet RRS feed

  • Question

  • We're working with a new client in our university that is on a different forest/domain and subnet. signed certificates are required for SCCM to function in HTTPS native mode. I made a certificate manually (no auto-enroll) for a test client and installed the cert, its intermediate, and its root on the test. However, when I export the test cert and run certutil -urlfetch -verify c:\testcert.cer I get the following:

    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
      Issuer: CN=SSCC CA, DC=ads, DC=ssc, DC=wisc, DC=edu
      NotBefore: 9/5/2019 12:32 PM
      NotAfter: 9/4/2020 12:32 PM
      Subject: CN=uwsc-booth05.ad.wisc.edu
      Serial: 1900002d341b3feb94aeeba4a7000100002d34
      Template: 1.3.6.1.4.1.311.21.8.12361318.3005162.16010686.12214934.6180701.44.6377128.2640082
      Cert: 06659d1130c600fe09556fa4d2c38af184376611
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
      Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
      ----------------  Certificate AIA  ----------------
      Failed "AIA" Time: 0 (null)
        Error retrieving URL: More data is available. 0x800700ea (WIN32/HTTP: 234 ERROR_MORE_DATA)
        ldap:///CN=SSCC%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ads,DC=ssc,DC=wisc,DC=edu?cACertificate?base?objectClass=certificationAuthority
    
      ----------------  Certificate CDP  ----------------
      Failed "CDP" Time: 0 (null)
        Error retrieving URL: More data is available. 0x800700ea (WIN32/HTTP: 234 ERROR_MORE_DATA)
        ldap:///CN=SSCC%20CA,CN=SSCCSubCa,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ads,DC=ssc,DC=wisc,DC=edu?certificateRevocationList?base?objectClass=cRLDistributionPoint
    
      Expected Base CRL "Delta CRL (0834)" Time: 0 751bc00de7664b50caa2c685c9f762412d5b4c69
        [1.0] http://cert.ssc.wisc.edu/cdp/SSCC%20CA.crl
    
      ----------------  Certificate OCSP  ----------------
      Failed "OCSP" Time: 0 (null)
        Error retrieving URL: Method not allowed (405). 0x80190195 (-2145844843 HTTP_E_STATUS_BAD_METHOD)
        http://cert.ssc.wisc.edu/cdp/SSCC%20CA.crt

    Now, of course I understand while checking CRL and AIA over LDAP is failing. But we have both LDAP and HTTP via IIS set up and stamped into each certificate. The firewall to cert.ssc.wisc.edu is open to the world; anyone can download those crl and crt files.

    Here's a screenshot of the CDP extensions tab for the test client's certificate:

    I inherited this PKI infrastructure; I wish I knew more about it. Anyone have any ideas?

    • Edited by MD5Hash Friday, September 13, 2019 6:34 PM
    Thursday, September 12, 2019 3:02 PM

Answers

  • I've modified SSCC CA's CDP extension to now have both <CaName> and <DeltaCRLAllowed> in the path, and then I ran certutil -crl from an elevated prompt.

    Now, in pkiview, the "deltaCRL Location #2" and "CDP location #2" still both read the same HTTP path, but now it's the deltacrl that shows as "unable to download" and "cdp location #2" now shows as okay - progress, maybe?

    However, based on Daisy's post above, deltaCRL location #2 and cdp location #2 should have different paths, right? like, http://cert.ssc.wisc.edu/cdp/sscc%20ca+.crl or something? That new + file now exists on the IIS share, too

    How can I get that new + crl file to be offered and visible in pkiview?

    • Marked as answer by MD5Hash Monday, September 16, 2019 9:04 PM
    Monday, September 16, 2019 7:40 PM
  • I figured it out - I needed to also edit the http:// path, not just the c:\ path, to include <DeltaCRLAllowed> variable, and then republish "revoked certificates" from certsrv - now pkiview comes back as green, and the SSCC%20CA+.crl is now being distributed. With the trusted root certificate installed, certutil can now validate an entire multi-level certificate chain including AIA and CDP.
    • Marked as answer by MD5Hash Monday, September 16, 2019 9:04 PM
    Monday, September 16, 2019 9:04 PM

All replies

  • Same with AIA extensions tab; I have both [1] and [2] listed as options; I know that there's a 10-15 second waiting period where LDAP would be checked first for the .crt file, but then it should go to HTTP.

    Thursday, September 12, 2019 3:06 PM
  • This doesn't seem right - in pkiview, my DeltaCRL Location #2 and my CDP location #2 are set to the same thing. It doesn't seem like this system was set up using delta CRLs at all, or at least not with the proper SSCC%20CA+.crl extension they should be, right?

    Looks like the image is too small, but I can see it when I right click and "view image"
    • Edited by MD5Hash Thursday, September 12, 2019 7:59 PM image too small by default
    Thursday, September 12, 2019 7:58 PM
  • Hello,
    Thank you for posting in our TechNet forum.

    According to our screenshot (pkiview.msc), I view the pkiview.msc with two-tier CA in my AD test environment .

    My domain name is fabrikam.com.
    2019server is my Web server name.



    So we can try to check the CDP configuration on the sub-CA Properties.

    1. C:\Windows\system32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl



    2. ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

    3. http://pki.fabrikam.com/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

    4. \\2019server.fabrikam.com\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl



    Here is an article about setting up two tier CA step by step.
    AD CS Step by Step Guide: Two Tier PKI Hierarchy Deployment



    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, September 13, 2019 3:25 AM
    Moderator
  • Good afternoon Daisy - thank you for the reply. We do already have a 2-tier CA in place, but I have to work with my predecessor's implementation of it right now. The Root CA is offline, of course. The Subordinate CA is where I am posting my screenshots from.

    Right now, I'm just using http://cert.ssc.wisc.edu/cdp/<CaName>.crl - and also publishing to its file based location, c:\inetpub\certservices\cdp\<CaName>.crl too. I have the exact same check boxes as you on both, as you can see below.

    Now, I notice that whoever set up the CDP extension, didn't include <DeltaCRLAllowed> in the path. So, of course I can add that to both paths, but will this damage the hundreds of existing certificates that this CA has already authorized, or will these changes only apply to new certificates?

    And, do I need to anything else for the new certs that the CA creates to start adding the deltaCRL path to the certificates anywhere else, or will it just start happening automatically?

    Thank you for the advice!

    Friday, September 13, 2019 6:17 PM
  • I went into IIS on the subCA, and looked at "handler mappings" both at the root, and the /CDP shortcut too. There's no handler mapping for *.crl files - is that important? One seems to have been manually added (as its path type is "file" rather than "unspecified") for *.cer, which reads as name "SecurityCertificate"

    Could this be why PKI view is failing? Does anyone have instructions on adding the CRL mime type to IIS? I just don't know what "name" to set it as, and whether it would be "add managed handler" or "add module mapping", etc

    Couldn't find documentation specifically to add CRL as a mimetype to IIS, so this probably isn't the reason things are failing (I figure there would be more posts on the internet if this were required).

    Edit: nope, that didn't work. I set it to %windir%\system32\cryptui.dll and made *.crl on the root and that was giving me 500 errors when trying to download the crl file. Broke PKIView.msc even more (deltaCRL Location #2 also showed unable to download too) so I removed the handler mapping.
    • Edited by MD5Hash Friday, September 13, 2019 8:31 PM
    Friday, September 13, 2019 8:21 PM
  • I've modified SSCC CA's CDP extension to now have both <CaName> and <DeltaCRLAllowed> in the path, and then I ran certutil -crl from an elevated prompt.

    Now, in pkiview, the "deltaCRL Location #2" and "CDP location #2" still both read the same HTTP path, but now it's the deltacrl that shows as "unable to download" and "cdp location #2" now shows as okay - progress, maybe?

    However, based on Daisy's post above, deltaCRL location #2 and cdp location #2 should have different paths, right? like, http://cert.ssc.wisc.edu/cdp/sscc%20ca+.crl or something? That new + file now exists on the IIS share, too

    How can I get that new + crl file to be offered and visible in pkiview?

    • Marked as answer by MD5Hash Monday, September 16, 2019 9:04 PM
    Monday, September 16, 2019 7:40 PM
  • I figured it out - I needed to also edit the http:// path, not just the c:\ path, to include <DeltaCRLAllowed> variable, and then republish "revoked certificates" from certsrv - now pkiview comes back as green, and the SSCC%20CA+.crl is now being distributed. With the trusted root certificate installed, certutil can now validate an entire multi-level certificate chain including AIA and CDP.
    • Marked as answer by MD5Hash Monday, September 16, 2019 9:04 PM
    Monday, September 16, 2019 9:04 PM
  • Hi,
    Thank you for your update and sharing. I’m very glad that the problem has been solved.
     
    As always, if there is any question in future, we warmly welcome you to post in this forum again. 

    Have a nice day!


    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, September 17, 2019 12:59 AM
    Moderator