Skip to main content
Security Posture Management
Continuous Monitoring
Vendor Risk Management
Trust Management Hub
Cyber Insurance
National Cybersecurity

Certificate Name Mismatch Findings

Marta Castro

When Certificate Name Mismatch findings for TLS/SSL Configurations are assessed, the Bitsight platform checks all publicly queried hostnames.

To reassess the findings, we need to confirm the DNS pair that shows the asset is targeted by the canonical name (CNAME) since there’s no way to tell if a scan is done on a CNAME. We can’t act on assets used as a "front door" because it could lead to security risks and set a bad precedent.

When a CNAME is scanned, a rule to skip checks on the Common Name and Subject Alternative Name fields for the relevant domains can be implemented. Reach out to Bitsight Support to set this up.

As a result, findings related to Certificate Name Mismatch are cleared and the overall rating can be recalculated. This ensures the scan results accurately reflect the CNAME configuration without unnecessary warnings. While these findings are removed, all other TLS/SSL Configuration findings continue to be flagged as usual.

  • July 15, 2025: Referenced the finding for more information.
  • January 28, 2025: Published.

Related articles

Feedback

1 comment

Date Votes
  • Alan [CORP]
    Edited

    TL;DR: In my opinion, Bitsight has created a problem that does not exist.

    Despite this article, Bitsight support states that you must install a SAN that covers all possible FQDNs, or they will not remove the penality.

    Consider these example services. In real-world practice, the user/browser/application will only connect and perform SSL cert checks for the bolded CNAME FQDNs.  The IP addresses that are eventually resolved by a chain of DNS records is returned to the OS.  The FQDNs in the chain are not evaluated for certificate validity because the browser/app is using the original FQDN and the final IP address.

    ServiceA is manually switched between a primary and backup circuit. It's not as fancy as load balancing. But it's a quick (and free) DNS fix to route around outages. The FQDNs of the (A) records are never presented to a browser.

    ServiceB is running at a site with non-static IP address. Dynamic DNS service will continually update so that you can use a friendly FQDN. It's not possible to make a SAN cert that includes a domain outside of your control.

    ServiceC is hosted on and external platform. It's not possible to make a SAN cert that includes a domain outside of your control.

    ServiceD points to a friendly CNAME of a provider, which then resolves to another CNAME or A record. Now we have multiple FQDNs, none of which are in domains under our control.

    Where is the risk of _not_ publishing certs for every FQDN along the way?  The browser or application will never be presented with the string of FQDNs during DNS resolution. Thus, there will be no certificate mis-match in the real world.

    ;;example  A Records
    server1.domain.tld.    1    IN    A    203.0.113.1; primary ckt handling serviceA
    server2.domain.tld.    1    IN    A    198.51.100.2; backup ckt handling serviceA

    ;; example CNAME Records
    serviceA.domain.tld.    1    IN    CNAME    server2.domain.tld.; manually set to active server
    serviceB.domain.tld.    1    IN    CNAME    dyn-serviceB.some-dynamic-dns-provider.tld.
    serviceC.domain.tld.    1    IN    CNAME    random-host123.some-hosting-provider.tld.
    serviceD.domain.tld.    1    IN    CNAME    domain-tld.other.tld.; this points to a customer-tagged CNAME
    domain-tld.other.tld.    1    IN    CNAME    load-balancer.us-other.tld.; this points to an A record in a different domain

    0

Please sign in to leave a comment.