none
RDS SSL Certificate Issue RRS feed

  • Question

  • I recently purchased an SSL certificate through a 3rd party provider to use on our Windows Server 2008 R2 server. For computers outside of our company, it appears to work fine. When I try and connect to the server internally, I get the following error:

    "A revocation check could not be performed for the certificate".

    "You may not proceed due to the severity of the certificate error".

    I checked the certificate and it has a valid CRL Distribution Point, I was able to connect to it via the web browser on my Windows 7 workstation (the CDP, not the RDS server). The CA is also in Microsoft's list of trusted providers.

    Does anyone have any thoughts as to what my issue might be?

    Thanks!

    Don

    Friday, November 12, 2010 9:18 PM

Answers

  • Do you have any Enterprise Trust Group Policy Settings for your domain? It may  also be worth checking under "Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Path Validation Settings" group policy settings.

    As a temporary workaround you can either:

    Create the DWORD Value : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors
    and set it to 1. (For CredSSP Single Sign On)

    and/or create either of the following DWORD values and set them to 0 (for pure TLS).

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Terminal Server Client\CertChainRevocationCheck
    HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\CertChainRevocationCheck

     

    Monday, November 15, 2010 3:28 PM
  • Hi Don,

     

    Does this certificate locate in the “local computer” store at client side? If not, please import this certificate to the “local computer ” store by going through mmc.exe, then File | Add Snap-in | Certificates | Local Computer and importing the CA certificate to the Trusted Root Authorities area.

     

    Meanwhile, the certificates for RD Gateway must meet these requirements:

     

    ·     The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the RD Gateway server, unless you are using wildcard certificates or the SAN attributes of certificates. Multiple CNs are not supported. If your organization issues certificates from an enterprise certification authority (CA), a certificate template must be configured so that the appropriate name is supplied in the certificate request. If your organization issues certificates from a stand-alone CA, you do not need to do this.
    ·  
       The certificate is a computer certificate.
    · 
        The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
    ·   
     The certificate has a corresponding private key.
    ·  
       The certificate has not expired. We recommend that the certificate be valid one year from the date of installation.
    ·  
       A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if the certificate that you plan to use contains an OID of 2.5.29.15, you can only use the certificate if at least one of the following key usage values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE.
    ·    The certificate must be trusted on clients. That is, the public certificate of the CA that signed the RD Gateway server certificate must be located in the client's Trusted Root Certification Authorities store on the client computer.

     

    By the way, you can run the command line below to get a clue where things go wrong.

     

    certutil -f –urlfetch -verify <your_certificate>.cer

     

     

    Hope this helps.

    Tuesday, November 16, 2010 6:38 AM
    Moderator

All replies

  • Hello,

    You can start by checking the obtained certificate if it a correct certificate for usage with RDS. Please check:

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

     


    regards Robert Maijen
    Saturday, November 13, 2010 9:38 AM
  • Hi Dwboley,

    Is the certification authority certificate installed in the Trusted Root CA's store on all of the internal clients?

    Saturday, November 13, 2010 9:17 PM
  • Thank guys for your quick response.

    The certificate appears to be the correct type to use with RDS. The interesting part is that if the computer is a member of our Active Directory domain, it experiences the problem (only Windows 7 machines, not Windows XP). If the computer is on our network but not a member of the AD domain, it can connect.

    The CA certificate is installed on all of the client computers, I specifically verified it on the client system I am testing.

    Don

     

    Monday, November 15, 2010 1:45 PM
  • Hello,

    Like O'C suggested.. is the certificate in the correct store?


    regards Robert Maijen
    Monday, November 15, 2010 2:20 PM
  • Yes, the CA certificate is installed in the "Trusted Root Certification Authority" store on the internal clients.

    Thanks,

    Don

    Monday, November 15, 2010 2:28 PM
  • Do you have any Enterprise Trust Group Policy Settings for your domain? It may  also be worth checking under "Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Path Validation Settings" group policy settings.

    As a temporary workaround you can either:

    Create the DWORD Value : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors
    and set it to 1. (For CredSSP Single Sign On)

    and/or create either of the following DWORD values and set them to 0 (for pure TLS).

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Terminal Server Client\CertChainRevocationCheck
    HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\CertChainRevocationCheck

     

    Monday, November 15, 2010 3:28 PM
  • Hi Don,

     

    Does this certificate locate in the “local computer” store at client side? If not, please import this certificate to the “local computer ” store by going through mmc.exe, then File | Add Snap-in | Certificates | Local Computer and importing the CA certificate to the Trusted Root Authorities area.

     

    Meanwhile, the certificates for RD Gateway must meet these requirements:

     

    ·     The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the RD Gateway server, unless you are using wildcard certificates or the SAN attributes of certificates. Multiple CNs are not supported. If your organization issues certificates from an enterprise certification authority (CA), a certificate template must be configured so that the appropriate name is supplied in the certificate request. If your organization issues certificates from a stand-alone CA, you do not need to do this.
    ·  
       The certificate is a computer certificate.
    · 
        The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
    ·   
     The certificate has a corresponding private key.
    ·  
       The certificate has not expired. We recommend that the certificate be valid one year from the date of installation.
    ·  
       A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if the certificate that you plan to use contains an OID of 2.5.29.15, you can only use the certificate if at least one of the following key usage values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE.
    ·    The certificate must be trusted on clients. That is, the public certificate of the CA that signed the RD Gateway server certificate must be located in the client's Trusted Root Certification Authorities store on the client computer.

     

    By the way, you can run the command line below to get a clue where things go wrong.

     

    certutil -f –urlfetch -verify <your_certificate>.cer

     

     

    Hope this helps.

    Tuesday, November 16, 2010 6:38 AM
    Moderator
  • HackedOffAdmin, I tested the following temporary workaround and it worked on my test system, thank you.

    Create the DWORD Value : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors
    and set it to 1. (For CredSSP Single Sign On)

    Adding the following 2 lines to the RDP file also worked for in a test I was doing, providing it here as an FYI (this was found in a different post in the TechNet forums):

    enablecredsspsupport:i:0
    authentication level:i:0

    Alan, the certificate was not installed on the client. I guess I thought that this step was not necessary since the CA (Go Daddy Class 2 Certification Authority) was listed there, which is the issuing CA. I did not need the certificate installed on non-domain member computers. To test, I did install it on my client and that did not help.

    Here are my thoughts on your other points:

    ·     The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the RD Gateway server, unless you are using wildcard certificates or the SAN attributes of certificates. Multiple CNs are not supported. If your organization issues certificates from an enterprise certification authority (CA), a certificate template must be configured so that the appropriate name is supplied in the certificate request. If your organization issues certificates from a stand-alone CA, you do not need to do this.  The subject line matches the DNS name in the format rdsserver.mydomain.com.
    ·  
       The certificate is a computer certificate. The certificate should be a server certificate. It has a subject type of "End Entity" if that matters.
    · 
        The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1). The "Enhanced Key Usage" section has the following:

    Server Authentication (1.3.6.1.5.5.7.3.1)
    Client Authentication (1.3.6.1.5.5.7.3.2)

    ·   
     The certificate has a corresponding private key. I am not sure where I would find that.
    ·  
       The certificate has not expired. We recommend that the certificate be valid one year from the date of installation. The certificate is valid until 11/12/2011.
    ·  
       A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if the certificate that you plan to use contains an OID of 2.5.29.15, you can only use the certificate if at least one of the following key usage values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE. I do not see a OID listed in the certificate.
    ·    The certificate must be trusted on clients. That is, the public certificate of the CA that signed the RD Gateway server certificate must be located in the client's Trusted Root Certification Authorities store on the client computer. The certificate was issues by "Go Daddy Secure Certification Authority", which is in the client's Intermediate Certification Authority, not the Trusted Root Certification Authority. In the Trusted Root Certification Authority, the CA "Go Daddy Class 2 Certification Authority" is listed, which is the issuing CA for the subordinate CA that issued my certificate.

    I hope this information helps. Thank you again for your assistance here guys!

    Don

    Tuesday, November 16, 2010 1:45 PM
  • Two points:

    The fact that your non-win7 and non-domained joined machines (I am assuming some of these are windows 7???) can connect fine and the details you have provided rule out any issues with the certificate.

    The fact that you are using a third party cert also suggests that its root is in the correct store (normal root authority).

    (try reading his posts people)

    The issue only appears to manifest on Windows7 PC and only when part of the Domain. Yes?

    Try Alan Zhu's test of running "certutil -f –urlfetch -verify <your_certificate>.cer" on working and non-working PCs, but my feeling is you have some domain wide group policy affecting certificate CRL checking/enterprise trust. Try having a look in group policy (or googling - there are a few MSDN/technet articles on this) the givaway is that only Windows7 or 2008 R2 honours these group policy settings.

    Tuesday, November 16, 2010 2:00 PM
  • You are correct, the issue only happens on Windows 7 computers that are members of our AD domain. Windows XP machines do not have this problem, and I have not tested Windows Vista systems (but could easily if we thought it would provide any insight). I have tried this on non-domain Windows XP and Windows 7 systems and have not seen the problem.

    I went ahead and ran the certutil command as specified in Alan's post and everything looks good, it appeared to see the CRL and I don't see any errors in it. I tested this on a domain member system as well and all looked good. I have to admit, I don't know what a failure would look like in the output, but I didn't see anything that looked like a fail.

    One thing I have been suspicious of (and you mentioned it here Hack), we are running AD 2003, we have not yet upgraded to AD 2008/2008R2. Therefore, we shouldn't have any GP settings that effect Windows 7 or 2008 R2 only. We have an upgrade planned for early to mid 2011, and I was curious if that might just fix the problem?

    Thanks again!

    Don

    Tuesday, November 16, 2010 2:53 PM
  • No idea, Microsoft's OCSP implimentation seems a bit flaky though. Do you have a Certificate Server in your AD domain? My advise, try running a packet capture on the machine and see if it issues any certificate revocation check traffic - if it does make sure its going to the correct place. You could try moveing the GoDaddy intermediate cert to the trusted root under the Local Computer (not user - the default i.e. don't use certmgr.msc) certificate snap-in but this is starting be cluching at straws....
    Tuesday, November 16, 2010 3:25 PM
  • I think at this point I will hold off getting into that level of diagnostics, we have some pretty descent work arounds until we get AD upgraded (as well as our 2003 internal CA) to see if the problem persists. Of course, if it does, I will get a packet capture going on the system and see.

    I thank you again for your help, as well as everyone else who provided thoughts and ideas here.

    Thanks!

    Don

    Tuesday, November 16, 2010 3:28 PM
  • I have the opposite problem and the registry keys fixed my issue.

     

    Thanks HackedOffAdmin!

    Wednesday, April 20, 2011 9:58 PM
  • Just a brief FYI... I had a similar issue.

    If connecting through the RD Gateway from an outside system I recieved the error above. I could use the same laptop on the inside of my network and connect using the rdp client to the farm. We were using an externally issued certificate.  Our RD gateway server and RD Host servers were on the same DMZ vlan and did not themselves have internet access.  Turned out that the RD Gateway server was the one actually having the problem downloading the CRL when it was attempting to proxy the connections. I used the regkey DWORD Value : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors and set it to 1. Now it is a happier environment. So it appears that if you are seeing this error it may not be the client that can't do a CRL check but is instead your gateway server that can't check the CRL, that is just my observation so do your own testing.

    Thanks all for pointing me in the right direction.

     

    Tuesday, May 17, 2011 9:14 PM
  • Try updating Windows 7 to SP1.

    Friday, June 10, 2011 11:13 AM
  • I also found a bug between Active Directory and RDP+SSL.   If one adds computers to the "Log on To" option in a user's AD account to restrict what PC to log into,  RDP+SSL gives a Certificate Revocation error.  "Log on To" claims to also now do DNS but only if the entry is maximum 15 characters long through the GUI.  I also tried editing the "userWorkstations" AD attribute directly trying different combinations including the farm name DNS to no avail.  Leaving "Log on To" empty, RDP+SSL gives no errors.
    Sunday, June 26, 2011 8:27 PM