Server 2008 TS Web Access SSL Revocation Error

Some time back I set up a 2008 terminal services solution with web access enabled. I have used SSL certificates for both the gateway and the terminal service applications and it all works fine when using Windows XP as the client.

Windows 7 however refuses to work full stop, complaining that 'A revocation check could not be performed for the certificate'. None of the certificates in use are self signed. I have done a bit of reading on the matter and from what I can gather Server 2008 TS requires OCSP to check that the certificate is valid. I recently learned the certificate in use didn't support OCSP and so I have just in the last 24 hours applied a new certificate that does (validated using certutil) thinking the problem would be resolved, sadly not.

The error returned is seen either internally or externally, and I have checked that the firewalls are allowing the traffic through (again using certutil). Really at a loss now, hopefully someone can help! Finally the same error occurs if I attempt to RDP directly to the server.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ParanormasticCryptographic EngineerCommented:
Try reviewing this post and we'll go from there:
ShrColAuthor Commented:
Thanks for that, I have seen this post before. Thats what lead me to change the certificate in use to a new one that contained the OCSP details in the AIA section. The key length is only 1024 so I cant see that being an issue and I have made manual connections to the CRL and OCSP addresses to verify its not a firewall problem. Just re-checked the certificate using certutil and all checks come back verified.
ShrColAuthor Commented:
Can anyone confirm that it is the client that does the revocation check?
Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

ParanormasticCryptographic EngineerCommented:
Yes, the client needs to validate that the server certificate is valid.

If you are doing client authentication from the server side, then the server would be validating that the client certificate is valid.

The "trusting party" (the one validating the cert of the "trusted party" or "end entity") will be the one doing the revocation check.

1024 or 2048 bit should be fine, as far as I'm aware there isn't a 2048 requirement.

I'm assuming that you did the certutil check on one of the workstations that is having problems getting in, not directly on the TS or CA, right?  If not please check from the client side to make sure that the client can talk to the OCSP server too.
ShrColAuthor Commented:
The checks with certutil have been completed on the TS and on my client machine, seem fine on both. Has TS or RDS (as I think its now known) changed much (other than the name) going forward into 2008 R2?
ParanormasticCryptographic EngineerCommented:
They overhaul RDP/TS about every 2 years it seems like to me.

Did you validate the OCSP using certutil -url filename.crt and select the OCSP button?
ShrColAuthor Commented:
Yes, thats how I have been testing it.
ParanormasticCryptographic EngineerCommented:
Is it possible your root cert may have ended up in the user's root store instead of the local machine root store, or somewhere else?  Confirm that each of your root CA certificate shows up if you run this:
certutil -store root

If you have multiple tiered PKI with a subordinate CA, it may be that this is not being served back from the RDP server, so the client may need to check this locally as well as the root.
certutil -store ca

If this is a problem, you can get the CA cert file and install to the appropriate location using certutil -addstore root   (or 'ca' instead of 'root' for the subordinate certs).
ShrColAuthor Commented:
I think possibly part of the issue here is my ignorance about how SSL hierarchy works. I have taken a look at the root and ca stores and added what I believe to be intermediate certificates, although I am not 100% sure on either. I presume there are no client RDP logs that may help here? Still no better I'm afraid.
ParanormasticCryptographic EngineerCommented:
Root CA
  -- Subordinate (Intermediate) CA
     -- (Sometimes another tier of subordinate CA)
        -- Web Server cert

Since the client normally only has the root cert in its store, it does not know about the rest.  For some weird reason, instead of hitting up the URL in the AIA portion of the cert that points to the repository for the CA certs, the client will often retreive the rest of the CA chain (the sub CAs) from the web server.  This means the web server needs to have the entire root chain installed in order to serve it up.  Alternatively, the client could install the rest of the chain too, but it is easier to centralize this on the web server.

With MS cert stores, there are a few groupings of each kind.  The primary containers are User, Local Computer, and Enterprise.  Within each are the more well-known secondary containers, such as Personal (My), Trusted Root (Root), Intermediates (CA), and a number of others.  That means that there are 3 trusted roots, 3 personal stores, etc. on each computer.

certutil -store Root will point to the Local Computer context
certutil -user -store Root will point to the User context
certutil -enterprise -store Root will point to the Enterprise context

The commands from my last post should help you look in the correct areas.  If you do not see the desired certs, then you can use certutil -addstore Root filename.cer to add the cert to that location, or deploy via GPO if you are able.
ShrColAuthor Commented:
Thanks for that, its clarified the concept a great deal. I have discovered that machines (W7) that have never been attached to our domain work fine. I know they never used to (same issue as domain machines), however I recently updated the certificate in use on the server to attempt to resolve this problem. The new one has clearly made a difference, it supports OCSP where the old one didn't.

To prove this wasn't an oddity on one machine I have rebuilt another and it also works. This good news as really this whole system is only for home (non domain) users. I would still like to get it working internally however. I have been through and checked that the certificates are installed correctly as per your last two posts - they seem to be both on my local machine and on the TS. We do have two internal CA's - could these be causing a problem somehow?
ParanormasticCryptographic EngineerCommented:
Seems to me then that this is somehow related to Group Policy - now the question is how.  It could be either default domain behavior or relating to a specific GPO.

Are the domain clients able to download from the URL specified for the OCSP?

Is there a GPO in effect that mandates a different URL for OCSP?  If not, maybe you could try one.  You could also try changing the default behavior from OCSP to CRL and see if that helps any - if nothing else for testing purposes.

Windows firewall settings - is RDP opened up for allowing traffic out from the client?

Here is some more info on 2008 R2 - RDP is now "RDS" - looks like it did get a bit of a facelift.  Here's some details and links to download the new client packages:

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ParanormasticCryptographic EngineerCommented:
Other articles that may be of interest to you, generically:
(Note: see sections 3.1.1 or 3.2.1 (depending on your network) for firewall port number descriptions)
ShrColAuthor Commented:
Thanks for the resources, makes some interesting reading. Unfortunately our domain is 2003 and so some of the certification polices do not exist. We are planning to upgrade it soon and at that point we will gain access to these additional policy settings.

I have checked an existing machines RSoP and it doesn't show any settings relating to certificates. Perhaps that's part of the problem, running Windows 7 clients with an older domain. Manually specifying a URL for OCSP or forcing CRL usage both sound promising options but not possible at present.
ParanormasticCryptographic EngineerCommented:
I'm not the best guy for GPO stuff, but I think you can get GPO update add-ons for newer OS / IE that make newer settings available for older domains with newer clients.

Did a little digging - looks like you can use a 2008 R2 or a Win7 domain client as a GPO management station to gain access to the newer settings.

ShrColAuthor Commented:
Thanks for that, looks like an option. I will have a look when I get a moment and let you know.
ParanormasticCryptographic EngineerCommented:
Any luck?
ShrColAuthor Commented:
Still not managed to get this resolved. A lot has changed since I asked the question, not least the fact that we are now running a 2008 R2 domain. I will work back through the suggestions when I get time. I am sure the answer lies in setting the OCSP manually.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.