Relative Distinguished Name (RDN)

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.

Use of undefined Relative Distinguished Names (RDN) in issued certificates

Sometimes it is necessary to allow Relative Distinguished Names (RDNs) in issued certificates that are not defined and accordingly not included in the SubjectTemplate value of the certification authority registration could be configured.

An example of this is the Organization Identifier with Object Identifier 2.5.4.97, which is required, for example, for certificates that are used for the eIDAS Regulation are compliant.

Change the order of the Relative Distinguished Names (RDNs) in the subject of issued certificates.

The Microsoft Certification Authority accepts subjects from certificate requests for templates in which their specification by the requester is allowed, not 1:1 in the issued certificate.

Instead, both is defined, which Relative Distinguished Names (RDNs) are allowedas well as in which order they are written to issued certificates. However, this order can be changed. How this is done is explained below.

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.

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: