Tag: Relative distinguished name (RDN)

As the operator of a certification authority, 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 authority. Well-known companies have already failed at this task , even had to file for insolvency as a result of misissuances and/or were severely punished by the big players in the market.

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 enrollee 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.

Continue reading "A policy module to tame them all: Introducing the TameMyCerts Policy Module for Microsoft Active Directory Certificate Services"

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.

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

Sometimes it is necessary to allow Relative Distinguished Names (RDNs) in issued certificates that are not defined and therefore could not be configured in the SubjectTemplate value in the certification authority's registry either.

An example of this is the Organization Identifier with object identifier 2.5.4.97, which is required, for example, for certificates that comply with the eIDAS Regulation.

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

Microsoft Active Directory Certificate Services does not transfer subjects from certificate requests for templates in which the enrollee is allowed to supply them 1:1 into the issued certificate.

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

Continue reading "Change the order of the Relative Distinguished Names (RDNs) in the Subject Distinguished Name (DN) of issued certificates"

Apple recently announced that the Safari browser will in future only accept certificates with a validity of 398 days, provided they were issued on or after 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 certification authorities - i.e. whether in future internal SSL certificates will also have to follow these rules, as was the case, for example, with Google's enforcement of RFC 2818 .

Continue reading "Chrome and Safari limit SSL certificates to one year validity"

In principle, RFC 5280 allows the use of arbitrary strings in the subject distinguished name (DN) of a certificate. Common fields are described in the X.520 standard. The length restrictions are also recommended by the ITU-T . The abbreviations commonly used today are mainly taken from 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 (AD CS) certification authority by default:

Continue reading "Allowed Relative Distinguished Names (RDNs) in the Subject of Issued Certificates"