WinHTTP and python requests package, fail to validate certificate containing valid CN but invalid SAN

Question

We're using WinHTTP to send API calls from our client. Now according to Common Criteria, FCS_TLSC_EXT.1.2 assurance activity Test 2, if certificate contains a valid CN (common name) but invalid SAN(Subject Alternate Name), the connection should fail.

Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type.

tool we're using to generate a certificate with valid CN but invalid SAN.

However, with WinHTTP and python requests package, they accept the invalid SAN (which should not happen). There seems to be no documentation on WinHTTP as to how this can be handled. this is internal implementation of WinHTTP.

Internet explorer also fails this test and accepts the connection. However chrome does deny the connection and confirms that the certificate is invalid (which is the required behavior):

The test fails with python's request library as well.

We are looking for some way if this can be altered to check the issue. Or is this us only facing the issue?

Since both python and windows libraries are used commonly, is this behavior common? Has anyone else experienced this issue?

I want to know if this is how WInHTTP implements SAN check, or is it just our implementation. Also, I couldn't find any documentation on MSDN regarding SAN checking in WinHTTP.

Answer 1

First, the issue is not about valid CN vs. invalid SAN but about a CN matching the domain vs. a SAN not matching the domain. A non-matching SAN is still a valid SAN entry.

The rule according to RFC 6125 is that the CN MUST not be checked if there is a SAN DNS entry. Additionally CN is deprecated for a long time and RFC 6125 explicitly adds that the CN MAY be checked if no appropriately typed SAN records exists and does not require it. Still, most implementations check both SAN and CN. Only Chrome does not check the CN at all since a while now. This is the primary reason the issue seems to be fixed with Chrome but not with others and this actually violates "Verification using the Common Name is required for the purposes of backwards compatibility" from FCS_TLSC_EXT.1.2.

... and python requests package, they accept the invalid SAN

As far as I can see the current version of requests ultimately uses the functionality of this ssl module in Python to validate the hostname. The code here in the latest version of Python explicitly makes sure that CN is only checked if no SAN DNS names exist. Of course, this might vary with the unknown version of Python and requests you are using.

I want to know if this is how WInHTTP implements SAN check, or is it just our implementation

While I cannot be sure because I don't know your implementation the chance is high that at least the version of WinHTTP your are using implements CN checking additionally to SAN - at least by default. This is similar to many other implementations although it does neither match RFC 6125 nor the older RFC 2818.