Windows Server 2008 RDP-TCP Certificate keeps going back to Auto generated

rdpssl-certificatewindows-server-2008windows-terminal-services

Our servers undergo periodic PCI compliance scans and we have a Windows 2008 server machine that we have port 3389 open for RDP. It is secured with SSL, but it is failing the scan because their test says:

 SOLUTION:
 Please install a server certificate signed by a trusted third-party Certificate Authority.
 RESULT:
 Certificate #0 unable to get local issuer certificate

As far as I can tell, the reason its failing is because in the Terminal Services Configuration tool it is using a locally created certificate instead of the one we got from GeoTrust. So, I open the wizard and it says the certificate is "Auto Generated." I click the SELECT button, change to the one we were issued from GeoTrust and hit OK to save everything (screen shot). However, then I disconnect my RDP session and reconnect and its back to "Auto Generated." I've even tried deleting the certificate from the MMC Local Computer Certificate snap-in and it just keeps recreating itself every time we reconnect through RDP. I can "pass" the scan by going through those motions and re-running the scan before I log in again with RDP, but that's hardly a permanent solution as these scans run every month.

Can anyone help me figure out how to get the trusted CA SSL cert to stick around permanently?

Thanks in advance.

Best Answer

Well, unfortunately no one was able to help and it came time where I had to deal with it so I played with it a little bit more and ultimately found something that seems to work, so I'll post it here in case it helps someone else.

My remote connection was connecting directly to the IP address of my server instead of the name in the trusted SSL certificate. So, when I changed my remote connection settings to connect to the trusted name instead of the IP address it worked fine. My assumption is that when you connect directly to the IP address, the RDP-TCP manager looks for a certificate that matches and if it doesn't find one, then it defaults back to the auto-generated one (and if that doesn't exist, then it re-creates it). So, now when I set it to the 3rd party trusted certificate and then connect using the FQDN of that certificate, it stays put.

So, now the scan passes without any flags and I'm good to go.

Related Solutions

Ssl – How to fix RDP on windows server 2012

You may encounter this error when connecting after importing an SSL certificate (and associated private key) into Windows Server 2012:

This computer can't connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

In addition, in the Windows event logs, you see:

"A fatal error occurred when attempting to access the SSL server credential 
private key. The error code returned from the cryptographic module is 0x8009030D. 
The internal error state is 10001."

Solution:

Quote from Microsoft KB2001849:

"The Remote Desktop Host Services service runs under the NETWORK SERVICE account. Therefore, it is necessary to set the ACL of the key file used by RDS (referenced by the certificate named in the SSLCertificateSHA1Hash registry value) to include NETWORK SERVICE with "Read" permissions. To modify the permissions follow the steps below:

Open the Certificates snap-in for the local computer:

Click Start, click Run, type mmc, and click OK.
On the File menu, click Add/Remove Snap-in.
In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, click Certificates, and click Add.
In the Certificates snap-in dialog box, click Computer account, and click Next.
In the Select Computer dialog box, click Local computer: (the computer this console is running on), and click Finish.
In the Add or Remove Snap-ins dialog box, click OK.
In the Certificates snap-in, in the console tree, expand Certificates (Local Computer), expand Personal, and navigate to the SSL certificate that you would like to use.
Right-click the certificate, select All Tasks, and select Manage Private Keys.
In the Permissions dialog box, click Add, type NETWORK SERVICE, click OK, select Read under the Allow checkbox, then click OK."

Source: https://support.microsoft.com/en-us/kb/2001849

Understanding the output of openssl s_client

The answer (as explained in this security.SE post) is that the two GeoTrust Global CA certificate you see in the chain are in fact not the same certificate, one is derived from the other.

Because of CA Cross-signing!

When the GeoTrust Global CA certificate was first created and signed, no computer/browsers/applications would have had it in their trust store.

By having another CA (with a pre-existing reputation and distribution) sign the GeoTrust root CA cert, the resulting certificate (referred to as a "bridge" certificate) can now be verified by the second CA, without the GeoTrust root CA certificate having to be trusted by the client explicitly.

When Google presents the Cross-signed version of the GeoTrust root CA cert, a client that doesn't trust the original can just use the Equifax CA cert to verify GeoTrust - so Equifax acts as a kind of "legacy" trust anchor.

Best Answer

Related Solutions

Ssl – How to fix RDP on windows server 2012

Understanding the output of openssl s_client

Because of CA Cross-signing!

Related Topic