none
RDP SSL Failed "A revocation check could not be performed on this certificate" RRS feed

  • Question

  • Been searching all morning for a resolution to this with no luck.

    Topology:

    • Offline Root CA (Windows 2012)
    • Enterprise Subordinate CA (Windows 2012)

    Current Issue:

    • Deployed certificate template and setup for Windows 7 / Windows 2012 to secure RDP sessions with SSL (used this http://www.derekseaman.com/2013/01/creating-custom-remote-desktop-services.html)
    • RDP Security set to Negotiate (since there is a certificate present, it defaults to SSL)
    • When connecting from Windows 7/8 client that is NOT domain joined to Windows 7/2012 via RDP, am presented with a warning/failure that "A revocation check could not be performed on this certificate"

    Troubleshooting steps already taken:

    • Verified that the CDP and AIA settings for all certificates (server and subCA) are pointed to http://certificates.domain.com/pki
    • Verified that the URL has the allowDoubleEscaping=True flag set within IIS
    • Verified permissions to write to the directory and share
    • Verified IIS authentication set to Anonymous
    • Verified non-domain joined client computers can successfully read published CRLs
    • Verified all proper CRLs and delta CRLs are being published
    • From a domain-joined computer, this does not happen
    • Verified that computer which is impacted by this does have all root and sub certs installed in correct stores on the local computer
    • Tried to save .rdp connection file and update the setting for credSSP with no luck
    • Verified all certificates visually check out, nothing expired, all certificates present
    • ran certutil -url against one of my rdpAuth certificates, all URLs check out
    • ran certutil -verify -fetchurl against the same rdpAuth certificate, I get the following output (bolding mine):

    PS C:\> certutil –verify –urlfetch sfxxxxad01.cer
    Issuer:
        CN=domainSubCA
        DC=domain
        DC=com
      Name Hash(sha1): 1d446a6b39e7014d113319d1a22f74523a10a597
      Name Hash(md5): 16d7a89801f784479045ce3c8c5693fb
    Subject:
        CN=sfxxxxad01.domain.com
      Name Hash(sha1): fd94f9031c4082755c836f3c28fb6d7597efcccc
      Name Hash(md5): ac2a34cdb755bf174dd92869cda9cb6c
    Cert Serial Number: 6d0000019999ee0fc78f46427d000000000199
    
    dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
    HCCE_LOCAL_MACHINE
    CERT_CHAIN_POLICY_BASE
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
    ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
    
    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
    SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
    
    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
      Issuer: CN=domainSubCA, DC=domain, DC=com
      NotBefore: 6/13/2013 11:56 AM
      NotAfter: 6/13/2015 11:56 AM
      Subject: CN=sfxxxxad01.domain.com
      Serial: 6d0000019999ee0fc78f46427d000000000199
      SubjectAltName: DNS Name=sfxxxxad01.domain.com
      Template: domainRemoteDesktopServerAuth
      cb c6 fd 8f 3a cf 0e 0e 75 79 4e 8e 7f d7 d4 e8 28 55 3f ca
      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  ----------------
      Verified "Certificate (0)" Time: 0
        [0.0] http://certificates.domain.com/pki/sfxxxxpki02.domain.com_domainSubCA.crt
    
      ----------------  Certificate CDP  ----------------
      Expected Base CRL "Delta CRL (26)" Time: 0
        [0.0] http://certificates.domain.com/pki/domainSubCA.crl
    
      ----------------  Certificate OCSP  ----------------
      No URLs "None" Time: 0
      --------------------------------
      Application[0] = 1.3.6.1.4.1.311.54.1.2 Remote Desktop Authentication
    
    	CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
    	  Issuer: CN=domainRootCA
    	  NotBefore: 5/29/2013 11:31 PM
    	  NotAfter: 5/29/2023 11:41 PM
    	  Subject: CN=domainSubCA, DC=domain, DC=com
    	  Serial: 3000000002216518440a315c0b000000000002
    	  Template: SubCA
    	  cb f7 3c 87 7c 29 a4 95 e9 7d ad 74 60 63 0b f0 fe 78 c5 12
    	  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
    	  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    	  ----------------  Certificate AIA  ----------------
    	  Verified "Certificate (0)" Time: 0
    		[0.0] http://certificates.domain.com/pki/sfxxxxpki01_domainRootCA.crt
    
    	  ----------------  Certificate CDP  ----------------
    	  Verified "Base CRL (02)" Time: 0
    		[0.0] http://certificates.domain.com/pki/domainRootCA.crl
    
    	  ----------------  Base CRL CDP  ----------------
    	  No URLs "None" Time: 0
    	  ----------------  Certificate OCSP  ----------------
    	  No URLs "None" Time: 0
    	  --------------------------------
    		CRL 02:
    		Issuer: CN=domainRootCA
    		ThisUpdate: 5/29/2013 9:26 PM
    		NextUpdate: 11/28/2013 9:46 AM
    		a7 e4 d2 ec b7 56 ee 6a 55 df 20 f2 8e 31 ca 2e f4 4d d2 a9
    	  Issuance[0] = 1.2.3.4.1455.67.89.5
    
    CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=domainRootCA
      NotBefore: 5/29/2013 9:08 PM
      NotAfter: 5/29/2033 9:18 PM
      Subject: CN=domainRootCA
      Serial: 1bda28d10cdb878345810344527c3c5e
      b1 74 73 fd 92 3c df 84 ee 2e 04 d9 c1 42 85 97 f9 f0 56 c8
      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate CDP  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate OCSP  ----------------
      No URLs "None" Time: 0
      --------------------------------
      Issuance[0] = 1.2.3.4.1455.67.89.5
    
    Exclude leaf cert:
      4a ac 1a b3 f6 95 f6 3c 11 fc 2d a9 a7 83 c6 9a 01 79 cb 2f
    Full chain:
      9e 09 5d fe 89 2c 20 d3 77 79 cd 39 cd 40 0f 63 ca a8 3b f4
      Issuer: CN=domainSubCA, DC=domain, DC=com
      NotBefore: 6/13/2013 11:56 AM
      NotAfter: 6/13/2015 11:56 AM
      Subject: CN=sfxxxxad01.domain.com
      Serial: 6d0000019999ee0fc78f46427d000000000199
      SubjectAltName: DNS Name=sfxxxxad01.domain.com
      Template: domainRemoteDesktopServerAuth
      cb c6 fd 8f 3a cf 0e 0e 75 79 4e 8e 7f d7 d4 e8 28 55 3f ca
    The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-214688561
    3)
    ------------------------------------
    Revocation check skipped -- server offline
    
    ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation beca
    use the revocation server was offline. 0x80092013 (-2146885613)
    CertUtil: The revocation function was unable to check revocation because the revocation server was offline.
    
    CertUtil: -verify command completed successfully.

    So, to me, everything checks out, but still seeing this issue with non-domain computers, even though the URL for the distribution point is fully accessible and all the certificates are there.  This PKI was planned appropriately, even the offline rootCA is publishing correctly to the same distribution point.

    Any guidance would be appreciated!



    • Edited by justinhamlin Friday, June 28, 2013 7:47 PM more info added
    Friday, June 28, 2013 7:34 PM

Answers

  • To add a final note to this, I was able to resolve the OCSP issues by actually configuring the Online Responder through the management console.  Yeah, I apparently just skipped that one.

    • http://technet.microsoft.com/library/cc770413.aspx

    Configured OCSP as directed in the document (remember to set the registry entries located in the doc), deleted the CA Exchange certificate, published new CRL and Delta CRL, restarted services and everything is up and running.

    Conclusion

    Here are the main points to check:

    • OCSP is configured as per the document linked above
    • CDP and AIA locations are set correctly and published to IIS/LDAP
    • Anonymous access on the OCSP IIS virtual directory as well as the location of the CRLs
    • The <DeltaCRLAllowed> option is enabled on CDP for both local file path and HTTP

    Hopefully this thread posts some good troubleshooting methods for everyone who reads it.

    • Marked as answer by justinhamlin Monday, July 8, 2013 8:55 PM
    Monday, July 8, 2013 8:55 PM

All replies

  • If anyone is reading this, I wanted to add some more details to this thread.

    Additional Troubleshooting:

    • after additional hours of troubleshooting, validated all IIS settings are correct according to what solved everyone else's issues
    • validated file permissions for CRLs
    • Used to Enterprise PKI MMC Snap In on my IssuingCA server.  The Root shows no errors, however, the IssuingCA throws 2 errors:  CDP Location #1 (which points to my HTTP distribution site) "Unable to Download" and OCSP Location #1 just says "Error"
    • Using the Enterprise PKI MMC Snap in, AIA and CA Certificate check out with no issues

    From what I can tell after searching, it looks like this is a mismatch with the CRL being requested not matching up to the CRL at the distribution point.  The only scenarios i can relate to this is when others have had multiple IssuingCA certs issued from their RootCA and the published CRL is the CRL from the first IssuingCA Cert, when the request is looking for a CRL for the 2nd IssuingCA Cert.

    The only thing I can think of is if there was an issue with when/how I requested the IssuingCA and setup the IssuingCA.  I am trying to avoid having to renew or replace the IssuingCA cert, but not sure if I have a choice.

    Thursday, July 4, 2013 4:41 PM
  • Alright, nice breakthrough here.

    (by the way, keeping this up so that anyone searching the TechNet site will be able to find this and hopefully help them in their troubleshooting..)

    First breakthrough was resolving the HTTP CRL Publishing error.  Here is what I had for my CDP Publishing settings:

    • c:\CertificatesWeb\pki\<CAName><CRLNameSuffix>.crl
    • http://certificates.domain.com/pki/<CAName><CRLNameSuffix>.crl

    These are both the same location, and I had the checkboxes for "Publish CRL to this location" and "Publish Delta CRL to this location" checked for the C:\ reference.  For the HTTP reference, I had the checkboxes for "Include in CRLs", "Include in the CDP extension" and "Include in the IDP extension" all checked.

    After researching some best practices, I realized that part of my issue was the Delta CRLs.  So, I updated my CDP settings to:

    • c:\CertificatesWeb\pki\<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
    • http://certificates.domain.com/pki/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl

    I left all the checkboxes the same, refreshed my ADCS services, and viola, the CDP error in Enterprise PKI was resolved, and now my certutil checks now passed with only an error now about OCSP.

    --

    With that issue resolved, I re-issued a few certificates, however, was still running into the same "A Revocation check could not be performed on this certificate" error when using RDP over SSL from a Windows 7/8 computer.

    I downloaded the latest CRL from the https://certificates.domain.com/certsrv website, installed it into my local certificates store, and all of a sudden, no more "revocation check" errors on my RDP over SSL.

    Next up, researching my OCSP implementation and figuring out why Windows 7/8 isnt downloading the CRL correctly.  Something tells me these last 2 pieces are related.


    • Edited by justinhamlin Friday, July 5, 2013 2:41 PM formatting
    Friday, July 5, 2013 2:41 PM
  • One more quick update.

    While troubleshooting OCSP (i am still getting errors, more on that later), I continued to troubleshoot with the CertUtil and various local VMs.  To my disbelief, after NOTHING changed overnight, RDP over SSL is successfully checking CRLs via http on non-domain joined computers with no issues.

    I was able to test this across 2 VMs and multiple other domain-joined remote servers, as well as various methods, such as my Remote Desktop Services Web front end, all, with absolutely no issues.

    I will continue to troubleshoot my OCSP in order to fix this 100%, however, in the interim, this is functional.  

    Regarding OCSP, I am testing it in 2 ways:

    • Enterprise PKI MMC Snap In on my IssuingCA server
    • Certutil -url cert.cer on a separate server

    One item to note that I came across is that there has been some discussion that the Enterprise PKI snap-in is actually testing the configuration of ALL ISSUED CERTS on the CA in order to validate AIA, CDP and OCSP.  I am not 100% sure if that is true, or if it is just testing the current configuration of the CA, but I diguress.

    Testing through the Enterprise PKI Snap In also shows the OCSP location of http://certificates.domain.com/ocsp in ERROR, however, when testing with the CertUtil URL tool, the messaging is a little more detailed, as it comes us as "Unsuccessful"

    Upcoming troubleshooting will include leveraging certutil -verify -urlfetch shell command to test the certificates using the newly published OCSP location.  

    Friday, July 5, 2013 5:13 PM
  • To add a final note to this, I was able to resolve the OCSP issues by actually configuring the Online Responder through the management console.  Yeah, I apparently just skipped that one.

    • http://technet.microsoft.com/library/cc770413.aspx

    Configured OCSP as directed in the document (remember to set the registry entries located in the doc), deleted the CA Exchange certificate, published new CRL and Delta CRL, restarted services and everything is up and running.

    Conclusion

    Here are the main points to check:

    • OCSP is configured as per the document linked above
    • CDP and AIA locations are set correctly and published to IIS/LDAP
    • Anonymous access on the OCSP IIS virtual directory as well as the location of the CRLs
    • The <DeltaCRLAllowed> option is enabled on CDP for both local file path and HTTP

    Hopefully this thread posts some good troubleshooting methods for everyone who reads it.

    • Marked as answer by justinhamlin Monday, July 8, 2013 8:55 PM
    Monday, July 8, 2013 8:55 PM
  • Hi Justin,

    Thank you for sharing your finding with us. The OCSP related troubleshooting is precious supplement to the Forum. Thank you for your valuable contribution!

    Thanks, Brian


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, July 22, 2013 4:59 AM