4

Little bit of context, we are seeing this finding a lot. We use wildcard certificates on public facing websites.

The finding is titled:

"X.509 Certificate Subject CN Does Not Match the Entity Name"

Below, I have added further details about the report on the finding from the scan (in Block quotes) and I have provided my comments underneath. I hope that someone with more experience may provide feedback to ensure my thought process is valid and that this is in fact a false positive.

From research and reviewing the indicators I believe it to be a false positive for the following reasons (please note, I have changed the domain name):

Subject CN *.somedomain.com does not match target name specified in the site.

Site refers to the name given to the asset within the scan configuration. In this case all assets are scanned by their IP address. The IP address doesn't match the CN.

Subject CN *.somedomain.com could not be resolved to an IP address via DNS lookup

Given that wildcard certificates are used, wildcard domain will not resolve with a DNS look up.

Subject Alternative Name *.somedomain.com does not match target name specified in the site.

The IP address is not listed as an alternative name. No match.

Subject Alternative Name somedomain.com does not match target name specified in the site.

Once again, IP is not listed and therefore will not match the domain name.

Keep in mind, that if the site is ever visited from a valid url, for example, client1.mydomain.com the certficate is valid and works as expected. I just believe that this is mainly due to the reasons listed above and given the nature of wildcard certificates.

Any comments appreciated and also if there are any other methods I may check for validity to provide assurance to my team would be greatly appreciated.

Thank you for your input.

ximaera
  • 3,395
  • 8
  • 23
user146316
  • 43
  • 1
  • 1
  • 3
  • I think the question is missing important context. What are you scanning for, what results do you expect, what tools do you use for scanning, what is the domain name in question, what is the CN/SAN of the certificate provided... – Steffen Ullrich Jan 24 '18 at 20:31
  • I was running a network vulnerability scan using InsightVM/Nexpose, not looking for anything in particular. The CN name mismatch came up as a high finding and I believe to be a false positive based on the details of how the finding was discovered and indicated. When the site is visited via URL The certificate is valid and works as expected. It is only because the connection attempt is initiated via the IP that is causing the false positive. Importing a wildcard certificate into the Nexpose engine for validation doesn't work because it still will not match the name. – user146316 Jan 24 '18 at 21:45

1 Answers1

1

If you intend to access your site via (e.g.) IP 192.168.1.1 then you will need to have that same IP in the certificate.

Namely inside the "Common Name" and/or "Subject Alternate Name" sections.

Otherwise it will not be valid to access via that IP.

But if you don't plan on ever accessing via that IP, then you don't need the IP inside the certificate. And you don't have to care about the scanner's warning either. -- The warning is the expected result in this case. (See this SSL scan for the IP of "example.com". It also has as a warning that reads "The certificate doesn't match hostname". And rightfully so, since the IP is not listed inside the cert.)

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • Exactly my thought process! Thank you for the link! That is exactly what we are seeing. I can use that to demonstrate my point and tag it as a false positive. – user146316 Jan 26 '18 at 18:40