0

We ran PCI DSS External Vulnerability Scan on our website and the scan failed with many vulnerabilities, all of them are PCI severity: Low except one medium and another one high.

The high one is:

Threat: An SSL Certificate associates an entity (person, organization, host, etc.) with a Public Key. In an SSL connection, the client authenticates the remote server using the server's Certificate and extracts the Public Key in the Certificate to establish the secure connection. The authentication is done by verifying that the public key in the certificate is signed by a trusted third-party Certificate Authority. If a client is unable to verify the certificate, it can abort communication or prompt the user to continue the communication without authentication.

Impact: By exploiting this vulnerability, man-in-the-middle attacks in tandem with DNS cache poisoning can occur. Exception: If the server communicates only with a restricted set of clients who have the server certificate or the trusted CA certificate, then the server or CA certificate may not be available publicly, and the scan will be unable to verify the signature.

Solution: Please install a server certificate signed by a trusted third-party Certificate Authority. Result: Certificate #0 CN=132123-server1 unable to get local issuer certificate

And I have no idea how to solve this issue to pass this point when I rerun the scan. is there any steps I can follow?

Notes:
The server is IIS 8
Website is using SSL wildcard from godaddy.

Amr Elgarhy
  • 243
  • 3
  • 7
  • 22
  • What's the URL in question? – EEAA Jun 16 '17 at 23:19
  • What URL? you mean the website URL? I can't share it unfortunately. – Amr Elgarhy Jun 16 '17 at 23:22
  • 1
    Yes, that's what I mean. Some problems are solved much more easily with real information. Your question as it stands is quite vague and the information you've provided is contradictory. – EEAA Jun 16 '17 at 23:24
  • Hmm, I understand your point, I thought may be someone faced the same issue, got the same result and can give me a list of generic steps to follow. – Amr Elgarhy Jun 16 '17 at 23:32
  • Well, this is when you get to dig into TLS troubleshooting tools. Check out OpenSSL s_client. Verify that the cert your server is using is actually as expected. – EEAA Jun 16 '17 at 23:37
  • (@EEAA) When using `s_client` be sure to specify `-servername whatever` if your server needs SNI to present the correct cert, which IIS may; it is not automatic. And use `-showcerts` to check the full chain not just the leaf cert; your quote suggests a problem there. I'm guessing you changed the CN for posting; if as quoted (not a FQDN) it means you aren't using an actual GoDaddy (or other public CA) cert. – dave_thompson_085 Jun 17 '17 at 08:27
  • @EEAA and dave thank you for your help, my problem that I have no Idea of these tools and was hoping if you share with me any article step by step a beginner like me can follow, anyway for now I will try to research about what you mentioned here, may be I get a step further, many thanks – Amr Elgarhy Jun 17 '17 at 19:48
  • 1
    I could solve your problem in 5 minutes if I had the domain. – EEAA Jun 17 '17 at 20:06
  • I ran the s_client command and it gave me in the result last line: Verify return code: 20 (unable to get local issuer certificate) – Amr Elgarhy Jun 17 '17 at 22:15

1 Answers1

1

Basically the error response you got from the SSL signature verification is:

unable to get local issuer certificate

The issuer is the signing authority that received your certificate signing request (CSR), signed it, and returned you the server certificate (which you installed along with the private key that you generated with the CSR). The server certificate is a PEM file with a .cer or .crt extention. It is a text file with certificates encoded in blocks between:

-----BEGIN CERTIFICATE-----

     gibberish not copied

-----END CERTIFICATE-----

The error text explains:

The authentication is done by verifying that the public key in the certificate is signed by a trusted third-party Certificate Authority.

But for this verification to happen, at least one other certificate is needed, namely the certificate of the issuer, and possibly also the one of the certificate root authority (CA).

A count of 1 in grep -c BEGIN /etc/pki/tls/certs/yourserver.crt will show that, when you have such a local issuer, its certificate is not available. It takes at least 2 certificates to verify.

A scanner, such as the PCI DSS External Vulnerability Scan, needs to know about these additional certificates. They can either be well-known/built-in CA's like Verisign or Thawte, but quite possible they can be unknown, because the CA could be your company's. The canonical name (CN=), and the (missing) domain components, in your output, show that the certificate was not signed by a CA that is built-in to the scanner by its vendor.

It is common practice to append the issuer certificate and the root ca certificate (in that order) to the server certificate, as of to tell the SSL client about the trust chain.

cat issuer.cer root_ca.cer >> etc/pki/tls/certs/yourserver.crt

But this does not establish trust. The scanner, and SSL clients in general, need to have the issuer’s root CA’s certificate. If your company has its own CA, then you need to install it everywhere.

bbaassssiiee
  • 160
  • 6