Configuring a Certificate Template for Remote Desktop (RDP) Certificates
To use Remote Desktop certificates, it is necessary to configure an appropriate certificate template.
Rob Greene from Microsoft points out in a blog entry published in September 2024 that Remote Desktop certificates should not be requested via autoenrollment (as described below).
The Remote Desktop session host can use certificates with the following Extended Key Usages (EKU) :
- Server Authentication (OID: 1.3.6.1.5.5.7.3.1)
- Remote Desktop Authentication (OID: 1.3.6.1.4.1.311.54.1.2)
It is recommended to use the Remote Desktop Authentication EKU, as this ensures that the certificates are only used for this purpose and not, for example, for providing a web server as well.
Likewise, using the "Server Authentication" EKU in combination with a key storage provider (KSP) can cause problems with the Active Directory Web Services (ADWS) , as these do not support KSPs and filter the certificate selection only by EKU and the fully qualified host name. Such conflicts can be avoided by using the Remote Desktop Authentication EKU.
However, the Remote Desktop Authentication EKU is not defined in the Active Directory directory service out of the box. This must be done in the course of configuring the certificate template.
Certificate template configuration
Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the application of rule sets to realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can be downloaded via GitHub and used free of charge. Professional maintenance is also offered.
First, a copy of the "Workstation Authentication" certificate template is created and edited using the Certificate Templates management console (certtmpl.msc).
"Compatibility" tab
We intend to use key storage providers (KSP) . For this, it is necessary to set the compatibility settings for certification authority and certificate recipient to "Windows Vista" and "Windows Server 2008" respectively.
"General" tab
A meaningful name is assigned in the "General" tab.
For Remote Desktop certificate templates, it is essential to use the same value for the certificate template name and its display name, as otherwise certificates may be requested more than once .
Vulnerability scanners such as those from Qualys will report a finding both if the certificate was not renewed one month before expiration and if the certificate is valid for more than one year. Since renewal via autoenrollment only occurs after 80% of the certificate validity has passed , it makes sense to set the certificate validity to a minimum of 6 months and a maximum of 12 months, and the time window for certificate renewal to a minimum of 5 weeks.
"Request Handling" tab
In the "Request Handling" tab, the Purpose must be adapted to the key algorithm to be used. The reason is that different requirements are placed on the "Key Usage" extension of the certificate depending on the key type (see RFC 5246 and RFC 4492 ).
| Key algorithm | Value |
|---|---|
| RSA | Signature and Encryption |
| ECDSA | Signature |
| ECDH | Signature and Encryption |
"Cryptography" tab
In the "Cryptography" tab, you can now select the "Key Storage Provider" category and the respective key algorithm.
The Microsoft Software Key Storage Provider should be selected as the provider unless the keys are to be protected, for example, with a Trusted Platform Module (TPM) .
If a cryptographic service provider (CSP) is to be used, the "Microsoft RSA SChannel Cryptographic Provider " should be used. It only supports AT_KEYEXCHANGE, so the Purpose must be set to "Signature and Encryption" in the "Request Handling" tab. In principle, a key storage provider should be preferred where possible.
There is an exception, however: the Active Directory Web Services (ADWS) already abort during certificate selection if even a single certificate in the computer certificate store does not use a CSP. So in this case, make sure that Remote Desktop certificates on domain controllers with ADWS enabled also use a CSP.
The choice of provider only affects certificate requests that read the certificate template during the request (i.e. manual or automatic certificate requests via autoenrollment).
"Extensions" tab
In the "Extensions" tab, the "Application Policies" are edited by clicking on "Edit...".
The existing "Client Authentication" EKU is removed by clicking on "Remove", as it is not required.
Then a new EKU is added with "Add...".
Since the Remote Desktop Authentication EKU is not defined in the Active Directory directory service out of the box, it must first be created by clicking on "New...".
The predefined values in the following dialog are removed and the following are entered instead:
| Field | Description |
|---|---|
| Name | A free text field, but the text entered here will be displayed in the certificate dialog on every client in the network. Therefore, something meaningful like "Remote Desktop Authentication" should be entered. |
| Object identifier | Exactly the following value must be entered here: 1.3.6.1.4.1.311.54.1.2 |
The newly defined EKU can now be selected and added by clicking on "OK".
Click on "OK" to finish the configuration.
"Security" tab
In the "Security" tab, the "Enroll" and "Autoenroll" permissions must be set for the participating computers.
If only "Enroll" is set, the machines will still request certificates, provided the corresponding Group Policy has been configured, as this corresponds to the fallback scenario. However, it is recommended to work with autoenrollment for better certificate management. Among other things, the fallback option does not archive expired certificates, which will lead to the regular generation of the event with ID 64 of the source Microsoft-Windows-CertificateServicesClient-AutoEnrollment on the clients.
Suitable security groups include, for example:
- Domain Computers (is already included in the list)
- Domain Controllers (must be added to the list)
If the Active Directory forest consists of several domains, the groups of all corresponding domains must of course be entered.
Technically, the "Enroll" permission is sufficient. However, it is strongly recommended to also grant the "Autoenrollment" permission so that the certificates are distributed through this mechanism and used by the Remote Desktop session host. The client-side behavior is described in the article "Configuring a Group Policy (GPO) for Remote Desktop (RDP) Certificates ".
"Subject Name" tab
The option is described in more detail in the article "About the "Build this from Active Directory information" option for certificate templates ".
The default settings of the "Workstation Authentication" certificate template can be kept.
Result
The issued certificates now show the Remote Desktop Authentication Extended Key Usage, because the corresponding OID object in the Public Key Services object of the forest is associated with this display name and is replicated to every participant in Active Directory.
Next step: configure Group Policy
To ensure that the certificates are also used by the Remote Desktop session host, a corresponding Group Policy must now be configured. The procedure is described in the article "Configuring a Group Policy (GPO) for Remote Desktop (RDP) Certificates ".
External sources
- Using certificates in Remote Desktop Services (Microsoft)
- Configuring Remote Desktop certificates (Microsoft, archive.org)
- Object IDs associated with Microsoft cryptography (Microsoft)
- Remote Desktop server certificates are renewed two times a day despite being valid for one year (Microsoft)
- Remote Desktop Services enrolling for TLS certificate from an Enterprise CA (Rob Greene, Microsoft)