This article includes information about disputing the "SSL - Certificate Hostname Discrepancy" vulnerability for PCI compliance, as well as the possible causes of this vulnerability, the related PCI requirement, and the procedure to dispute this vulnerability.
This vulnerability can be caused by either of the following scenarios:
- Host was scanned via IP address instead of fully qualified domain names (FQDN)
- FQDN does not match certificate CN or SAN
In most cases, using the FQDN in the scan configuration will prevent this vulnerability from showing at all.
Note: These PCI requirements come from the PCI ASV Program Guide, section 5.5, p. 16.
In addition to providing all external-facing IP addresses, you must also supply all FQDN and other unique entryways into applications for the entire in-scope infrastructure. This includes, but is not limited to:
- Domains for all web servers
- Domains for all mail servers
- Domains used in name-based virtual hosting
- Web-server URLs to "hidden" directories that cannot be reached by crawling the website from the home page
- Any other public-facing domains or domain aliases
If you have deployed load balancers, the scan may only see part of the configuration beyond the load balancer. In these cases, the following applies:
- Localized Load Balancers: The ASV must obtain documented assurance from the scan customer that the infrastructure behind the load balancer(s) is synchronized in terms of configuration.
- External Load Balancing Services: The customer should implement a configuration to ensure that all IP addresses and ranges provided are successfully scanned.
In the case of cloud services such as Amazon Web Services (AWS), Microsoft Azure, Incapsula, etc., the FQDN still needs to be provided in the scan configuration to ensure that the web application is scanned.
If the customer is using a service such as AWS, ensure that you use your DNS name rather than the instance name in the scan config.
If you need to dispute this vulnerability, follow these guidelines.
- Verify that the FQDN properly resolves to the host using an outside source such as www.sslshopper.com or www.digicert.com/help/. These could also identify potential certificate problems as well.
Example: host1.foo.com resolves to 192.168.38.4
- In the case of a load balancer, provide all expected IP resolutions of the FQDN. An attestation that hosts behind the load balance are in sync is also required.
- For a DR host, a statement should be provided that indicates the host is part of a backup or failover environment where the IP is needed to be used due to DNS not actively pointing to the host.
- A service provider may scan by IP if the web applications are out of scope and an attestation of such is provided in the dispute comments.