Chromium - Uwe Gradenegger

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.

Google Chrome reports error code "ERR_SSL_PROTOCOL_ERROR" when calling a web page

Assume the following scenario:

A web page is accessed using Google Chrome.
The connection setup fails with the following error message:

This website cannot provide a secure connection
test.intra.adcslabor.com has sent an invalid response.
Try to run the Windows network diagnostics.
ERR_SSL_PROTOCOL_ERROR

Inspect TLS traffic with Wireshark (decrypt HTTPS)

When troubleshooting, it can be very helpful to view encrypted SSL connections in order to inspect the messages within. There is a relatively simple way to do this with Wireshark.

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.

What to consider when applying Microsoft Security Baselines?

In the context of hardening measures, it is a good idea to use the Microsoft published Microsoft Security Baselines to your own server landscape.

This will inevitably have an impact on PKI components. The following is an overview of the expected effects and countermeasures.

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.

Configuring a Secure Socket Layer (SSL) Certificate Template for Web Server

Below is a guide to configuring a web server template with recommended settings.

Generating a 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