PCI ASV Certification: How It Differs From PCI Certified and PCI Compliant
PCI ASV certification explained: how it differs from PCI certified and PCI compliant, who validates each, and how to verify a PCI approved scanning vendor.
• ASV scan TLS failures come down to three fixable causes: old protocols, weak ciphers and untrusted certificates.
• SSLv2, SSLv3 and TLS 1.0 fail an ASV scan automatically. Allow TLS 1.2 and 1.3 only, and disable TLS 1.1 as well.
• Weak ciphers such as RC4, 3DES, export and NULL suites can fail a scan even when TLS 1.2 is enabled.
• Certificates must be CA-signed, unexpired, complete in chain and valid for every host and IP the scanner reaches.
• Test from outside your network with testssl.sh or nmap before you request a rescan.
ASV scan TLS failures are among the most common reasons merchants and service providers fail their quarterly PCI scans, and nearly all of them are fixed with targeted server configuration changes. You closed the open ports and the report still says fail. The remaining line items read like “TLS Version 1.0 Protocol Detection” or “SSL Certificate Cannot Be Trusted”, and each one means an internet-facing system exposes a cryptographic weakness your acquirer will not accept. These findings are rarely a judgement call. The server either offers a deprecated protocol, a weak cipher or a bad certificate, or it does not.
They linger because servers collect old settings: a legacy protocol left on for one old client, a default cipher list nobody revisited, a self-signed certificate on a forgotten admin port. This guide explains why each category of ASV scan TLS failures fails, then gives copy-ready fixes for Nginx, Apache, IIS and Cloudflare and a way to verify before you pay for a rescan. If your failure is about exposed services or a finding you believe is wrong, start with open ports and PCI ASV scan failures or disputing a false positive. For the wider picture of why scans fail, see why an ASV scan fails.
ASV (Approved Scanning Vendor): an organisation approved by the PCI Security Standards Council to run the external vulnerability scans PCI DSS requires. Only an ASV scan counts for compliance. See what an ASV scan is.
TLS (Transport Layer Security): the protocol that encrypts data between clients and servers. PCI DSS expects only strong, current versions on internet-facing systems.
Early TLS: SSL 2.0, SSL 3.0 and TLS 1.0. The ASV Program Guide treats a service that supports them as an automatic failure.
Cipher suite: the bundle of algorithms (key exchange, encryption, and integrity) a client and server agree on for a connection.
Forward secrecy: key exchange (ECDHE or DHE) that stops recorded traffic being decrypted later if the server key leaks.
Certificate chain: your certificate plus the intermediate certificates that link it to a Certificate Authority (CA) the client trusts. The server must send the intermediates.
Almost every TLS failure falls into three groups: an old protocol is still enabled, a weak cipher is still offered, or a certificate is expired, untrusted or mismatched. Find your finding in the table, apply the fix, then verify.
Scanners’ word findings differ, but they map to the causes below.
Finding (as scanners word it) | Why it fails | Fix |
|---|---|---|
SSLv2, SSLv3 or TLS 1.0 supported | Early TLS. Exposed to POODLE and BEAST-class attacks. Automatic failure in the ASV Program Guide. | Allow TLS 1.2 and 1.3 only |
TLS 1.1 supported | Deprecated by the IETF. Scanners often flag it, and ASVs may require removal. | Disable it; TLS 1.2 and 1.3 only |
RC4, NULL, export or single-DES ciphers | Broken or deliberately weak encryption. | Remove from the cipher list |
3DES or 64-bit block ciphers (Sweet32) | Block collisions on long sessions. Typically scores at or above the CVSS 4.0 fail line. | Remove 3DES; use AES-GCM or ChaCha20 |
Weak Diffie-Hellman (under 2048-bit) | Logjam-style downgrade and precomputation attacks. | Use ECDHE, or 2048-bit or larger DH parameters |
Expired certificate | Clients cannot trust it; the scanner records a failure. | Renew and deploy on every endpoint |
Self-signed certificate | Not issued by a trusted CA. | Install a CA-signed certificate |
Hostname mismatch | The certificate does not cover the name or IP the scanner connected to. | Reissue with every hostname in the SAN list |
Incomplete chain | Intermediate certificates are not sent. | Serve the full chain |
Weak signature or key (SHA-1, RSA under 2048) | Forgeable or brute-forceable. | Reissue with SHA-256 and RSA 2048+ or ECDSA P-256 |
Run a PCI ASV scan and see exactly which protocols, ciphers and certificates fail.
The ASV Program Guide marks any component that supports SSL or early TLS as an automatic failure, and it also fails strong cryptography offered alongside them because of downgrade attacks. Allow TLS 1.2 and 1.3 only.
TLS 1.0 was standardised in 1999. Its weaknesses, including exposure to POODLE and BEAST-class attacks, cannot be configured away: the protocol itself is the problem. It is not enough to prefer TLS 1.2. If the server still negotiates TLS 1.0 when a client asks, the scan fails. Which versions are acceptable:
• TLS 1.3: the current standard. Enable it wherever your software supports it.
• TLS 1.2: the minimum to aim for, with strong cipher suites.
• TLS 1.1: deprecated by the IETF and often flagged. The PCI Council has indicated that its mere presence isn’t an automatic failure when it isn’t protecting cardholder data, but ASVs differ, so disable it.
• TLS 1.0 and SSL 2.0 or 3.0: disable them. These are automatic failures.
If a system is genuinely not susceptible to a flagged vulnerability, an ASV may accept a documented exception. Do not plan around that. Turning the protocol off is faster than defending it. For the requirement context, see PCI DSS v4.0 ASV scanning. Before you disable TLS 1.0, find the clients that still use it. Older point-of-sale terminals, legacy payment applications and embedded systems may still negotiate it. Identify them first, plan their upgrade or replacement, then switch the protocol off. That sequence fixes the scan without breaking payments.
Any finding scored CVSS 4.0 or higher fails the scan, and RC4, DES, 3DES, export, NULL and anonymous cipher suites all meet that bar. Offering even one as a fallback is enough to fail.
During the TLS handshake the client and server negotiate a cipher suite. If your server advertises a deprecated suite, an attacker can try to force a downgrade to it. That is why a scanner flags every weak suite your server will accept, not only the one it prefers. These cipher categories fail an ASV scan:
• RC4: a stream cipher with well-documented weaknesses.
• DES and 3DES: too weak for modern use. 3DES is also the source of the Sweet32 finding.
• Export-grade ciphers: deliberately weakened decades ago and exploitable through FREAK and Logjam.
• NULL ciphers: no encryption at all.
• Anonymous key exchange: no server authentication.
The fix is an allowlist, not a blocklist. Name the strong suites you accept (ECDHE key exchange with AES-GCM or ChaCha20) and drop everything else. Weak ciphers usually survive because a default cipher string was never replaced. The Mozilla SSL Configuration Generator produces a current allowlist for most server software.
A certificate fails the scan when the scanner cannot validate the server's identity: it is expired, self-signed, issued for a different name, or missing its intermediate certificates.
A certificate does two jobs: it enables encryption, and it proves the server is who it claims to be. When it cannot do the second, TLS stops protecting the user.
• Expired: the most common operational cause. Renew from a trusted CA before expiry, and automate with ACME tools such as Let’s Encrypt. Make sure renewal reloads the service, or the old certificate stays live.
• Self-signed: fine for internal systems, not for internet-facing servers. No trusted party verified it, so scanners and browsers reject it. Replace it with a CA-signed certificate.
• Hostname mismatch: the CN or SAN does not cover the name or IP the scanner queried. This often follows a migration or domain change. Reissue a certificate that covers every hostname, using a multi-SAN or wildcard certificate where needed.
The scanner connects to your IP addresses, not only your domain names. The most common surprise is a default virtual host or an old admin port serving a self-signed certificate. Every IP and port in scope must present a valid certificate or be taken out of public exposure.
Turn a failed report into a short fix list and get back to a passing scan.
Set the protocol list to TLS 1.2 and 1.3, replace the cipher list with ECDHE AEAD suites, serve a full certificate chain, then reload the service.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Set protocols in the http block so no server block or default server inherits an old list.
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/example.com/fullchain.pem; # leaf + intermediates
ssl_certificate_key /etc/ssl/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
}
sudo nginx -t && sudo systemctl reload nginx
Put these in the global or default virtual host as well as each site. TLS 1.3 needs Apache 2.4.36 or later built against OpenSSL 1.1.1 or later.
SSLEngine on
SSLCertificateFile /etc/ssl/example.com/fullchain.pem
SSLCertificateKeyFile /etc/ssl/example.com/privkey.pem
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off
sudo apachectl configtest && sudo systemctl reload apache2
IIS uses the operating system's Schannel settings. The simplest route is the free IIS Crypto tool with its PCI template. To script it, run this in an elevated PowerShell session, then reboot.
# Disable legacy protocols for inbound (server) connections
$base = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"
foreach ($p in "SSL 2.0","SSL 3.0","TLS 1.0","TLS 1.1") {
$k = "$base\$p\Server"
New-Item -Path $k -Force | Out-Null
New-ItemProperty -Path $k -Name Enabled -Value 0 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $k -Name DisabledByDefault -Value 1 -PropertyType DWord -Force | Out-Null
}
# Disable weak ciphers (names contain "/", so use the .NET registry API)
$root = (Get-Item HKLM:\).OpenSubKey("SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers", $true)
foreach ($c in "NULL","DES 56/56","RC4 40/128","RC4 56/128","RC4 64/128","RC4 128/128","Triple DES 168") {
$key = $root.CreateSubKey($c)
$key.SetValue("Enabled", 0, "DWord")
$key.Close()
}
TLS 1.2 is available on Windows Server 2012 R2 and later; TLS 1.3 needs Windows Server 2022. Test first, because older applications that call out over TLS 1.0 can break.
For proxied hostnames the scanner sees Cloudflare's edge settings, not your origin. In the dashboard go to SSL/TLS > Edge Certificates, set Minimum TLS Version to 1.2 and confirm TLS 1.3 is on. Use Full (strict) encryption mode so the origin certificate is validated too. To script the minimum version:
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/min_tls_version" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"value":"1.2"}'
Cloudflare does not protect anything the scanner can reach directly. DNS-only (grey cloud) records and an exposed origin IP are scanned as-is, so fix the origin configuration above as well. More in our Cloudflare and PCI ASV scanning guide.
The same findings appear on cloud load balancers (pick a TLS 1.2+ security policy), mail servers (SMTP, IMAPS, POP3S), FTPS and RDP. Check every internet-facing port, not only 443.
Test from outside your network, confirm old protocols are refused, confirm only strong ciphers are offered, and check the certificate on every IP and port.
# Full protocol, cipher and certificate report
testssl.sh --protocols --ciphers --server-defaults example.com:443
# Alternative: enumerate ciphers with nmap
nmap --script ssl-enum-ciphers -p 443 example.com
# Confirm TLS 1.0 and 1.1 are refused (older OpenSSL builds only)
openssl s_client -connect example.com:443 -tls1 < /dev/null
openssl s_client -connect example.com:443 -tls1_1 < /dev/null
# Mail and other STARTTLS services
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com < /dev/null
Rescan only after every in-scope endpoint passes your own external test. A fix that missed one node or one port means another failed scan.
• Fix every node. Load-balanced pools, standby servers and CDN edges must all carry the change.
• Restart, then retest. Reload the service, or reboot IIS, to make the new settings live.
• Check certificates after renewal. Auto-renewal that writes a file but never reloads the service leaves the old certificate in place.
• Cover non-web ports. Mail, FTPS, RDP and VPN portals are scanned too.
• Keep evidence. Save before-and-after test output. It helps with disputes and with the ASV report your acquirer asks for.
• Dispute only real false positives. If a finding is not exploitable in your setup, follow the false positive process.
• Know your rescan terms. Read the rescan policy before you request one.
• Plan for the next quarter. Scans repeat, so put certificate expiry and configuration checks on a calendar. See how often ASV scans are required.
ASV scan TLS failures are not random. The scanner is doing what PCI DSS asks: finding cryptographic weaknesses that put cardholder data at risk. Deprecated protocols have documented exploits, weak ciphers invite downgrade attacks, and bad certificates break the identity checks TLS relies on.
Whether it is a TLS 1.0 PCI failure, PCI ASV weak ciphers or an ASV scan certificate failure, each has a clear cause and a configuration-level fix. Work through them in order: read what the scan flagged, make the change on every endpoint, verify from outside your network, then rescan. For a wider routine, see how to pass a PCI ASV scan the first time.
Ask a scanning specialist before you rescan, so you fix the right servers and ports.
ASV scan TLS failures happen when a server supports a deprecated protocol, offers a weak cipher suite, or presents an expired, self-signed or mismatched certificate. A PCI SSC-approved scanner must report each one, and the scan cannot pass until all are fixed.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.