RFC 2818 - 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 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 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

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.

Manually requesting a web server certificate

There are cases in which you cannot or do not want to obtain web server certificates directly from a certification authority in your own Active Directory forest via the Microsoft Management Console, 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).

Google Chrome and Microsoft Edge do not check certificate revocation state

More and more companies are using the Google Chrome browser or the new Chromium-based Microsoft Edge (codename Anaheim) on.

When distributing one of these two browsers, it should be noted that they sometimes behave differently from other browsers in terms of certificates.

Besides the fact that Chromium, unlike Internet Explorer and the previous Edge (codename Spartan) the RFC 2818 enforces, it also behaves in the Checking blocking information different.

Certificate request fails with error message "Error Parsing Request The request subject name is invalid or too long. 0x80094001 (-2146877439 CERTSRV_E_BAD_REQUESTSUBJECT)".

Assume the following scenario

A certificate request is sent to a certification authority.
The certificate request fails with the following error message:

Error Parsing Request The request subject name is invalid or too long. 0x80094001 (-2146877439 CERTSRV_E_BAD_REQUESTSUBJECT)

Chrome and Safari limit SSL certificates to one year validity

Apple recently announced that the Safari browser will only accept certificates with a validity of 398 days in the future, provided they were issued from September 1, 2020.

Mozilla and Google want to implement comparable behavior in their browsers. So the question is whether this change will have an impact on internal certificate authorities - i.e. whether in future internal SSL certificates will also have to follow these rules, as is the case, for example, with the enforcement of the RFC 2818 by Google was the case.

More than one common name (CN) in the certificate

Nowadays rather a curiosity than really relevant in practice, but it does happen from time to time that you receive certificate requests that contain more than one common name in the subject. Even though it may seem surprising, this is quite possible and also RFC compliant.

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.

Generating a RFC 2818 compliant certificate request for SSL certificates

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

Active Directory forest compromised by EDITF_ATTRIBUTESUBJECTALTNAME2 flag

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 recommends that the EDITF_ATTRIBUTESUBJECTALTNAME2 flag should be set on the certification authority - supposedly to be able to issue Subject Alternative Name (SAN) extension certificates for manually submitted certificate requests.

Unfortunately, this approach 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 forest.