PCI Compliance Scan Certificate errors

Description

This article shows some of the PCI Scan Certificate errors related to PCI Compliance and the explanation or the way to resolve them.

Resolution

Here's some of the errors:

  • SSLv2 Supported
    SonicWall UTM appliances do not support SSLv2.  This error could be due to a device, like a webserver, behind the SonicWall using SSLv2.
  • SSL Weak Encryption Algorithms
    This error could be due to a device, like a webserver, behind the SonicWall using less than 128 bit encryption. SonicWall UTM appliances support the following cipher-suites:
Protocol VersionCipher SuiteEncryption bit
SSLv3AES256-SHA256
SSLv3DES-CBC3-SHA168
SSLv3AES128-SHA128
SSLv3RC4-MD5128
SSLv3RC4-SHA128
TLSv1AES256-SHA256
TLSv1DES-CBC3-SHA168
TLSv1AES128-SHA128
TLSv1RC4-MD5128
TLSv1RC4-SHA128
  • SSL certificate is signed with weak hash function

All SonicWall devices with the latest SoniOS firmware, Gen4 and Gen5 - both SonicOS Standard and Enhanced - use SHA1 in the SonicWall self-signed certificate. This error could be due to a device behind the SonicWall using MD5.

If it is determined that this vulnerability is found in the SonicWall, then it could be due to importing a 3rd party certificate with a weak hash.

In rare cases a SonicWall self-signed certificate with the latest firmware could have MD5. In such cases the reason could be upgrading from an older firmware hasn't still made SonicWall use SHA1 hash. The suggested workaround would be to change the Certificate Common Name (CN) under System > Administration page and restart. This will force the SonicWall to re-generate the self-signed certificate and use SHA1.

  • SSL Certificate is Self-Signed

    All SonicWall UTM appliances have an inbuilt self-signed certificate. By default, this certificate is used for HTTPS web management. It is recommended to use a certificate signed by a third party Certificate Authority (CA) like Verisign or GoDaddy. Refer these articles on how to obtain certificates from a public CA, GoDaddy and Thawte as examples:
  • SSL Certificate is Not Trusted

    This error occurs when the certificate in the HTTP web management or SSL VPN is signed by an unknown Certificate Authority (CA). In most cases this happens when the CA is private. For example, a Windows CA. Obtain a certificate signed by a public CA.
  • SSL Certificate has an IP Address as the Common Name

    The certificate used in HTTP web management or SSL VPN has IP address instead of FQDN in Common Name (CN) field. Obtain a certificate with an FQDN as its CN or Subject Alternative Name. 
  • Subject Common Name Does Not Match Server FQDN

    Obtain a certificate whose Subject Common Name (CN) or Subject Alternative Name (SAN) matches the FQDN used to access it. For example, if the scan is being done using the FQDN www.example.com, the certificate must have its CN or SAN as www.example.com or *.example.com.
  • SSL Certificate - Signature Verification Failed Vulnerability
    This error occurs when the certificate in the HTTP web management or SSL VPN is signed by an unknown Certificate Authority (CA). In most cases this happens when the CA is private. For example, a Windows CA. Obtain a certificate signed by a public CA.
  • Port 500 Remote Access Service Detected:
    This error occurs when a WANGroupVPN is enabled so port 500 will be open. You can create custom rules from WAN to WAN to limit WAN GroupVPN access to only specific Public IPs or users.

  • Port 500 Weak Encryption Ciphers identified on VPN Device
    This error occurs when WANGroupVPN ciphers are too weak. Make sure you're not using strong Encryption and Authentication algorithms for IKE and IPSec Proposals and that Default Key Provisioning is disabled.

 

  • PCI Compliance scan fails the vulnerability test while accessing the IP address 

    Usually, the PCI compliance vulnerability test fails while accessing the IP address and the same PCI compliance vulnerability test passes while accessing anything with a domain name.

Image

  

When the CSR is generated on SonicWALL, if the common name is set to domain, then the PCI compliance vulnerability test will only pass for domain and not the IP addresses.

 

 

Image

  So, as far as the cert is associated with the domain name, it will fail for the IP address which is the normal behavior.

Related Articles

  • Firewall logs show frequent probe status changes after upgrade
    Read More
  • SSO Agent 4.0: Installation, Configurations, and troubleshooting
    Read More
  • CFS blocks valid sites due to incorrect 64: Not Rated tag
    Read More
not finding your answers?
was this article helpful?