In order to eliminate the error "A revocation check could not be performed for the certificate" which appears on the external W7 client when trying to use RemoteApp application via TS Web Access on 2008 server, I've tried to add new CRL Distribution point to a certificate issued by my local CA so it can be verified for revocation from outside. I've published the existing CDP on the ISA and CRL file is downloadable via http://myserver.dyndns.org/certenroll/MyServer.crl Also, I've looked at the existing 3 CDP entries in the extensions tab of the CA and by model of these 3 (ldap, ftp, http) I've added a new external URL. so on the basis of: http://<ServerDNSName>/Certenroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl I've added: http://myserver.dyndns.org/Certenroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl After reissuing the same certificate with this new CDP I keep getting the same error. After I checked the certificate manually with certutil command: certutil –verify –urlfetch MyServer.cer I can see that CRL is checked properly here: ---------------- Certificate CDP ---------------- Verified "Base CRL (22)" Time: 2 [2.0] http://myserver.dyndns.org/CertEnroll/MY-SERVER-CA.crl but no delta crl gets checked and process fails: Revocation check skipped -- server offline when running the same command from inside the process is complete: Leaf certificate revocation check passed and delta crl is also checked: ---------------- 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+.crland what is also interesting both outside urls are tried and fail obviously: 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 My question is why is it that delta crl is not checked from outside and is it a reason why process fails?Do i need to add anything else to the certificate for revocation check to work ie. publishing AIA also? Thanks

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-pathalso 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

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.crlwhile 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+.crland 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.1thanks

> 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.cerand 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

---------------- Certificate CDP ---------------- Verified "Base CRL (22)" Time: 2 [2.0] http://myserver.dyndns.org/CertEnroll/MY-SERVER-CA.crlBase 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 CDPFor retreive Certs (from AIA)I have no external urls for this extemsionfailures for internal URLS - type AIAFor retreive OCSPNo URLSSo both external CRLs are retrieved. What should i do next?

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.

so, here is 2 things that I want to explain.The first thing is that your problem is notwithCRL 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 onWindows 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-pathalso 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

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

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

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

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 threadgives more detail.http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/22915d39-5a53-4233-a307-1f07fc4e019e#67fecf0e-f2b9-477b-a11d-8efb8dd4dc1c

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:0authentication level:i:0We 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 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:0authentication level:i:0We 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.

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

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.

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..

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.

No, this has nothing at all to do with OCSP.Paul Adare CTO IdentIT Inc. ILM MVP

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...

> 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

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.

Hi, did you ever found a solution for this? I have the exact same problem!!!!

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?

Yes, did exactly that! Using the certutil I am able to fecth the CRLs normaly.

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.

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.

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

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

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?

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...

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!!!

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

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?

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.

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.

Do you have your how CA or use a well known CA on the internet?

I use my own (Windows 2008 R2) CA.

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.

CRl is exposed on the Internet. Some RD clients are inside the same LAN, some are on the Internet, some are connected via DirectAccess.

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?

We have no Vista clients. The clients are a mixture of Windows 7 and Server 2008 R2.

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

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...

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.

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

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?

No. The certificate is from my CA.

I give up :) Just used a self-signed..

Me again :) Is your version 2008 R2 Standard? Or Enterprise? Do you have OCSP installed? (Online Responder Service)

Standard. No (don't have OCSP installed).

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.

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

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.

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

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.

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

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.

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

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

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

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

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 SpiderMCP, 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"