Subject Distinguished Name - Uwe Gradenegger

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 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
Samsung Knox

How the TameMyCerts Policy Module for Active Directory Certificate Services (ADCS) can help establish digital signature processes in the company

Nowadays, many companies want to rely on paperless processes to speed up internal approval and signature processes. In times when most employees are working from home, this has become even more important.

Although the Microsoft certification authority is able to implement automatic certificate issuance processes, their ability to influence the content of the certificate is severely limited.

The TameMyCerts Policy Module for Microsoft Active Directory Certificate Services (AD CS) allows the definition of extended Rules for the Subject Distinguished Name and also the Subject Alternative Name certificates issued.

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.

Installation of a new certification authority certificate fails with error code "ERROR_INVALID_PARAMETER".

Assume the following scenario:

A new Certification Authority certificate is requested for a subordinate Certification Authority and issued by the superordinate Certification Authority.
The Subject Distinguished Name (Subject DN) is identical to that of the previous certification authority certificate.
However, the installation of the certificate authority certificate fails with the following error message:

An error was detected while configuring Active Directory Certificate Services.
The Active Directory Certificate Services Setup Wizard will need to be rerun to complete the configuration.
The new certificate subject name does not exactly match the active CA name.
Renew with a new key to allow minor subject name changes: The parameter is incorrect. 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER).

Character encoding in the Subject Distinguished Name of certificate requests and issued certificates

Usually, the encoding of characters and strings in certificates is not a topic of great interest to the users of a PKI. However, there are cases where the default settings of the certification authority do not provide the desired results.

A policy module to tame them all: Introducing the TameMyCerts Policy Module for the Microsoft Certification Authority.

As a Certification Authority operator, you are (among other things) responsible for the identification of the enrollees and the confirmation of the requested identities. The fact that this task is carried out conscientiously and without error is the central pillar of the trust placed in the certification body. Well-known companies are already failed in this task, even had to file for insolvency as a result of misrepresentations and / or were taken over by the big players in the market sensitive punished.

In many cases, we as (Microsoft) PKI operators in companies (regardless of the associated quality) are able to delegate our task of uniquely identifying an applicant to the Active Directory. In many cases, however, we unfortunately also have to instruct our certification authority(ies) to simply issue everything that is requested.

About the "Build this from Active Directory information" option for certificate templates

When configuring a certificate template, one must decide on the intended certificate content, i.e., among other things, which identities are confirmed by the certificates and how they are mapped.

In the "Subject Name" tab of the certificate template configuration dialog, you can configure how the identity confirmed by the certificate is mapped.

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.

Code signatures of Appx packages via SignTool.exe fail with error code 0x8007000b (ERROR_BAD_FORMAT)

Assume the following scenario:

An Appx package is to be signed.
For this purpose the SignTool.exe used.
The code signing certificate used was recently renewed.
The signing process with the new code signing certificate fails with the following error message:

"Error: SignerSign() failed." (-2147024885/0x8007000b)

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.

SSCEP: Subject of our request does not match that of the returned Certificate!

Assume the following scenario:

A certificate request is made on a Linux system (for example, a thin client) by means of a SSCEP against a Network Device Enrollment Service (NDES) performed.
The certificate request fails with the following error message:

sscep: Subject of our request does not match that of the returned Certificate!