Hello, in several networks (several separate customers) I have this weird behaviour. I have created a new Remote Desktop Authentication certificate (1.3.6.1.4.1.311.54.1.2) and assigned it through the GPO policy "Server Authentication Certificate Template" to my RDP servers to be obtained automatically. Thre problem I face is that each time any Remote Desktop Configuration or Terminal Services Configuration service restarts, it enrolls for a new certificate of the same template. Every time I receve a successfull event about it happened (1064, Information, TerminalServices-RemoteConnectionManager): A new template-based certificate to be used by the terminal server for Transport Layer Security (TLS) 1.0\Secure Sockets Layer (SSL) authentication and encryption has been installed. The name for this certificate is Alfa.xxx.local. The SHA1 hash of the certificate is provided in the event data. The certificate is normally assigned to RDP and everything works fine except the next restart of the server/service, another certificate is pulled. No error messages apear, everything looks to be in order. This happens on both 2008 and 2008 R2 boxes. The template is version 2003 or 2008 (either tested). The template can be exportable or non-exportable (both types tested without effect). It also does not depend on what Subject field contains. There is also no difference to the behavior whether the servers are allowed to Autoenroll in addition to the Enroll permission or not. The behavior also does not depend on the expiration of the certificates (I have tested 2 years, 1 year, 6 months). The authority is SHA1, issues SHA1 certificates. It looks just like the computers on the next restart just cannot find a suitable certificate and enroll again. How could I stop the clients enroll for the certificate every time of their restart? thank you. ondrej.

... another symptom is, that the RDP server that enrolls for the Remote Desktop Certificate also generates automatically its own self-signed certificate into the Remote Desktop/Certificates store (if non is there or has been deleted manually). Although the previously mentioned event shows a correct certificate hash of the enrolled certificate and the RDP server really uses the enrolled certificate, there is the autogenerated cert created as well while not used. ondrej.

Hi, To better understand the issue, please help collect the following information on the RDP server: Please run certutil -store -v my "serial of the SSL certificate" > cert.txt. Please run certutil -template -v "TemplateName of the SSL certificate template" > template.txt. Please export all certificate events from Event Viewer. You can upload the information to the following space: https://sftasia.one.microsoft.com/choosetransfer.aspx?key=506ec2c7-b359-40ba-803c-6dc9f29011ea Password: U^y6ME^7BwA Thanks.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

you got it. Although the certificate does not contain CDP now, it is no difference if I include CDP which is valid, as verified by CERTUTIL -verify. ondrej.

Hi, Thanks for the information. I've checked the files and the setting looks correct. I performed a test and can reproduce the behavior in my environment. I've submitted it to related team for further investigation and will post back if I get any update. Thanks.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

awsome! thank you! ondrej.

I believe this problem is related to the template display name compared to template name. When you name a certificate make sure that the template name and template display name are identical. No spaces are allowed in the template name so having spaces in the template display name causes this issue you are experiencing. Please see the following references specifically step 5. There are also some comments relating to this issue on the second page of comments. http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx?PageIndex=2

hi, looks reasonably. the client is probably not able to find the template by using its display name in the store while is not able to enroll for it if the system name is defined in the policy. so the use of same names could make it work on both sides. anyway, this seems to me as a bug that needs mending. ondrej.

Client don't use Display Name to find certain template. Instead, OID or canonical name is used. In this case CN is used. http://en-us.sysadmins.lv PowerShell PKI module: http://pspki.codeplex.com/

sure, but as GPO specifies the display name of the template, the client first needs to lookup the OID for the template and this is probably where the problem starts. o.

Can you point to exact sentence where is talked about display name? I'm looking to corresponding GPO entry and see "template name". Template name is not the same as template display name. Why common name? This is because template OID is suited with template common name. To check this run the following command in Windows PowerShell: [Security.Cryptography.Oid]"TemplateCommonName" in the output you will see template OID. Display name is used to display user-friendly text and never used in internal operations. http://en-us.sysadmins.lv PowerShell PKI module: http://pspki.codeplex.com/

no, I am talking about Remote Desktop Services and its GPO settings to specify "Server Authentication Template". The setting requires you to specify a template display name. If you tried the cn of the template, the Remote Desktop SErvices Configuration service wouldn't be able to enroll for the certificate. So you go for display name in the RDP setting. The problem happens probably later when the RDP Configuration service at its next restart tries to find an existing certificate that would have been issued from the template. At this point, it seems like the service is trying to use the previously configured DISPLAY name but now interprets it as CN of the template. The incorrect behaviour would produce the results as I have observed in several networks. And would also enable you to overcome the problem by configuring the template to have same Display name and CN. ondrej.

Can you provide exact string in this setting? Ok I have simple template name (RDP-TLS) which has the same display and common name and haven't expereinced this issue. But in any way my thought is that you need to specify template common name since there is no mention about display name.http://en-us.sysadmins.lv PowerShell PKI module: http://pspki.codeplex.com/

cool, go and change the template names to something different. such as RDP TLS (with a space) and CN=RDPTLS. Then try GPO with either name and restart the RD Configuration (SessionEnv) service several times. When you specify the CN in the policy, you will not receive any certificate as the SessionEnv cannot enroll for then nonexisting template. When you try to configure the display namy, although the SessionEnv is able to enroll, it enrolls on each restart. when you change the templates, be sure to delete the template cache in hklm\software\microsoft\cryptography\certificatetemplatecache or I suggest creating a brand new template for the test. ondrej.

can you tell which name you have used in GPO? Display name or CN?http://en-us.sysadmins.lv PowerShell PKI module: http://pspki.codeplex.com/