Subject Alternative Name (SAN)

How securing printers can turn into a security disaster - and how the TameMyCerts Policy Module for Active Directory Certificate Services (ADCS) can prevent it

Nowadays, it is essential to protect the authentication of devices on the company network and administrative interfaces. As a rule, digital certificates are used for this purpose.

Printers therefore also generally require digital certificates in order to be operated securely. From a certain number of devices, there is no getting around automatic certificate distribution.

Some printer manufacturers offer centralized management solutions for certificate distribution.

Unfortunately, it has been shown time and again that the secure handling of digital certificates requires a great deal of knowledge, experience and care, which is often not the case.

How the TameMyCerts Policy Module for Active Directory Certificate Services (ADCS) can prevent attacks against the ESC1 attack vector

Attacks on Microsoft certification authorities can be aimed at exploiting authorizations on certificate templates. In many cases, certificate templates must be configured to grant the applicant the right to apply for any identities. This can lead to the attacker taking over the identities of Active Directory accounts and subsequently to the elevation of rights. Attacks of this type are known in the security scene as "ESC1" is labeled.

How the TameMyCerts Policy Module for Active Directory Certificate Services (ADCS) can detect and prevent attacks against the ESC6 and ESC7 attack vectors

With the supposedly good intention of making it possible to issue such certificate requirements with a SAN, guess unfortunately much at many Instructions to set the flag on the certification authority EDITF_ATTRIBUTESUBJECTALTNAME2 to activate.

If this flag is activated, a very large attack surface is offered, as any applicant can now instruct the certification authority to issue certificates with any content. This type of attack is known in the security scene as ESC6 and ESC7 known.

How the TameMyCerts Policy Module for Active Directory Certificate Services (ADCS) can help secure scenarios with Microsoft Intune and other Mobile Device Management (MDM) systems

Companies use Mobile Device Management (MDM) Products for managing, configuring and updating mobile devices such as smartphones, tablet computers or desktop systems via the Internet (over-the-air, OTA).

Common mobile device management products are:

Microsoft Intune
VMware Workspace One (previously known under the brand name AirWatch)
Ivanti MobileIron UEM
Jamf Pro
Baramundi Enterprise Mobility Management
BlackBerry Enterprise Mobility Suite
Sophos Mobile Control
SOTI MobiControl

How the TameMyCerts Policy Module for Active Directory Certificate Services (ADCS) can repair incoming certificate requests to make them RFC compliant

Starting with version 58, Google has decided to remove support for the Subject Distinguished Name of web server certificates in the Chrome browser and instead only accept certificates with Subject Alternative Name.

Since this moment, web server certificates without a subject alternative name in the form of a dNSName from Google Chrome and others Chromium-based browsers (i.e. also Microsoft Edge) was rejected. Other browser manufacturers quickly adopted this approach, so that this problem now affects all popular browsers.

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 this requirement.

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.