Return to 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][2] we're using to generate 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 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.

Edit: 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, couldnt find any documentation on MSDN regarding SAN checking in WinHTTP

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.

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.

However, with WinHTTP's internal working, it accepts the invalid SAN (which should not happen). There seems to be no documentation on WinHTTP as to how this can be handled. Because this is internal implementation of WinHTTP.

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

Edit: 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, couldnt find any documentation on MSDN regarding SAN checking in WinHTTP

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][2] we're using to generate 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 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.

Edit: 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, couldnt find any documentation on MSDN regarding SAN checking in WinHTTP

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.

However, with WinHTTP's internal working, it accepts the invalid SAN (which should not happen). There seems to be no documentation on WinHTTP as to how this can be handled. Because this is internal implementation of WinHTTP.

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

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.

However, with WinHTTP's internal working, it accepts the invalid SAN (which should not happen). There seems to be no documentation on WinHTTP as to how this can be handled. Because this is internal implementation of WinHTTP.

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

Edit: 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, couldnt find any documentation on MSDN regarding SAN checking in WinHTTP