none
Certificate revocation check from external network

Answers

  • Do i need to add anything else to the certificate for revocation check to work ie. publishing AIA also?


    Thanks

     

    I'll reply to myself. Yes you need to publish AIA also, and if you had done so in the first place you could have saved yourself 2 days hanging on the forum waiting for the answer.

    Monday, October 05, 2009 8:22 AM

All replies

  • so, here is 2 things that I want to explain.
    The first thing is that your problem is not with CRL only. Unfortunately all RPC 7.0 (on Windows 7 RTM, Windows Server 2008 R2 RTM, and RC packages for Windows XP and Windows Vista) have a bug with CRL checking. At this time you have only one way - replace RDC 7.0 with 6.1.

    the second thing is that if you use CA on Windows Server 2008, you need to configure IIS to interpretate plus signs as literal characters. Please refer this link:
    http://www.ifinity.com.au/Blog/Technical_Blog/EntryId/60/404-Error-in-IIS-7-when-using-a-Url-with-a-plus-sign-in-the-path

    also check if your Proxy/Firewall allow access form internet to your intrenal IIS server. please note that client now doesnt't support FTP paths for CRL checking.


    Please let me know if something is not clear for you.

    [http://www.sysadmins.lv] As always enjoy the automation of tools within the Windows-based, .NET aware, WPF accessible, multi-processes on the same IP / Port usage, admin's automation tool, powershell.exe! © Flowering Weeds
    Saturday, October 03, 2009 7:50 PM
  • The problem is that downloading delta manually http://myserver.dyndns.org/certenroll/MyServer+.crl works either. So no IIS error, firewall is open (fetching the URL with no credentials)

    I stress once more: no failed, not verified entry in  certutil check run from outside (done on XP SP3 with RDP 6.1) for delta CRL. Just this one:


    ----------------  Certificate CDP  ----------------

    Verified "Base CRL (22)" Time: 2
        [2.0]
    http://myserver.dyndns.org/CertEnroll/MY-SERVER-CA.crl




    while I get both verified

    ----------------  Certificate CDP  ----------------

    Verified "Base CRL (30)" Time: 0
        [1.0]
    http://myserver.local/CertEnroll/MY-SERVER-CA.crl

    Verified "Delta CRL (30)" Time: 0
        [1.0.1]
    http://myserver.local/CertEnroll/MY-SERVER-CA+.crl


    and both failed (they get checked at least)


    Failed "CDP" Time: 0
        Error retrieving URL: Error 0x80070194 (WIN32: 404)
        [1.2.0]
    http://myserver.dyndns.org/CertEnroll/MY-SERVER-CA+.crl

      Failed "CDP" Time: 0
        Error retrieving URL: Error 0x80070194 (WIN32: 404)
       
    http://myserver.dyndns.org/CertEnroll/MY-SERVER-CA.crl

    when I run the command from inside.


    My question is: will verifying delta crl bring succesful revocation check at least with RDP 6.1? That would be satisfactory to me. For now I am getting the same error although not verbose but numerical 0x80090327 even in RDP 6.1

    thanks

    Sunday, October 04, 2009 8:55 AM
  • > will verifying delta crl bring succesful revocation check at least with RDP 6.1?

    only if BaseCRL is available for client. Client cannot rely on DeltaCRL info only.

    try this one:
    certutil -url certificate.cer

    and check for any errors.
    [http://www.sysadmins.lv] As always enjoy the automation of tools within the Windows-based, .NET aware, WPF accessible, multi-processes on the same IP / Port usage, admin's automation tool, powershell.exe! © Flowering Weeds
    Sunday, October 04, 2009 11:09 AM
  • ----------------  Certificate CDP  ----------------

    Verified "Base CRL (22)" Time: 2
        [2.0]
    http://myserver.dyndns.org/CertEnroll/MY-SERVER-CA.crl

    Base is already available as I said in the above posts.


    Running your command produces

    For retreive CRLs (from CDP)

    OK for type BASE CRL (1e) and OK for type DELTA CRL (1e) at my external site
    failures at all internal CRLs ldap and http - type CDP

    For retreive Certs (from AIA)
    I have no external urls for this extemsion
    failures for internal URLS - type AIA

    For retreive OCSP
    No URLS

    So both external CRLs are retrieved. What should i do next?

    Sunday, October 04, 2009 12:05 PM
  • Do i need to add anything else to the certificate for revocation check to work ie. publishing AIA also?


    Thanks

     

    I'll reply to myself. Yes you need to publish AIA also, and if you had done so in the first place you could have saved yourself 2 days hanging on the forum waiting for the answer.

    Monday, October 05, 2009 8:22 AM
  • so, here is 2 things that I want to explain.
    The first thing is that your problem is not with CRL only. Unfortunately all RPC 7.0 (on Windows 7 RTM, Windows Server 2008 R2 RTM, and RC packages for Windows XP and Windows Vista) have a bug with CRL checking. At this time you have only one way - replace RDC 7.0 with 6.1.

    the second thing is that if you use CA on Windows Server 2008, you need to configure IIS to interpretate plus signs as literal characters. Please refer this link:
    http://www.ifinity.com.au/Blog/Technical_Blog/EntryId/60/404-Error-in-IIS-7-when-using-a-Url-with-a-plus-sign-in-the-path

    also check if your Proxy/Firewall allow access form internet to your intrenal IIS server. please note that client now doesnt't support FTP paths for CRL checking.


    Please let me know if something is not clear for you.

    [http://www.sysadmins.lv] As always enjoy the automation of tools within the Windows-based, .NET aware, WPF accessible, multi-processes on the same IP / Port usage, admin's automation tool, powershell.exe! © Flowering Weeds

    Dear Vadims Podans,

    Not sure will have bug fix for RPC 7.0 CRL check soon? Any target date?
    Thanks!

    Regards,
    Wing Ko
    Sunday, October 18, 2009 3:26 PM
  • So, at this time I have figured this issue with certificate chaining engine. When RDC tries to connect to SSL-secured TS, client launch certificate chaining engine to validate server certificate. And here is important moment - end certificate must chain up to certificates that stored in Trusted Root CAs in computer store. Therefore if root CA to which chains SSL certificate is stored in Current User store only, certificate chaining engine fails and you will unable to connect to SSL-secured TS.
    [http://www.sysadmins.lv] As always enjoy the automation of tools within the Windows-based, .NET aware, WPF accessible, multi-processes on the same IP / Port usage, admin's automation tool, powershell.exe! © Flowering Weeds
    • Proposed as answer by Max Edrets Thursday, May 06, 2010 1:35 PM
    Sunday, October 18, 2009 4:16 PM
  • Dear Vadims Podans,

    This is my case as well, I installed the CA root cert in "Trusted Root CAs" in computer store already (The cert chain is valid). And the CDP and AIA can be accessed by RDP client computer. But the Secure RDP connection failed from Win7 & Win08R2 "A revocation check could not be performed for the certificate". You said this is bug for RDP client 7.x. Not sure will it be fixed? Or any workaround to fix it?

    Regards,
    Wing Ko
    Monday, October 19, 2009 12:53 AM
  • I know only one workaround - use self-signed certificate for TS. This bug is sent to Windows 7 beta team, however no news from them.
    [http://www.sysadmins.lv] As always enjoy the automation of tools within the Windows-based, .NET aware, WPF accessible, multi-processes on the same IP / Port usage, admin's automation tool, powershell.exe! © Flowering Weeds
    Monday, October 19, 2009 3:06 AM
  • I have been able to get a certificate-secured RDP connection working.  The RDP Client is version 6.1.7600 (Windows 7 RTM or Server 2008 R2 RTM).  The RDP Server is Server 2008 R2 RTM.  I had to use HTTP AIA and CRL locations only (no LDAP locations).  The last post in the following thread gives more detail.

    http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/22915d39-5a53-4233-a307-1f07fc4e019e#67fecf0e-f2b9-477b-a11d-8efb8dd4dc1c
    Monday, October 26, 2009 12:24 AM
  • Hi guys,

    This is not a bug and this is not something that will be changed.
    Since CredSSP the "revocation check could not be performed" error has become non-continuable.
    The two solutions available are the following:

    1. The DWORD key: UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors can be added to:

    System\\CurrentControlSet\\Control\\LSA\\CredSSP and given a non-zero value(1).

    2. Create an RDP file with the following properties. This would make RDP clients use legacy RDP encryption and avoid SSL:

    enablecredsspsupport:i:0
    authentication level:i:0

    We also see this issue when the CRL is published on the CA and the CA is offline, in that case, publish the CA to AD if it's AD integrated.



    Friday, January 15, 2010 2:48 PM
  • Hi guys,

    This is not a bug and this is not something that will be changed.
    Since CredSSP the "revocation check could not be performed" error has become non-continuable.
    The two solutions available are the following:

    1. The DWORD key: UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors can be added to:

    System\\CurrentControlSet\\Control\\LSA\\CredSSP and given a non-zero value(1).

    2. Create an RDP file with the following properties. This would make RDP clients use legacy RDP encryption and avoid SSL:

    enablecredsspsupport:i:0
    authentication level:i:0

    We also see this issue when the CRL is published on the CA and the CA is offline, in that case, publish the CA to AD if it's AD integrated.




    Hi Leon. Please could you elaborate on what you mean when you say "Since CredSSP the "revocation check could not be performed" error has become non-continuable." ?

    The two solutions don't seem good enough to me. My certificate provides CRL and AIA locations that are happily http accessible, from anywhere, yet RDP 7 client fails to check the CRL.
    Monday, January 25, 2010 4:11 PM
  • Where is the root certificate for your certificate installed? For the current RDP client it needs to be in the computer's Trusted Root store, it won't work if it is in the user's Trusted Root store.


    Paul Adare CTO IdentIT Inc. ILM MVP
    Monday, January 25, 2010 4:34 PM
  • It's in the Computer's trusted root store.
    Here's the output of certutil on the term servers certificate. You can try out the CRL address yourself..
    Issuer:
        CN=simtrava-STSERVER-CA
    Subject:
        CN=TERMSERVER.simtrava.local
    Cert Serial Number: 13f3b5cb000000000011
    
    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.dwRevocationFreshnessTime: 28 Minutes, 34 Seconds
    
    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwRevocationFreshnessTime: 28 Minutes, 34 Seconds
    
    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=simtrava-STSERVER-CA
      NotBefore: 25/01/2010 4:12 PM
      NotAfter: 25/01/2011 4:12 PM
      Subject: CN=TERMSERVER.simtrava.local
      Serial: 13f3b5cb000000000011
      SubjectAltName: DNS Name=TERMSERVER.simtrava.local
      Template: Machine
      15 d5 2d f1 84 84 e7 d6 84 57 a2 48 55 a9 56 4c 17 58 d0 d2
      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://oldham.simtrava.co.uk/CertEnroll/STSERVER.simtrava.local_simtrava-STSERVER-CA.crt
    
      ----------------  Certificate CDP  ----------------
      Verified "Base CRL (0177)" Time: 0
        [0.0] http://oldham.simtrava.co.uk/CertEnroll/simtrava-STSERVER-CA.crl
    
      Verified "Delta CRL (0177)" Time: 0
        [0.0.0] http://oldham.simtrava.co.uk/CertEnroll/simtrava-STSERVER-CA+.crl
    
      ----------------  Base CRL CDP  ----------------
      OK "Delta CRL (0177)" Time: 0
        [0.0] http://oldham.simtrava.co.uk/CertEnroll/simtrava-STSERVER-CA+.crl
    
      ----------------  Certificate OCSP  ----------------
      No URLs "None" Time: 0
      --------------------------------
        CRL 0177:
        Issuer: CN=simtrava-STSERVER-CA
        ab 03 9c e5 27 8f 25 16 99 0e 69 c3 1d c7 0a e0 11 78 50 de
        Delta CRL 0177:
        Issuer: CN=simtrava-STSERVER-CA
        df 12 bd 0d 73 86 92 6d 3d 9f e3 75 15 ad e3 4e f9 14 b6 5a
      Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
      Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication
    
    CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=simtrava-STSERVER-CA
      NotBefore: 17/01/2009 1:19 PM
      NotAfter: 17/01/2014 1:29 PM
      Subject: CN=simtrava-STSERVER-CA
      Serial: 701e34c485c71bb847c76ce710bb9295
      cf 15 31 7a 3f c9 49 aa 14 5a 98 ff 6e 66 16 be 54 07 b8 84
      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
      --------------------------------
    
    Exclude leaf cert:
      4b c3 f8 c9 0f bb e0 35 76 2e f7 0e d8 fc 44 72 80 0b dd 9a
    Full chain:
      a1 06 a6 6d fb e2 64 57 f8 33 eb 96 4d f7 c4 a9 cc bb bd b6
    ------------------------------------
    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.
    

    Monday, January 25, 2010 4:48 PM
  • I always place in the computer's trusted root store anyway. RPC-over-HTTPs requires that.

    I think I understand what Leon means - the error is one where the user cannot click ignore/continue, so it's "non-continuable". I thought he was suggesting a reason why this is deemed not to be a bug..

    Monday, January 25, 2010 4:51 PM
  • Might it be that the RDP 7 client only uses OCSP to check certificate validity ? I don't know anything about OCSP and it's not something I have enabled.
    Monday, January 25, 2010 5:18 PM
  • No, this has nothing at all to do with OCSP.
    Paul Adare CTO IdentIT Inc. ILM MVP
    Monday, January 25, 2010 6:39 PM
  • Vadim Podans, thank you very much for you suggestion!

    For me placing the CA certificate in computer's Trusted Root CAs, not just user's solved the problem. 

    It is strange that the errors were about CRL check, not the CA trust...

    Thursday, May 06, 2010 1:42 PM
  • > It is strange that the errors were about CRL check, not the CA trust...

    this is expected, because certificate chaining engine don't check certificate for revocation if chain root certificate is not trusted. This is because you cannot trust revocation information for untrusted certificate chain. 


    http://www.sysadmins.lv
    Thursday, May 06, 2010 1:47 PM
  • I found this thread just today. (opened another question http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/9edad881-1c4e-4e66-a806-f7a1351a762c)

    My CA certificate was already on the computer keystore, but nevertheless I removed it and reimported the CA chain (p7b) again just to be sure.

    The issue continues. It complains about the revocation list although the CRLs are available publicly plus the AIA.

    On the browser https pages work perfectly... RD and SSTP no!

    I have no clue why something so simple prevents my remote desktop to function. Not only I have that problem on the RD but also on a SSTP VPN.

    Can someone please confirm this to be a bug! Even on the above thread it looks to be a bug, but then by the end it looks to be by design.

    Thank you for all your help.

     

    Sunday, June 13, 2010 8:52 PM
  • Hi, did you ever found a solution for this? I have the exact same problem!!!!

     

    Sunday, June 13, 2010 8:54 PM
  • I don't know if this helps, but have you deleted all LDAP URLs, created HTTP URLs for the AIA and CRL, and re-published the CRL? 

    Sunday, June 13, 2010 10:50 PM
  • Yes, did exactly that!

    Using the certutil I am able to fecth the CRLs normaly.

    Monday, June 14, 2010 2:02 AM
  • You probably or know about the following items too, but just in case you didn't, I'll suggest them

    run  certutil -urlfetch -verify <YourRDPserverCertificate.cer>.  All checks should pass, including "Leaf certificate revocation check passed" (near the end of the command output)

    In one of your previous posts, you mentioned "On the browser https pages work perfectly... ".  You are probably referring to a different URL, but the URL for your CRL must be http, not https.  When you enter your CRL's URL in a browser, you should be able to get a directory listing that shows your base and delta CRL files.  If you don't get such a listing, make sure you have enabled directory browsing for that web site, and that you have allowed DoubleEscaping to allow the use of the "+" character in the delta CRL.

    One more thing.  From time to time, the revocation check fails even on systems that are properly set up, but this type of failure is transitory, and if you try again, the check will succeed on the second or third attempt.

    Monday, June 14, 2010 3:15 AM
  • Thank you for you reply.

    I fact I knew about this. The CRL http is not https. My note about the browser is that I am able to fecth the files.

    I also did the certutil -URL mycert.cer and this pops-up a gui where is is possible to actualy download and see the crls, etc...

    I have no doubt that the CRL is ok (and AIA). Tried it also from a Unix machiche using wget with success.

    I found out that from VISTA (RDP 6.1) it works just fine. This revocation error happens on W7 (RDP 7).

    I am almost sure this is a bug on RDP 7 ou W7...

    Now, this RDP 7 "thing" is refered on another post. But I found nothing official from Microsoft.

    I am lost and in reality W7 continues to fail always.

    Note: I completly removed the LDAP entries from the CRL.

     

    Monday, June 14, 2010 1:20 PM
  • Once again, you have probably checked this, but since your last post was not explicit about it, let me ask: when you enter the URL that contains your CRL into a browser, do you get a directory listing that shows your delta CRL, base CRL, a .crt file that contains a copy of your Root CA certificate, and a web.config file that contains the rule to allow the use of the + character in the delta CRL filename? 

    If so, can you save/open each of them except for the web.config file?

    The directory listing should look something like this. 

    6/13/2010 10:55 AM     505 Your-CA+.crl
    6/9/2010 10:55 AM       555 Your-CA.crl
    11/19/2009  4:57 PM     851 Your-Server.example.com_Your-CA.crt
    12/21/2009  5:48 PM     275 web.config

    Monday, June 14, 2010 3:06 PM
  • On Mon, 14 Jun 2010 15:06:12 +0000, sejong wrote:

    Once again, you have probably checked this, but since your last post was not explicit about it, let me ask: when?you enter the URL that contains your CRL into a browser, do you get a directory listing that shows your?delta CRL, base CRL, a .crt file that contains a copy of your Root CA certificate, and a web.config file that?contains the rule?to allow the use of the + character in the delta CRL filename??

    If so, can you save/open each of them except for the web.config file?

    The directory listing should look something like this.?

    6/13/2010 10:55 AM???? 505 Your-CA+.crl <http://social.technet.microsoft.com/certenroll/RB-CA&#43;.crl>
    6/9/2010 10:55 AM?????? 555 Your-CA.crl <http://social.technet.microsoft.com/certenroll/RB-CA.crl>
    11/19/2009? 4:57 PM???? 851 Your-Server.example.com_Your-CA.crt <http://social.technet.microsoft.com/certenroll/SERVER2.rb9.net_RB-CA.crt>
    12/21/2009? 5:48 PM?????275 web.config <http://social.technet.microsoft.com/certenroll/web.config>

    No offense but checking to see if one gets a directory listing is a bit
    misleading as there is no requirement to allow directory browsing on the
    vdir that contains the CRLs or the intermediate CA certificates.


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca

    Monday, June 14, 2010 4:29 PM
  • Thanks for pointing that out.  I didn't know it.  I disabled directory browsing on my own CRL virtual directory, and verified that certificate revocation checking for an RDP connection still works.

    Would the ability to open/save the base and delta CRL files be a useful indicator of whether the configuration was correct?

    Monday, June 14, 2010 5:01 PM
  • I am not allowing directory listing on that url. Nevertheless I am able to download perfectly both base and delta and AIA.

    Something strange happen... It workied fine for two days... then it stopped again with the same error. Did nothing, I was all happy thinking this was some sort of W7 internal cache that timedout.

    Was was about to write in here with my finding when it started again.

    This is a paint...

     

    Thursday, June 17, 2010 9:39 AM
  • Additionaly.

    I have done the certutil -fetch... it completes Ok.

    Done the certutil-URL... starts up a small gui where it is possible to fetch and verify all relevant files. All ok.

    Saved files localy using IE (base & delta & AIA)

    gone to Unix machine (no authentication, nothing browser fancy, command line bare bones thing) and used wget to fetch all files... ok!

    I am convinced this is a bug from W7.

    I had a theory before (not sure now); initialy I only had certs with the LDAP URL, then changed that for outside access to be HTTP... the theory I had is that W7 saved somewere that LDAP string and continued to use it although the new cer only had an HTTP URL.

    This is very weird. Not very well explained on official docs and affects many others. There is an official doc on technet that explains how to fix this error by including the HTTP URL on the cert... thats it.

    IS THERE somebody that has this setting working?

    W2008 R2 Std  ---> W7 Ultimate using RemoteApp.  Just that!

    Try it.

    http://corp.webdisplay.pt/CertEnroll/corp-WDSRV01-CA.crl

    http://corp.webdisplay.pt/CertEnroll/WDSRV01.corp.webdisplay.pt_corp-WDSRV01-CA.crt

     

    I can just revert to self-sign certificates... but it should work!!!

     

     

    Thursday, June 17, 2010 9:52 AM
  • You have put a lot of effort into this!

    You asked if somebody has this setting working.  I have, for about  7 months, and people in my company use it daily from many RDP client computers.  Having said that, we have Windows 7 Enterprise clients and Server 2008 R2 Remote Desktop servers.  You have Windows 7 client and server, so maybe that's where the bug is

    Thursday, June 17, 2010 12:38 PM
  • Thanks for you reply.

    I have 2008 R2 server also... I guess 7 Enterprise vs. Ultimate shoud not be an issue...

    I found this link: http://blogs.technet.com/b/rrasblog/archive/2007/09/26/how-to-debug-sstp-specific-connection-failures.aspx

    and I am reading symptom6

    Did this setting worked for you without any problem? Was it simple to do?

    Thursday, June 17, 2010 4:19 PM
  • Based on the link you refenced, it sounds like you are trying to establish an RDP connection over an SSTP VPN.  I didn't realize that.  In our case there is no VPN involved.
    Thursday, June 17, 2010 4:36 PM
  • Ok, I actualy try to do both. RDP connection (using Remote App ou Remote Desktop) and also the SSTP VPN.

    Both present the same revocation list error. But to make it simple lets just consider the RDP for now (SSTP is next :) )

    The only way I have it working now was by importing the CRLs directly to my PC.

    Thursday, June 17, 2010 11:13 PM
  • Do you have your how CA or use a well known CA on the internet?
    Tuesday, June 22, 2010 11:50 AM
  • I use my own (Windows 2008 R2) CA.
    Wednesday, June 23, 2010 12:53 AM
  • Exactly like me...

    I exposed the crl on the internet. Are you doing the same? Are your RD clients inside the same LAN, or are they on the WAN?

    There must be somethig differente here that is obvious...

    I installed the Enterprise mode CA, exposed the CRL via HTTP but the only way to have this working is almost every day importing the crl manualy to local store.

    Saturday, June 26, 2010 2:54 PM
  • CRl is exposed on the Internet.  Some RD clients are inside the same LAN, some are on the Internet, some are connected via DirectAccess. 
    Saturday, June 26, 2010 4:28 PM
  • Ok. Thank you for your time helping me.

    I guess the next point to troubleshoot is the client side then.

    My W7 clients have the revocation issue. The Vista clients do not have the revocation issue...

    Could it be a RDP 7 bug as I have seen refered before?

    How is your client landscape? do you have W7 clients? or onely Vista?

    Monday, June 28, 2010 11:12 AM
  • We have no Vista clients.  The clients are a mixture of Windows 7 and Server 2008 R2.
    Monday, June 28, 2010 3:23 PM
  • Anyone? Any ideias?

    This is becoming an issue internaly whitin the company.

    Is this related with the "type" of certificate? (is there such a thing). My certificates have many DNS names...

    The only workaround I have is downloading the crl files (base and delta) from exactly the same URLs detailed on the certificate and import it manualy into the local computer keystore.

    This is impractical! There must be a way to troubleshoot this.

    If someone has any ideia ou trroubleshooting tool (utility, etc...) please write some lines in here.

    Microsoft, do you read this foruns? If yes, do you have some hints?

    Should I unistall AD's and CA's roles and redo everything?

    Thanks,

    Luis Cordeiro

    Wednesday, June 30, 2010 1:37 PM
  • Sejong, I noticed in one of your replies that although you use W7 the RDP version is actualy 6.1 and not 7. This could explain why it works for you and it does not work for me.

    You said:

       "I have been able to get a certificate-secured RDP connection working.  The RDP Client is version 6.1.7600"

    Can you confirm this? How did you make W7 use RDP 6.1?

    Microsfto, is this a bug on RDP 7? The truth is that my VISTA clients work fine...

    Wednesday, June 30, 2010 1:45 PM
  • I just checked a Windows 7 computer.  The Remote Desktop client (mstsc.exe) is version 6.1.7600.16385.  As far as I know, this is the version that came baked into Windows 7.

     

    Wednesday, June 30, 2010 4:33 PM
  • I must thank you for all your attention.

    I checked also and the exe version and I have 6.1.7600.16385.

    I guess I was mislead by the RDP 7.0 vs. RDP 6.1 remarks I found elsewere.

    The fact is that from VISTA all works fine but from W7 it does not.

    As a last oportunity I disabled crl dowloading on the CA root certificate that I imported into my computer keystore (it's a property on the certificate)

    If this does not work, I will downgrade for self-sign certificate until I found any other alternative or solution.

    I cannot ask the users to continue to donwload and import the crl manualy.

    Unfortunalty this issue is causing some disapointment on some users :( and I am not sure if it is my fault or a bug.

    You have this working and apparently we have similar settings... I do not know what to do more.

    Luis Cordeiro

     

    Wednesday, June 30, 2010 9:56 PM
  • Sejong, one additional question.

    What kind of certificate do you have on: Administrative Tools / Remote Desktop Session Host Configuration / RDP properties?

    Do yo have an auto-generated certificate?

     

     

    Thursday, July 01, 2010 1:48 PM
  • No.  The certificate is from my CA.
    Thursday, July 01, 2010 7:33 PM
  • I give up :)

    Just used a self-signed..

    Friday, July 02, 2010 10:21 AM
  • Me again :)

    Is your version 2008 R2 Standard? Or Enterprise?

    Do you have OCSP installed? (Online Responder Service)

    Friday, August 27, 2010 9:27 PM
  • Standard.

    No (don't have OCSP installed).

    Tuesday, August 31, 2010 8:03 PM
  • I've had a similar problem once with one client.

    The solution was to disable delta crl at all on CA and reissue certificates after that. The problem with iis 7 and "+" was solved but delta crl still wasn't available for clients for some reason. It looks more like a workaround but still it helped.

     

    Wednesday, September 08, 2010 6:46 AM
  • Hi Luis,

    Ive been reading this thread with great interest as I have exactly.. and I mean EXACTLY the same problem

    • Internal CA (Windows 2008 R2)
    • Remote App Server etc (Windows 2008 R2)
    • WAN Clients (Windows 7 Professional)
    • Using certificates issued from my Internal CA just like you.
    • I have the CA root cert installed on my external client (for Outlook Anywhere)
    • I have my CRL Distribution points available externally and published in the certs.
    • certutil -url mycert.cer brings up the GUI and finds the CRL's and verifys them
    • certutil -verify -urlfetch mycert.cer works and Leaf checking passes.

    However, I still get "A revocation check failed!"

    IF I use a self signed cert, it works! (But I dont want to do this!)

    I'm tempted to install Windows 7 Service Pack 1 Beta to see if that fixes things.

     

    Any news?

     

    Thanks

    Andy

    Thursday, September 16, 2010 2:13 PM
  • I doubt that installing Windows 7 SP1 Beta would make any difference.  I had this working without SP1 and with SP1.  Easy for me to say, I know.
    Thursday, September 16, 2010 2:25 PM
  • Andy, thank you for you reply.

    I am so "happy" I am not the only one having this issue. I am sure that something very obvious is happening, but finding what... maybe because this also affects you someone from MS takes a look at this forum :)

    I still have the issue. My theory is:

    1) this affects Win 7 clients

    2) Win 7 is trying to use OCSP, and W2008 R2 Standard does not have it.

    3) Win 7 does not query the crl links, thus it give back a revocation check failed.

    Nevertheless sejong has this working with Standard :( so the above points (my theory) has flaws :)

    I have no ideia why or what is happening. I was kind of expecting some day this suddendly becomes obvious

     

     

    Thursday, September 16, 2010 3:44 PM
  • I just verified that this works with Server 2008 R2 Enterprise (as well as Standard).  In this case both the Windows 7 Client and the Server 2008 R2 Enterprise Remote Desktop Session Host are running SP1 Beta, but as I said in an earlier post, I doubt that SP1 makes a difference here.
    Thursday, September 16, 2010 4:51 PM
  • I just verified that this works with Server 2008 R2 Enterprise (as well as Standard).  In this case both the Windows 7 Client and the Server 2008 R2 Enterprise Remote Desktop Session Host are running SP1 Beta, but as I said in an earlier post, I doubt that SP1 makes a difference here.


    Hi Guys

     

    Well I've installed SP1 Beta on my Windows 2008 R2 Std Remote App Test server and my Windows 7 client. My RDP client on my windows 7 pro machine is now 7.1 and the revocation issue has gone!!!

    Luis, I highly suggest you try SP1 beta on your Windows 7 client and report back as it fixed the issue for me!

    Cheers

    Andy

     

    Thursday, September 16, 2010 5:35 PM
  • I have this same problem as well.

    The problem occurs when: Client is Windows 7 or Windows 2008/2008R2 connecting to a 2008R2 Terminal server and the connecting client is NOT a member of the domain where the internal CA resides.

    I can connect without issue and don't receive the revocation error if I'm connecting from a system that is a member of the domain.

    Thursday, September 23, 2010 6:19 AM
  • I have this same problem as well.

    The problem occurs when: Client is Windows 7 or Windows 2008/2008R2 connecting to a 2008R2 Terminal server and the connecting client is NOT a member of the domain where the internal CA resides.

    I can connect without issue and don't receive the revocation error if I'm connecting from a system that is a member of the domain.


    Hi Louis

    Then our configs must be ever so slightly different.

    My Client is (was) Windows 7 Profressional x64 and connecting to a Windows 2008 R2 Enterprise X64 server for Remote App.

    My Client IS a member of the same domain/AD as the RD WebApp Server and I still got the revocation issue when using my internal CA (which is part of the same domain) certificates.

    I just took the client machine (laptop) externally, connected via 3G to prove the issue. The revocation issue was only removed after installed Windows 7 SP1 Beta on the Client (laptop)

    Very odd!

    Cheers

    Andy

     

    Thursday, September 23, 2010 7:36 AM
  • Hey Versus_2, I am having the same issue but not with RDC I am working on SSTP VPN using TMG

    I am getting the same error 0x80092013 So you Published CRLs:

    http://myserver.dyndns.org/CertEnroll/MY-SERVER-CA.crl & http://myserver.dyndns.org/CertEnroll/MY-SERVER-CA+.crl

    Then you published AIA as http://myserver.dyndns.org/CertEnroll/myserver.dyndns.org_MY-SERVER-CA.crt Then everything worked perfectly for you right?

    I published the AIA as mentioned above and CRLs of course but still getting the same error message. Did you have to install and publish OCSP? http://technet.microsoft.com/en-us/library/cc770413(WS.10).aspx Any tips will be appreciated.

     

    @Guys who applied Win7 SP1 so you think this is a windows 7 Bug?

    Thanks Black Spider

    • Edited by Black Spider Saturday, February 05, 2011 8:04 PM Formating and adding a few lines
    Saturday, February 05, 2011 7:43 PM
  • Updates:

    I have updated to Win7 SP1 but still have the same issue.

    Sunday, February 06, 2011 12:38 PM
  • Spider,

    Can you start a new thread with your issue.

    You need to provide more information.

    For example, take an issued certificate from the CA database and run certutil -verify -urlfetch certificate.crt and post the output

    This is not a bug, but simply a misconfiguration in your network.

    Brian

    Sunday, February 06, 2011 2:01 PM
  • Brian,

    I have created a new thread with more information about the case.
    http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/3c28feb6-6ff6-4917-bbbf-ef67ade068a5

    Could you please have a look and give me some feedbacks.

     

    Regards

    Black Spider


    MCP, MCSA 2000, MCSE 2000, MCSA 2003, MCSE 2003, MCSA Security 2000, MCSE Security 2000, MCSA Security 2003, MCSE Security 2003, MCTS, MCITP: Enterprise Administrator. "It isn't important to be better than others. It's important to be better than you were yesterday"
    Thursday, February 10, 2011 11:20 AM