A revocation check could not be performed for the certificate
Hi guys, (I was advised to cross post this from http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/e3b8e10a-4635-4d8b-80c0-e73b01bcd081, any help you guys can offer would be apprecaited!) I've read through all the other threads on this issue but they're all slightly different to my issue, hopefully somebody can help me out as I'm stumped now! I've got a single Windows 2008 R2 Remote Desktop Services server setup with a standard single subject name Thawte SSL123 signed cert. I've installed the cert on the RDS server, including the intermediate cert and root CA cert. Most PCs can connect to the RDS server no problem, however a number of Windows 7 (strangely all Home edition so far) are getting the error "A revocation check could not be performed for the certificate." when they try to connect and are therefore not allowed to connect. On some Windows XP machines users get "The connection has been terminated because an unexpected server authentication certificate was received from the remote computer.". I have tested both from computers on the domain and off the domain, and from inside the network and outside the network with similar random results. The users who will be eventually using the RDS server will be outside the network on non-domain machines so deploying certs or CRLs to each of them is not an option. I read in another thread that I should export the cert to a .CER file, copy it to a PC and run certutil -f -verify -urlfetch against the file, below is the output from this command. Note it is the same on both a PC that can and a PC that cannot connect to the RDS server. I suspect the output is "normal" given that the .CER file will not contain the intermediate certs, whereas when a PC connects to the RDS server it should be handing the connecting PC the whole chain. Note that I tried browsing to the CDP and was able to download the CRL no problem, when I browsed to the OCSP I was able to download a file though it seemed to just contain a few characters (I guess this is normal). Issuer: CN=Thawte DV SSL CA OU=Domain Validated SSL O=Thawte, Inc. C=US Subject: CN=rds.mydomain.tld OU=Domain Validated OU=Thawte SSL123 certificate OU=Go to https://www.thawte.com/repository/index.html O=rds.mydomain.tld Cert Serial Number: 542f62f602b33310c79de678d8be9bfe dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1) dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2) dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8) dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000) dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000) ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000) HCCE_LOCAL_MACHINE CERT_CHAIN_POLICY_BASE -------- CERT_CHAIN_CONTEXT -------- ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40) ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000) ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000) SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40) SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000) SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000) CertContext[0][0]: dwInfoStatus=4 dwErrorStatus=1000040 Issuer: CN=Thawte DV SSL CA, OU=Domain Validated SSL, O="Thawte, Inc.", C=US NotBefore: 23/03/2012 01:00 NotAfter: 24/03/2015 00:59 Subject: CN=rds.mydomain.tld, OU=Domain Validated, OU=Thawte SSL123 certificate, OU=Go to https://www.thawte.com/repository/index.html, O=rds.mydomain.tld Serial: 542f62f602b33310c79de678d8be9bfe 7d 84 19 b4 63 c7 40 06 67 b8 7c 01 ea 47 d3 8f 6b 2d 39 db Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40) Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- OK "Base CRL (05cb)" Time: 1 [0.0] http://svr-dv-crl.thawte.com/ThawteDV.crl ---------------- Certificate OCSP ---------------- Unsuccessful "OCSP" Time: 0 [0.0] http://ocsp.thawte.com -------------------------------- Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication Exclude leaf cert: da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09 Full chain: 7d 84 19 b4 63 c7 40 06 67 b8 7c 01 ea 47 d3 8f 6b 2d 39 db Missing Issuer: CN=Thawte DV SSL CA, OU=Domain Validated SSL, O="Thawte, Inc.", C=US Issuer: CN=Thawte DV SSL CA, OU=Domain Validated SSL, O="Thawte, Inc.", C=US NotBefore: 23/03/2012 01:00 NotAfter: 24/03/2015 00:59 Subject: CN=rds.mydomain.tld, OU=Domain Validated, OU=Thawte SSL123 certificate, OU=Go to https://www.thawte.com/repository/index.html, O=rds.mydomain.tld Serial: 542f62f602b33310c79de678d8be9bfe 7d 84 19 b4 63 c7 40 06 67 b8 7c 01 ea 47 d3 8f 6b 2d 39 db A certificate chain could not be built to a trusted root authority. 0x800b010a (-2146762486) ------------------------------------ Incomplete certificate chain Cannot find certificate: CN=Thawte DV SSL CA, OU=Domain Validated SSL, O="Thawte, Inc.", C=US Cert is an End Entity certificate ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because 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. Below is the output of the same certutil command against the same .CER file from the RDS server itself - Issuer: CN=Thawte DV SSL CA OU=Domain Validated SSL O=Thawte, Inc. C=US Subject: CN=rds.mydomain.tld OU=Domain Validated OU=Thawte SSL123 certificate OU=Go to https://www.thawte.com/repository/index.html O=rds.mydomain.tld Cert Serial Number: 542f62f602b33310c79de678d8be9bfe dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1) dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2) dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8) dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000) dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000) ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000) HCCE_LOCAL_MACHINE CERT_CHAIN_POLICY_BASE -------- CERT_CHAIN_CONTEXT -------- ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) CertContext[0][0]: dwInfoStatus=104 dwErrorStatus=0 Issuer: CN=Thawte DV SSL CA, OU=Domain Validated SSL, O="Thawte, Inc.", C=US NotBefore: 23/03/2012 01:00 NotAfter: 24/03/2015 00:59 Subject: CN=rds.mydomain.tld, OU=Domain Validated, OU=Thawte SSL123 certificate, OU=Go to https://www.thawte.com/repository/index.html, O=rds.mydomain.tld Serial: 542f62f602b33310c79de678d8be9bfe 7d 84 19 b4 63 c7 40 06 67 b8 7c 01 ea 47 d3 8f 6b 2d 39 db Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- Verified "Base CRL (05cc)" Time: 6 [0.0] http://svr-dv-crl.thawte.com/ThawteDV.crl ---------------- Base CRL CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- Verified "OCSP" Time: 4 [0.0] http://ocsp.thawte.com -------------------------------- CRL (null): Issuer: CN=Thawte DV SSL OCSP Responder, O="Thawte, Inc.", C=US 74 d7 94 14 9e 5d 70 88 bb 36 4e 69 8e da b7 20 3e 9e 44 a9 Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US NotBefore: 18/02/2010 01:00 NotAfter: 18/02/2020 00:59 Subject: CN=Thawte DV SSL CA, OU=Domain Validated SSL, O="Thawte, Inc.", C=US Serial: 7610128a17b682bb3a1f9d1a9a35c092 SubjectAltName: Directory Address:CN=VeriSignMPKI-2-11 3c a9 58 f3 e7 d6 83 7e 1c 1a cf 8b 0f 6a 2e 6d 48 7d 67 62 Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- Verified "Base CRL" Time: 4 [0.0] http://crl.thawte.com/ThawtePCA.crl ---------------- Base CRL CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- Verified "OCSP" Time: 4 [0.0] http://ocsp.thawte.com -------------------------------- CRL (null): Issuer: CN=thawte Primary Root OCSP Responder, O="thawte, Inc.", C=US 50 24 98 8d d6 ab db e5 77 2b 40 3f 89 d5 eb d9 f9 c5 6c f9 Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication Application[2] = 1.3.6.1.5.5.7.3.4 Secure Email Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US NotBefore: 17/11/2006 01:00 NotAfter: 17/07/2036 00:59 Subject: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US Serial: 344ed55720d5edec49f42fce37db2b6d 91 c6 d6 ee 3e 8a c8 63 84 e5 48 c2 99 29 5c 75 6c 81 7b 81 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 -------------------------------- Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication Application[2] = 1.3.6.1.5.5.7.3.4 Secure Email Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing Exclude leaf cert: 7d ff 3c 13 7a 2e 83 00 81 ae 1e c6 bf cc b1 25 1c e8 30 4c Full chain: 8f 82 94 3b e4 8d db 06 9d 9a e4 d8 8a 5d b1 a1 e1 a4 fd 41 ------------------------------------ Verified Issuance Policies: None Verified Application Policies: 1.3.6.1.5.5.7.3.1 Server Authentication 1.3.6.1.5.5.7.3.2 Client Authentication Cert is an End Entity certificate Leaf certificate revocation check passed CertUtil: -verify command completed successfully. Any help would be much appreciated!
May 24th, 2012 10:41am

you must install Thawte intermediate CA certificate (I think it is Thawte SSL CA) to all clients (install in computer store).My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki
Free Windows Admin Tool Kit Click here and download it now
May 24th, 2012 11:13am

Can you clarify that a bit further Vadims please, is this somethign specific to RDP? Installing the Thawte Intermediate certificate does sort out the problem, but the RDS server should be sending the client the intermediate cert during the SSL handshake, and it appears to be doing this for "most" clients as I am able to connect no problem from my own Windows 7 Pro PC which does not have the intermediate certificate installed. I also regularly use these SSL certs on web servers and never have to install the intermediate cert on client devices, it always goes on the server only which supplies it to the client.
May 24th, 2012 11:17am

> Installing the Thawte Intermediate certificate does sort out the problem, but the RDS server should be sending the client the intermediate cert during the SSL handshake It is incorrect assumption. RDP sends only leaf certificate. Also, intermediate certificate might be installed in cache (during web browsing) and certain machines will accepth your SSL certificate. > I also regularly use these SSL certs on web servers and never have to install the intermediate cert on client devices, it always goes on the server only which supplies it to the client. yes, IIS sends full certificate chain to the client. But RDP/SSTP not.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki
Free Windows Admin Tool Kit Click here and download it now
May 24th, 2012 11:30am

"IIS sends full certificate chain to the client. But RDP/SSTP not." Ahhhhh, that's a bit of information I wasn't aware of, thank you! Surely this is a serious deficiency in the implementation of RDS, one might even call it a bug as the message from the client is very misleading. Are there any Microsoft articles on the subject so I can read up on it a bit more and confirm the information? Not that I doubt you, but this is the Internet at the end of the day :). So given that the end-user machines are going to belong to other companies, and most will be locked down to prevent users adding the certificates to the computer store I'm guessing my only option is to use a self-signed cert (which annoying the RDP client will accept!!) or to try and get a cert from a trusted root CA that does not contain intermediate certs? Thanks!
May 24th, 2012 11:43am

you can check my blog article: http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=40 you can use either self-signed (though, it MUST be installed on client machines too) or use different SSL cert provider who do not hides their intermediate CAs. Everything you can find in my blog post.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki
Free Windows Admin Tool Kit Click here and download it now
May 24th, 2012 11:49am

Hi Vadims, Excellent blog post and indeed that does answer the questions, I'll contact Thawte and see what happens. Just to say that a self-signed cert will actually work without being installed on the client computers. They will get a pop-up to say the cert is not trusted but they can continue past this and connect, so an SSL encrypted RDP session happens. Wherease the revocation error above blocks the user from connecting at all. To be clear though this is a cert self-signed by the RDS server itself, so it is treated as a CA cert by the RDP client, and as no CRL checking is done on CA certs the user can connect. I suspect if you had an internal CA and used this to sign a cert that was used on the RDS server then you'd be back to having CRL lookup issues and no connectivity. Do you know if this has ever been logged as a bug/feature request with Microsoft or where I might go to do it? I've wasted a considerable amount of time trying to troubleshoot this issue due to misleading warnings from the RDP client and unexpected behaviour of the RDS server in only sending leaf certs when IIS and other MS products send the full chain. Leave it with me and I'll reply if I come up with anything useful, thanks VERY much for your help!
May 24th, 2012 11:58am

I just found this on the Thawte site which I'll gvie a try - [RDP connection fails with invalid chained when intermediates certificates are used with Microsoft Windows 7 and Windows 2008] - https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO15919&actp=search&viewlocale=en_US&searchid=1337885897799
Free Windows Admin Tool Kit Click here and download it now
May 24th, 2012 12:03pm

I just found this on the Thawte site which I'll gvie a try - [RDP connection fails with invalid chained when intermediates certificates are used with Microsoft Windows 7 and Windows 2008] - https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO15919&actp=search&viewlocale=en_US&searchid=1337885897799
May 24th, 2012 12:10pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics