Subject Alternative Name (SAN)

Automatically enter DNS names in the Subject Alternate Name (SAN) of issued certificates - with the TameMyCerts Policy Module for Microsoft Active Directory Certificate Services (ADCS)

Google is a major player with the Chromium project and products based on it such as Google Chrome and Microsoft Edge have moved to implement the RFC 2818 and to no longer trust certificates that no longer fulfill the RFC.

For us, the following sentence is of great explosiveness:

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead
https://tools.ietf.org/html/rfc2818

Change the Subject Alternative Name (SAN) of a certificate before it is issued - but do it securely!

In net circulate unfortunately much at many Instructions (also the big players are not excluded from this, not even Microsoft itself or the Grand Master Komar), which fatally recommend that the flag EDITF_ATTRIBUTESUBJECTALTNAME2 should be set on the certification authority - supposedly to be able to issue certificates with Subject Alternative Name (SAN) extension for manually submitted certificate requests.

Unfortunately, this procedure is not only unnecessary, it also has some unpleasant side effects, which in the worst case can help an attacker to take over the entire Active Directory structure.

Basics: Name Constraints

Name restrictions are a part of the X.509 standard and in the RFC 5280 described. They are a tool that can be used within the qualified subordination can be used to control the validity range of a certification authority certificate in a fine-grained manner.

From Zero to Enterprise Administrator through Network Device Enrollment Service (NDES) - and What to Do About It

In the following, I would like to present a highly dangerous PKI configuration, perhaps not necessarily known to the general public, which can probably be encountered quite frequently in this way in corporate networks.

I show how, by exploiting various unfortunate circumstances in the Windows PKI, it is possible to elevate privileges from mere network access to complete Active Directory takeover.

The initial point of attack in this example is the Network Device Enrollment Service (NDES).

Basics: Configuration file for the certification authority (capolicy.inf)

The capolicy.inf contains basic settings that can or should be specified before installing a certificate authority. In simple terms, it can be said that no certificate authority should be installed without it.

Signing certificates bypassing the certification authority

Time and again in discussions about the security of a certification authority, it comes up that abuse of the certification authority could be contained by its security settings.

However, the fact that the integrity of a certification authority is directly tied to its key material and can therefore also be compromised by it is not obvious at first glance.

one must think of the certification authority software as a kind of management around the key material. For example, the software provides a Online interface for Certificate Enrollment takes care of the authentication of the enrollees, the automated execution of signature operations (issuing certificates and Brevocation lists) and their logging (Certification Authority Database, Audit log, Event log).

However, signature operations require nothing more than the private key of the certification authority. The following example shows how an attacker, given access to the certification authority's private key, can generate and issue certificates without the certification authority software and its security mechanisms being aware of this.

With such a certificate, it would even be possible in the worst case, take over the Active Directory forest undetected.

Certificate Enrollment for Windows Systems via the Network Device Enrollment Service (NDES) with Windows PowerShell

If you want to equip Windows systems with certificates that do not have the option of communicating directly with an Active Directory-integrated certification authority, or that are not even in the same Active Directory forest, the only option in most cases is to install certificates manually.

Since Windows 8.1 / Windows Server 2012 R2, however, there is an integrated client for the Simple Certificate Enrollment Protocol (SCEP) on board. On the server side, SCEP is implemented via the Network Device Enrollment Service (NDES) implemented in the Microsoft PKI since Windows Server 2003.

A particularly interesting feature of SCEP is that the protocol allows a certificate to be renewed by specifying an existing one. So what could be more obvious than to use this interface? What is still missing is a corresponding automation via Windows PowerShell.

Details of the event with ID 30 of the source Microsoft-Windows-NetworkDeviceEnrollmentService

Event Source:	Microsoft-Windows-NetworkDeviceEnrollmentService
Event ID:	30 (0x1E)
Event log:	Application
Event type:	Error
Symbolic Name:	EVENT_MSCEP_FAIL_ADD_ALT
Event text (English):	The Network Device Enrollment Service cannot add an alternative subject name extension to the certificate request (%1). %2
Event text (German):	No extension for an alternative requester name can be added to the certificate request by the network device registration service (%1). %2

Details of the event with ID 21 of the source Microsoft-Windows-Kerberos-Key-Distribution-Center

Event Source:	Microsoft Windows Kerberos Key Distribution Center
Event ID:	21 (0x80000015)
Event log:	System
Event type:	Warning
Event text (English):	The client certificate for the user %1\%2 is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they're attempting to use for smartcard logon. The chain status was : %3
Event text (German):	The client certificate for user %1\%2 is not valid. The result was an error during smartcard login. Contact the user for more information about the certificate to be used for the smartcard application. Chain status: %3

Configuring a Certificate Template for Domain Controllers

Even with a certificate template for domain controllers that is supposedly simple to configure, there are a few things to keep in mind.

Configuring the Network Device Enrollment Service (NDES) for use with an alias.

The following describes the steps required to configure the Network Device Enrollment Service (NDES) for use with an alias.

The term alias means that the service is not called with the name of the server on which it is installed, but with a generic name independent of this name. The use of an alias allows the service to be moved to another system at a later time without having to inform all participants of the new address.

Manually requesting a Remote Desktop (RDP) certificate

There are cases in which you cannot or do not want to obtain Remote Desktop certificates from a certificate authority in your own Active Directory forest, for example, if the system in question is not a domain member.

In this case, the use of certificate templates is not possible, and one must manually create a Certificate Signing Request (CSR).

Certificates for domain controllers do not contain the domain name in the Subject Alternative Name (SAN)

Assume the following scenario:

Certificates for domain controllers are issued by an Active Directory integrated certificate authority (Enterprise CA)
The certificate template used for this purpose was created by the user
The issued certificates contain in the Subject Alternative Name (SAN) only the fully qualified computer name of the respective domain controller, but not the fully qualified name and the NETBIOS name of the domain

Allowed Relative Distinguished Names (RDNs) in the Subject of Issued Certificates

In principle, the RFC 5280 the use of arbitrary strings in the subject string of a certificate. Common fields in the standard are X.520 described. The Length restrictions are also recommended by the ITU-T. The abbreviations commonly used today are mainly taken from the RFC 4519.

However, Microsoft Active Directory Certificate Services only allows certain RDNs by default.

The following Relative Distinguished Names (RDNs) are accepted by the Active Directory Certificate Services (ADCS) certificate authority by default:

Inspect a certificate request (CSR)

Often, before submitting a certificate request to a certification authority - or before issuing the certificate - you want to verify that it contains the desired values.

The following describes how to achieve this.