Generating an RFC 2818 compliant certificate request for SSL certificates

With the Chromium project and products based on it such as Google Chrome and Microsoft Edge, Google has moved to enforcing RFC 2818 , which was adopted in 2000, and to no longer trusting certificates that no longer fulfill the RFC.

For us, the following sentence is highly significant:

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

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

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 certification 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 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 enrollee 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 certification authority in compliance with RFC 2818:

• If the subject is empty, the Subject Alternative Name extension is marked as critical, since it contains the only way to determine the identity.
• If a Common Name exists within the Subject, the Subject Alternative Name extension is marked as not critical 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 certification authority.

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

certreq -submit {Zertifikatanforderung}.req

certreq -attrib "CertificateTemplate:{Name-der-Zertifikatvorlage}" -submit {Zertifikatanforderung}.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 down the RequestId that is displayed, 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 {Zertifikat}.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 .

Related links:

• Issue 308330: Remove support for common names in certificates; only support Subject Alt Names (Chromium Project)
• RFC 2818 - HTTP Over TLS (Internet Engineering Task Force)