locked
Revocation check using LDAP URL fails

    Question

  • After changing the certificate used by Remote Desktop services from the default self-issued one to one issued by my own CA, I get the following message on Remote Desktop client computers when the try to connect:
    A revocation check could not be performed for the certificate

    I know there are other threads about this message, and I sucessfully eliminated the revocation check message by importing the CRL into the certificate store of the Remote Desktop client computer.

    However, I want to ask a question about revocation check failure I have not seen addressed elsewhere.  The problem seems to be that the LDAP connection to the CRL Distribution point fails. 

    I have corrobated this by running
    certutil -URL ldap:///CN=My-CA,CN=servername,CN=CDP,CN=Public%20Key%20 ervices,CN=Services,CN=Configuration,DC=domainame,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

    I have also tried running certutil -URL with ldap://servername.domainname.com/CN=My-CA,CN=servername,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domainame,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

    Either of these LDAP URL's work when certutil -URL is run on the computer running my CA, but fail when run from a non-domain computer on the same subnet as the CA computer.

    Any suggestions about how to make Revocation check using LDAP URLs work?

    Thanks.


    Update: are the LDAP URLs accessible only with domain credentials?  If so, is there a different way to publish an LDAP CRL that is accessible with no-domain credentials?
    Thursday, October 22, 2009 4:37 PM

Answers

  • Hi,

     

    Thanks for your post.

     

    You are correct, domain credential is required to access the LDAP CDP. In order that the workgroup client computer can download the CRL, you need to publish the CRL to an HTTP location.

     

    For more information, you can refer to the “CRL Best Practices” section of the following article:

     

    Creating Certificate Policies and Certificate Practice Statements

    http://technet.microsoft.com/en-us/library/cc780454(WS.10).aspx

     

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, October 23, 2009 6:31 AM
    Moderator
  • Thanks for your quick reply, and for the CRL Best Practices link.  Here is a follow-up question: How do you place the HTTP location first?

    According to CRL Best Practices, "If you have a mixed client environment or both internal and external clients, it is a best practice to place the HTTP location in the CRL distribution point extension first to avoid network timeouts". 



    For any who follow this thread, here are a couple of things I learned.

    1.  You need to re-publish the base CRL after making changes to the CRL distribution location.  If you don't, clients will be checking a stale CRL, which in my case had only an LDAP location, so revocation checking using certutil -URL certificatename.cer fails.

    2.  Once you fix that, revocation checking using certutil -URL certificatename.cer still fails because IS 7.0 by default can't handle double escape characters (like the plus sign), which prevents access to the delta CRL file, whose name is the form CAName+.crl.  I worked around this by editing the web.config file in the same folder as the base and delta CRL files to AllowDoubleEscaping, as described in http://jcwarnerii.spaces.live.com/blog/cns!DAFBEF02F4CD141!175.entry?sa=790923091.

    3.  Make sure the Root Certificate of your CA is imported into the Trusted Root Certification Authorities container of the RDC client computer.

    With these steps completed, certutil -URL certificatename.cer succeeds, and the Remote Desktop Client version 6.1.7600 connects without error.  In the Connection Bar, there will be a padock icon, which if you click it, will show that identity of the remote computer was verified by using a server certificate.  If you click the View Certificate button, you can see that the certicate used is the one issued by your CA.

    Friday, October 23, 2009 6:05 PM

All replies

  • Hi,

     

    Thanks for your post.

     

    You are correct, domain credential is required to access the LDAP CDP. In order that the workgroup client computer can download the CRL, you need to publish the CRL to an HTTP location.

     

    For more information, you can refer to the “CRL Best Practices” section of the following article:

     

    Creating Certificate Policies and Certificate Practice Statements

    http://technet.microsoft.com/en-us/library/cc780454(WS.10).aspx

     

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, October 23, 2009 6:31 AM
    Moderator
  • Thanks for your quick reply, and for the CRL Best Practices link.  Here is a follow-up question: How do you place the HTTP location first?

    According to CRL Best Practices, "If you have a mixed client environment or both internal and external clients, it is a best practice to place the HTTP location in the CRL distribution point extension first to avoid network timeouts". 



    For any who follow this thread, here are a couple of things I learned.

    1.  You need to re-publish the base CRL after making changes to the CRL distribution location.  If you don't, clients will be checking a stale CRL, which in my case had only an LDAP location, so revocation checking using certutil -URL certificatename.cer fails.

    2.  Once you fix that, revocation checking using certutil -URL certificatename.cer still fails because IS 7.0 by default can't handle double escape characters (like the plus sign), which prevents access to the delta CRL file, whose name is the form CAName+.crl.  I worked around this by editing the web.config file in the same folder as the base and delta CRL files to AllowDoubleEscaping, as described in http://jcwarnerii.spaces.live.com/blog/cns!DAFBEF02F4CD141!175.entry?sa=790923091.

    3.  Make sure the Root Certificate of your CA is imported into the Trusted Root Certification Authorities container of the RDC client computer.

    With these steps completed, certutil -URL certificatename.cer succeeds, and the Remote Desktop Client version 6.1.7600 connects without error.  In the Connection Bar, there will be a padock icon, which if you click it, will show that identity of the remote computer was verified by using a server certificate.  If you click the View Certificate button, you can see that the certicate used is the one issued by your CA.

    Friday, October 23, 2009 6:05 PM
  • Thanks for your quick reply, and for the CRL Best Practices link.  Here is a follow-up question: How do you place the HTTP location first?

    According to CRL Best Practices, "If you have a mixed client environment or both internal and external clients, it is a best practice to place the HTTP location in the CRL distribution point extension first to avoid network timeouts". 



    For any who follow this thread, here are a couple of things I learned.

    1.  You need to re-publish the base CRL after making changes to the CRL distribution location.  If you don't, clients will be checking a stale CRL, which in my case had only an LDAP location, so revocation checking using certutil -URL certificatename.cer fails.

    2.  Once you fix that, revocation checking using certutil -URL certificatename.cer still fails because IS 7.0 by default can't handle double escape characters (like the plus sign), which prevents access to the delta CRL file, whose name is the form CAName+.crl.  I worked around this by editing the web.config file in the same folder as the base and delta CRL files to AllowDoubleEscaping, as described in http://jcwarnerii.spaces.live.com/blog/cns!DAFBEF02F4CD141!175.entry?sa=790923091.

    3.  Make sure the Root Certificate of your CA is imported into the Trusted Root Certification Authorities container of the RDC client computer.

    With these steps completed, certutil -URL certificatename.cer succeeds, and the Remote Desktop Client version 6.1.7600 connects without error.  In the Connection Bar, there will be a padock icon, which if you click it, will show that identity of the remote computer was verified by using a server certificate.  If you click the View Certificate button, you can see that the certicate used is the one issued by your CA.

    Dear Sejong,

    I use "certutil -URL certfile.cer" from RD Client with result below:
    Status        Type                  Url
    Verified     Base CRL (52)     [0.0]http://xxxxx/xxxx.crl
    Failed        CDP                   [0.0.0]ldap:///CNxxxxx....
    Failed        CDP                   [0.1.0]http://dc1.xx.local/xxxx....
    Verified     Delta CRL (52)    [0.0.2]http://xxxxx/xxxx.crl

    I use the certfile.cer for RD Server connection on Win08R2.
    From the certfile.cer, I configured the CDP and AIA only use http://xxxx.xxx.crl already which can be touched by RD client.
    But Win7 and Win08R2 RD Client cannot connect with "A revocation check could not be performed for the certificate" error.

    Any hints can suggest to me?
    Thanks a lot.

    Regards,
    Wing Ko
    Monday, October 26, 2009 3:19 AM
  • 1.  Remove the LDAP URLs, and re-publish the CRL.  Your post says you "configured the CDP and AIA [to] only use http...", but the output of certutil -URL certfile.cer shows failure for LDAP URLs, suggesting that both HTTP and LDAP URLs are in use. 

    It's possible that having both HTTP and LDAP URLs is OK, but it in that case it may be necessary to have the HTTP URLs listed before the LDAP ones.  This why I asked the question How do you place the HTTP location first?  Until that is answered, I'm using HTTP only.

    2.  Instead of running certutil -URL certfile.cer, run certutil -f -URLFetch certfile.cer, and check the output for errors.  I just ran this command and got the following output (I deleted some portions of the output that I did not think were relevant)

     ----------------  Certificate AIA  ----------------
     Verified "Certificate (0)" Time: 0
       [0.0] http://server.domain.com/CertEnroll/SERVER.domain.com_domain-SERVER-CA.crt

     ----------------  Certificate CDP  ----------------
     Verified "Base CRL (20)" Time: 0
       [0.0] http://server.domain.com/CertEnroll/domain-SERVER-CA.crl

     Verified "Delta CRL (20)" Time: 0
       [0.0.0] http://server.domain.com/CertEnroll/domain-SERVER-CA+.crl

     ----------------  Base CRL CDP  ----------------
     OK "Delta CRL (22)" Time: 0
       [0.0] http://server.domain.com/CertEnroll/domain-SERVER-CA+.crl


    Verified Issuance Policies: None
    Verified Application Policies:
        1.3.6.1.5.5.7.3.2 Client Authentication
        1.3.6.1.5.5.7.3.1 Server Authentication
    Leaf certificate revocation check passed
    CertUtil: -verify command completed successfully.

    3.  Enable CAPI2 Operational Logging (if not already enabled), and check the CAPI2 Operational log for errors.  In my experience, the following Information events are associated with a successful connection

    Event 10 Build Chain (2 instances)
    Event 11 Build Chain (2 instances)
    Event 30 Verify Chain Policy  (2 instances)
    Event 40 Verify Revocation
    Event 41 Verify Revocation
    Event 90 X509 Objects  (2 instances)

    Monday, October 26, 2009 1:23 PM
  • Hi sejong,

     

    Glad to hear that the issue has been resolved and thanks for your sharing.

     

    As for the follow-up question, the sentence means that it is a best practice to create the HTTP location first in the CRL distribution point extension.

     

    Thanks.

     

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, October 27, 2009 3:21 AM
    Moderator
  • hi guys - also experiencing the isue - and not keen to move my CRL's over to HTTP only.
    Any more info or timeframe on fixing this as yet ?
    Wednesday, October 28, 2009 2:35 PM
  • You could try deleting LDAP URLs, creating HTTP URLs if they don't exist already, then create new LDAP URLs.  This might cause the HTTP URLs to be listed first.  I have not tried it because at this time using HTTP URLs only works for me.
    Wednesday, October 28, 2009 4:17 PM
  • sejong,
              The client i was initially experiening this problem with - well, the issue seems to have solved itself... which bugged me... as i want to find a definitive solution or work-around for this issue.

    So i made up a test environment in a few virtuals and am having the same issue when clients try and access RD Web apps via RD Gateway
    1) The HTTP CRL path is the only CRL path (I have deleted the LDAP path) - and there is only one HTTP path available.
    2) If i copy/paste the crl path out of the cert, i can download the CRL succesfully
    3) The Root CA certfifcate is in the trusted root authorities certificate store for the local computer
    4) I have re-published the CRL since updating the CRL paths
    5) Using Certutil -url on the cert in question verifies the CRL and AIA downloads are available
    6) The ISA logs show HTTPS traffic to the RD web site, then to the RD Gateway, but i never see any attempts from the client IP to get the CRL via HTTP. 

    I'm not quite sure what the next step is to troubleshoot this. I've been running network captures, but can't see any http requests going to the CRL location just before the certificate error appeears.

    Got any suggestions ?
    • Edited by Ben_22 Thursday, November 05, 2009 3:13 AM Updated info
    Thursday, November 05, 2009 3:00 AM
  • I have been working with full Remote Desktop, not RD Gateway, so there may be some differences.  That said, did you try running the following command to see if it shows any errors?

    certutil -URL certfile.cer, run certutil -f -URLFetch certfile.cer

    Also, can you dowload the delta CRL as well as the base CRL?
    Thursday, November 05, 2009 1:38 PM
  • ah - apologies, i thought this was what you were experieincing in a RD Gateway scenario.

    yep - as stated - certutil -url <mycert.cer> - retunrs verified for both the full and delta crl

    the second command doesnt seem to be recognised by my certutil - and i cant see anything close when running a "/?" to see the options.... I am running a win 7 client, so im not sure if certutil has different versions ?

    Overnight i have also found that a number of other win7 or win2008 R2 clients work fine - the difference being that this client (the one that doesnt work) had tried to access rdgateway while the CRL path had a different HTTP address first. I then updated the CA, re-issued the certs and re-tried, with just one, correct HTTP path for the CRL.

    So im thinking that this client may have the old cert still cached somewhere/somehow? Even though when i view the cert, it has the current properties - including the CRL path.

    I have tried clearing the SSL state etc, but to no avail. I have also waited 12 hours inbetween attempts.... to no avail ( i found an article that stated the cert timeout for XP was 10 hours - couldnt find one relating to win 7)
    Thursday, November 05, 2009 7:38 PM
  • My apologies; the syntax of the second command is:

    certutil –urlfetch -verify <mycert.cer>

    Also, when connected a certificate-secured Remote Desktop session, I have sometimes noticed a delay where a first attempt to connect gives the "A revocation check could not be performed for the certificate" error, but subsequent attempts will succeed.  This seems to happen after switching from a CA-issued certificate to the self-issued certificate, then back to the CA-issued one.
    Tuesday, November 10, 2009 1:22 PM
  • Ahh thanks.

    I ran the command - and as expected, everything returns ok. The AIA and full/delta paths are correct and verified. I created and revoked a cert just to check - and it reports correctly back as revoked.

    I've tried a bunch of things.... clearing the ssl cache within IE, importing the CRLs manually, importing the certificate into the computer store, disabling CRL checking on the trusted root cert... waiting until any cache should have expired - all to no avail.

    It seems that if you have multiple HTTP CRL paths, when the externally accessable CRL path is not the first one, any client that tries to use RDweb/RD Gateway will fail... after updating the CRL path to contain only the externally accessable path (and re-issuing the certs), any client that tried to access RD Gateway already (while the old CRL paths were active) will continue to fail... while any new clients are fine.

    I was hoping to at least find a work-around for the issue - but the way its going, i dont think its going to happen!

    Thanks for your help sejong - looks like we'll be recommending to only use external certs with RDWeb/RDGateway.
    Tuesday, November 10, 2009 11:54 PM
  • I've enabled CAPI2 logging, and it seems that even though I've configured all the lists to be available only by HTTP, it still tries to load them over LDAP..

    hm...
    Tuesday, January 19, 2010 10:00 PM
  • just after writing that I found the answer - earlier I've tried installing CRL into local store. But that didn't help. They stayed there, and the engine was loading CRLs NOT from the newly downloaded cert, but from the installed CRL, which only had LDAP targets!
    Tuesday, January 19, 2010 10:04 PM