In a previous blog on Object Identifiers (OID) in PKI, I mentioned creating a certificate template for Remote Desktop Connection (RDP). In this blog, I will show how to create the template, why the OID and extensions are important, and how to implement it and remove self-signed certificate warnings from RDP connections.
Expand Your PKI Visibility
Discover why seeing is securing with revolutionary PKI monitoring and alerting.
Prior to Windows Server 2012, a bug existed where using the template Display Name in the GPO (below), would trigger an enrollment, however the policy would not honor it. At each subsequent GPO refresh the process was repeated resulting in huge numbers of RDP certificates being issued. Pay close attention to this if there are server OS(s) below Windows Server 2012 in your environment and use template name or OID when specifying the RDP template. A best practice I always follow is no spaces in template names and setting template name and template display name to match when possible.
Why Issue RDP Certificates?
There are multiple reasons to issue RDP certificates from a PKI. The most noticeable is the warning displayed when making an RDP connection to a server or client. Upon the first RDP connection, servers and clients generate a self-signed certificate, which are not trusted so the warning is displayed.
The identity of the remote computer cannot be verified. Do you want to connect anyway?
Clicking Yes, to connect sets a bad precedent, especially when checking the box to not be notified again. In servers and clients prior to Windows 8.1 and Server 2012R2, the self-signed certificates were issued based on a SHA1, until an update when they started issuing SHA2 based self-signed.
After following these steps, clients and servers the GPO is
applied to will no longer generate the self-signed certificates and will use
the trusted certificate issued from your PKI to secure the connection.
Current Policies & Corresponding OIDs
To view the policies and OID list, open the certificate templates console (certtmpl.msc), then right click on the console root at the top left and select “View Object Identifiers…
OID(s) that start with 1.3.6.1.4.1.311 are Microsoft based policies
The highlighted policy above is Microsoft’s OID designation
for Remote Desktop Authentication (1.3.6.1.4.1.311.54.1.2) but isn’t present by
default and must be created.
Creating Remote Desktop Authentication Policy
To create the policy, open certificate templates console (certtmpl.msc)
then right click on the default Computer template and duplicate template. Highlight
the Extensions tab and select Application Polices and click Edit.
Select Client and Server Authentication
polices and Remove. Now click Add and the Add Application Policy
box opens; select New and in the New Application Policy dialog box enter
“Remote Desktop Authentication” in the Name field and 1.3.6.1.4.1.311.54.1.2
in the Object Identifier field (delete the default value in the box) then OK
out. On the Security tab set Read and Enroll for targeted servers or
groups. On the General tab, set the Template
display name and Template name to
match exactly with no spaces. (Example: NewRDPTemplate)
Utilizing the New Certificate Template
Publish the new RDP template to a certificate authority. For servers to automatically enroll and stop generating and using self-signed certificates a GPO must be configured. The GPO settings are located under: Computer Configuration, Policies, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Security, Server Authentication certificate template. Update the policy with the template name or OID of the RDP certificate template and select the enable radio button then OK. When the GPO refresh applies to targeted servers they will enroll for the new certificate and use it for RDP connections.
Template Name Example
OID Example
When setting the Certificate Template Name for RDP template in the GPO, rather than using the template name, the templates OID may also be used. The OID is shown under the Extension tab in the Certificate Template Information or via Certutil: Certutil -adtemplate -v “”.
Related Resources
Blog
November 7, 2024
PKI Insights Recap – Is Your PKI Healthy? The Essential Guide to Comprehensive Assessments
PKI, PKI Insights
Blog
October 4, 2024
Announcing the October 2024 PKI Spotlight® Release
PKI, PKI Spotlight
Blog
August 16, 2024
To Revoke or Not to Revoke: Balancing Security with Performance and Operational Complexity
CA, Certificate Authority, Certificate Revocation List, CRL, OCSP, PKI, VPN
Jake Grandlienard
Jake Grandlienard brings more than 19 years of industry experience as a senior level engineer. Jake is a subject matter expert in PKI, mobile device management software, smart card management software, and Hardware Security Module (HSM) integrations.
Very good article. I have my environment configured in the same way, however, we encounter a small problem with this setup.
For some of our servers that reside deeper in our data centers, they have two NIC’s configured. One for the Public side of the Network and one for the Private (Admin) side of the Network. Since these servers technically have two DNS entries for the differing Networks, we find an issue in where the RDP Cert which is issued on the Public side of the network does not include the Private (Admin) DNS entry in the RDP Cert, so we end up getting the RDP Cert Warning when accessing the server on the Private (Admin) Network. Is there a way to include an additional SAN entry for the Private (Admin) Network DNS entry upon RDP Cert Issuance so that the RDP Cert gets both DNS entries for the server which include the Public and Private (Admin) DNS entries?
Hi Michael,
Thank you for your question and apologies for the delay in my response. The problem you mention you are seeing with your servers RDP certificates is like those I see with other clients custom Domain controller or Webserver certificates. The option of building the subject from AD is not able to get everything needed into the certificate. In these cases, the only option is to have a separate template that allows a subject supplied in request. The custom names and SAN(s) from both private and public NIC(s) can be added. We would also want to make sure the template is configured to Use subject information from existing certificates for auto-enrollment renewal request. (Available after compatibility for recipients of Windows 7 / Server 2008R2 or later) Lastly, we need to make sure the designated servers have both enroll and auto-enroll configured, so the renewals are automated.
Thank you again from the question, and I will do a better job of responding quicker in the future.
Jake
Hi Jake, excellent article. I’ve bumped up against the issue with multiple RDP certs being issued on every gpupdate. All servers are 2012R2, 2016, 2019, with all Windows 10 1809/1909 clients. The ADCA is running on Server 2019. DFL/FFL is at 2012R2 level. I’ve attempted several iterations of creating new templates, naming template name and template displayname the same, no spaces. Also tried using the template name in my gpo as well as the oid. Any ideas on where else this repeat gpupdate enrollment is triggering from?
Sorry to hear you are having problems. The multiple certificates bug was present in older version of Windows Server, but I have not seen or heard of it in anything later like you have in your environment. Can you verify the permission on the template you have configured in the GPO? The certificate listed (by template name or OID) only needs Read and Enroll permissions for the intended systems, not auto enroll. If auto enroll is granted it may be causing the duplication issues. If that isn’t the case, please reply back and let me know.
Thanks for the quick response! I resolved the issue. Sadly I made multiple changes in one shot so I’m not sure which was of my goofs were causing this behavior. First thing, my original template did have autoenroll enabled. Then during testing I set validity time to 6 hrs with 2 hr renewal window to test autorenewal and cleanup of expired/revoked certs. I then had issues so I simply deleted the template, re-sync’ed AD, then created a new template but used the *same* template name as the deleted template and set autorenew off with the same expiry/renewal time as the deleted template. Even though I followed your instructions on that second template I continued to have the multiple enrollments. Finally, after seeing your post and a bit more digging and failures, I followed your original instructions again, this time with a new template name, no autoenroll, and much higher expiry/renewal periods. I also set compatibility to cert server 2016, clients Win8/2012R2, and crypto ECDH_P256. That worked! no more multiple enrollments. Thanks for the major assist!
Hi Jake,
Thank you for the write-up, it was very helpful.
I have tried to follow your write up but facing an issue when adding Remote Desktop Authentication OID under applications. Getting the message “The following object identifier has already been used:…”
I have tried to look for the oid in the template and object identifiers but it is simply not there. Any idea what I did wrong or how to resolve it?
Thank you for your question. When searching for the Remote Desktop Authentication (RDP) OID there are a couple different ways to view them. One easy way is from the certificate template console (certtmpl.msc). When open, right clicking Certificate Templates in the upper left and select View Object Identifiers, it will show a list of all OIDs. Another method is to run a PowerShell command using Certutil to dump a list of all OIDs for the pKIExtendedKeyUsage attribute. (Certutil –dstemplate –v | select-string displayname, pKIExtendedKeyUsage | clip) I like to use | clip to copy the output to the clipboard and paste into a text editor. Then, use Find to look for the RDP OID: 1.3.6.1.4.1.311.54.1.2. The only catch with this method is, if you do not have read access to the certificate template that has the RDP application policy it will not be shown.
Please let me know if searching with these methods locates the existing Policy using the RDP OID.
We’ve been able to replicate the error message above, but have not yet resolved it “The following object identifier has already been used:…”
The reason for this issue: is that if Full Control permissions aren’t granted over the OID container in AD, that an attempt to create an OID will fail with the error message “Windows could not save the new application policy name. Insufficient access rights to perform the operation.”
Later on, if you’re given Full Control over the OID container, and reattempt to create the OID, it will give the error “The following object identifier has already been used: 1.3.6.1,4.1.311.54.1.2. Type a different value.”
It appears that an OID is created, but the name is not saved, so it exists somewhere in the OIDs directory but is not available for use.
I think this article needs to be revisited, the EKU for remote desktop authentication is missing, and server authentication appears to be more readily consumable by end points, including non Microsoft boxes, for the encryption piece, in the environments I have been in for at least a couple years as stated by Mbauguraije Tjikuzu
I have double checked the article and the Application Policy (EKU) for RDP (1.3.6.1.4.1.311.54.1.2) is listed a couple times. When making the decision to leave Server Authentication (1.3.6.1.5.5.7.3.1) or remove it I agree it should be based on the environment. A large presence of non-Windows devices will drive leaving Server Auth., however utilizing a single certificate for a specific purpose has its merits. When configuring bindings in IIS as an example, the RDP certificate with no Server Auth. will not display as an option.
I’m curious as to whether you’ve seen an issue where the enrolling computers seem to require elevated permissions to enroll using the RDP certificate template. I’ve got an environment that I’d describe as relatively vanilla, in which I have defined the template and application policies as above. Domain Computers are permitted to Enroll.
The issuing CA enrolled itself without problems. I have only managed to get other servers to enroll if I add them to the issuing CA’s Administrators group; without those overly generous permissions, enrollment fails with RPC_S_SERVER_UNAVAILABLE.
The template has a reasonably simple ACL – Authenticated Users (R), Domain Admins and Enterprise Admins (R,W,E) and Domain Computers (R,E).
Hi David,
It sounds like the issue you are seeing is related to DCOM permissions. Is the CA role currently on a domain controller? That can cause similar issues and would require some additional config. You would need to make sure the AD group Certificate Service DCOM Access (DSA.msc) has the Domain Users, Domain Computers groups.
If the CA isn’t on a DC, check the local group Certificate Service DCOM Access (lusrmgr.msc) group on the CA, verify it has NT Authority\Authenticated Users present. If it is there and the problems persist then let me know and I can recommend what to check next.
Thanks for sharing, this guide helped me setting up certificates for RDP sessions!
I was wondering if it is possible to include the IP address as alternative name in the certificates (I do not think I saw this is an option in the template)? Sometimes I make connections using the IP address and then there is this warning about name mismatch. Or should I simply change my behavior to always connect using FQDN? 🙂
Thanks for sharing, this guide helped me setting up certificates for RDP sessions!
However, is it possible to use the IP address as alternative name in the certificates? I do not think I saw this option in the template. Or should I simply change my behavior to always connect using the FQDN instead of sometimes using the IP address? 🙂
Hi Jake,
Thanks for writing knowledgeable article .I ‘m planning to try it. I have question Where should I configure GPO on AD server or CA server?
Thanks
The group policy settings can be added to a new or existing GPO. In either case, the GPO must be linked to the OU where the machine objects exist to trigger enrollment for the RDP certificate. You can view all polices and make updates via GPMC.msc. Link the policy at the domain level to target all machines or a specific OU to limit the scope. Don’t forget to grant enroll access to the RDP certificate template created to any machines you want to enroll for the RDP certificate.
Hi Jake,
Thanks for quick reply. I got it. Actually , I want to know on which server i have to edit setting Domain Controller or CA Server?
Thank again!
Hi Jake,
I’m getting the following warning message when try to RDP through VPN.
A revocation check could not be performed for the certificate.
The certificate or associated chain is invalid (Code:0x10000).
Any Idea?
When i create a new template i get message that the following object identifier has already been user. trype a different value. Is RemoteDesktopSecure is an anwer to that from MS?
It sounds as if someone has already created the Application Policy for the RDP OID. You can verify if any existing certificate templates are configured with the RDP OID by running , or select any template in certtmpl.msc, then properties and select the Extension tab. Select the Application Policies, then edit so you can view all the existing policies and associated OIDs. If it is not in use, create a new template and assign it as the application policy.
I have gone through each certificate template in my console, and none is utilizing the OID for RDP. However, when I try to create a new template according to your instructions, I always get the error that the OID is already in use. In my Object Identifiers list, there is a policy called Remote Desktop Authentication using the 1.3.6.1.4.1.311.54.1.2 identifier. Do I need to somehow delete this first (and if so, how?), then create a new template, or is there some other way/place to search for why it seems to be in use?
Schedule a Demo
