Creating an RFC 2818 compliant certificate request for SSL certificates

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 the RFC.

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

Please note that the statements regarding the mapping of identity within a certificate in this article are aimed exclusively at the HTTP over SSL (HTTPS) use case.

The RFC thus requires that the identity of a web page should no longer be formed from the Common Name field within the Subject, but from one or more dNSName entries within the Subject Alternative Name (SAN) extension within the certificate. Thus, a certificate without a SAN extension is not RFC compliant and will no longer be accepted by these browsers.

Identity via Common Name (CN) within the subject, should no longer be done.

Identity via dNSName entry within the Subject Alternative Name extension, the variant required by RFC 2818.

Create a certificate request

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

The process for requesting an RFC 2818-compliant certificate from the Microsoft certification authority is described below. A method has been deliberately chosen here which is divided into the individual process steps and can therefore also be adapted for other systems (for example Linux).

Manual creation of the certificate request

This method is useful for systems that are not members of the same Active Directory forest as the certificate authority. See article "Manually requesting a web server certificate„.

Creating the certificate request via the Microsoft Management Console (MMC)

This method is useful if the web server and the certification authority are members of the same Active Directory forest and can therefore use the certificate templates stored in Active Directory.

The first step is to generate a key pair and a certificate request (CSR) on the target system. This step depends on the target operating system (Windows, Linux, etc.) and must be performed by the respective IT service owner (the requester, enrollee).

For Windows, the certificate management console for the computer account (certlm.msc) is started and Certificates is right-clicked under Personal. In the context menu, select All Tasks - Advanced Operations - Create Custom Request.

Now select the certificate template and click Next.

Before the certificate request is generated, Properties is clicked in the subsequent dialog under Details. In the case of a web server certificate, the requester usually specifies the identity, which still has to be configured.

According to RFC 2818, the subject of the certificate may be empty if a Subject Alternative Name exists. The Subject Alternative Name extension behaves as follows for the Microsoft Certificate Authority in compliance with RFC 2818:

If the subject is empty, the Subject Alternative Name extension is defined as a critical marked, since it contains the only way to determine the identity.
If a Common Name exists within the Subject, the Subject Alternative Name extension is available as a not critical marked to allow applications to fallback should they not understand the SAN extension.

Experience shows that it is quite possible that a certificate can be used by an application that has not been programmed to conform to RFC 2818. This would possibly not know the Subject Alternative Name extension and then ignore it. If the SAN extension is marked as critical, the processing of the certificate would have to be aborted in this case.

For this reason, it is quite advisable to continue to populate the Common Name. This does not violate RFC 2818, since a SAN extension is available for all compliant applications.

The certificate request can now be saved to a file. Which encoding is selected here is of secondary importance.

A key pair and a certificate request are now generated. This must be sent to the certification authority in the next step.

Sending the certificate request to the certification authority

Regardless of how the certificate request was generated (Windows, Linux, etc.), the CSR file can now be sent to the appropriate certificate authority.

This can be done from any Windows computer in the Active Directory forest, but the executing user must have the enroll privilege on the target certificate template.

certreq -submit {certificate request}.req

For certificate requests that were not created with the Microsoft MMC, no information about the certificate template is available. This information must be provided manually during the request:

certreq -attrib "CertificateTemplate:{name-of-the-certificate-template}" -submit {certificate-request}.req

One is now prompted to select a target Certification Authority.

The certificate request is then sent to the certification authority. If the certificate template is configured in such a way that the request must first be checked by a certificate manager, you will be notified of this fact and will not receive a certificate back for the time being. It is important to note the issued RequestId, as this is required to retrieve the certificate.

Collecting the issued certificate from the certification authority

After the certificate has been issued by a certificate manager, it can be retrieved from the certification authority with the following command.

certreq -reqtrieve {Request-ID}

Again, you have to select the target Certification Authority.

Afterwards, the certificate can be saved as a file.

Connecting the issued certificate with the private key

This step again depends on the target system (Windows, Linux). The issued certificate must now be associated with the previously created private key before it can be used. Administrator rights are required for this if the certificate request was created in the machine context.

certreq -accept {certificate}.cer

Binding the certificate to the application

The issued and installed certificate must now be bound to the target application. This step depends on the target application (for example, IIS, Apache, NGINX). For the Network Device Enrollment Service (NDES) here is an example.

Generating a RFC 2818 compliant certificate request for SSL certificates