Certification body - Uwe Gradenegger

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 rejected by Chrome. Other browser manufacturers quickly adopted this approach, meaning that this problem now affects all popular browsers (including Microsoft Edge).

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 kind 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 body 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 to manage, configure and update 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 as 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 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.

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: Delta revocation lists

Certificate revocation lists (CRLs) are used to remove issued certificates from circulation before the end of their validity period.

A CRL is a signed list of the serial numbers of certificates that have been revoked by the certification authority. The revocation list has an expiration date (usually a few days short) and is reissued and signed by the associated certification authority at regular intervals.

Certificate revocation lists can reach a considerable size if the volume of revoked certificates is high (as a rule of thumb, you can expect about 5 megabytes per 100,000 entries). The regular download of large certificate revocation lists by subscribers can generate a large network load. To address this problem, there is the concept of delta revocation lists.

Deconstruction of an Active Directory integrated certification authority (Enterprise CA)

There are many instructions for setting up and commissioning IT services. However, the associated instructions for decommissioning are usually forgotten.

The following describes how to correctly decommission a certification authority (Enterprise Certification Authority) integrated into Active Directory.

Subsequent archiving of private keys

For the encryption of e-mail messages, companies usually use the Secure / Multipurpose Internet Message Extensions (S/MIME) standard and provide their users with appropriate certificates for this purpose.

An important aspect here is that the users' private keys should be secured centrally - in contrast to the signature certificates that are otherwise mostly used. Incoming messages are encrypted for a specific private key and can only be decrypted again by the same person. Thus a backup of these keys must absolutely be available - also for the Synchronization to mobile devices this is indispensable. For this purpose, the Microsoft Active Directory Certificate Services offer the function of the Private Key Archival.

But what if private key archiving has not been set up and users have already applied for corresponding certificates?

Signing certificates bypassing the certification authority - solely using built-in tools

In the article "Signing certificates bypassing the certification authority"I described how an attacker with administrative rights on the certification authority can generate a logon certificate for administrative accounts of the domain by bypassing the certification authority software, i.e. by directly using the private key of the certification authority.

In the previous article I described the PSCertificateEnrollment Powershell Module is used to demonstrate the procedure. Microsoft supplies with certreq and certutil However, perfectly suitable pentesting tools are already included with the operating system ex works.

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 errors is the central cornerstone for the trust that is placed in the Certification Authority. Well-known companies are already failed in this task, even had to file for insolvency as a result of misrepresentations and/or were severely punished by the major players on the market.

In many cases, we as enterprise (Microsoft) PKI operators (regardless of the quality involved) are able to delegate our task of uniquely identifying an enrollee to Active Directory. In many cases, however, we must also instruct our certification authority(ies) to simply issue whatever is requested.

The partition of the Hardware Security Module (HSM) runs full

Assume the following scenario:

A Certification Authority uses a Hardware Security Module (HSM).
The partition of the hardware security module fills up with more and more keys over the lifetime of the certificate authority.
At SafeNet hardware security modules, this can even cause the partition to fill up. As a result, the events 86 and 88 logged by the Certification Authority.