AnsweredAssumed Answered

Using our own PKI should be considered as a false positive "By design"

Question asked by Phil Provost on Mar 19, 2013
Latest reply on Mar 28, 2013 by q-community



We have multiple PKIs, one of which is used to and included in a PCI perimeter.

Whenever we run a PCI compliance scan, we get systematically two QID which Qualys UNTIL now REFUSED TO CONSIDER AS true false positives.


We recently involved the PCI QSA we contracted with to do blank certification testings and they confirm our position: "these QIDs are in the studied case truly false positives).


Until now, Qualys answers are quite partial and not conform to the PCI statements. Let s discover the case:


A scan is run on the concerned IPs. 2 QID a systematically revealed;


QID 38173  SSL Certificate - Signature Verification Failed Vulnerability



QID 38169 : SSL Certificate - Self-Signed Certificate


However we truly consider these two as fault positives considering:


1-      The involved scanned  SSL service is used by a small set of dedicated enterprise laptops only. These  laptops are owned and maintained by the company. This SSL service is NOT a public service inthe sense that no external entity or third party has any usage of that  service.


2-      The involved scanned SSL service is based on mutual authentication (i.e. the server authenticates the client and the client authenticates the server relying on the same private PKI).


3-      Our certificates are managed by our internal PKI. Our PKI is fully part of the PCI DSS scope of assessment, this scope has been validated by our QSA.


4-      The server certificates are signed by a sub CA of our Root CA. (the resulting  certicate chain is trusted: server-Cert->subCA->RootCA)


5-      The client certificate is signed by a sub CA of our Root CA. (the resulting certicate chain is trusted: user-Cert->subCA->RootCA)


6-      The Root CA certificate is installed on the involved servers and on the concerned and dedicated enterprise standardized laptop systems.


7-      The VPN infrastructure operates a mutual authentication service:

   1. The client checks the server certificate and validates that it is  signed by the Root CA (whose certificate is installed in the laptop)

   2. The server checks the client certificate and validates that it is signed by the Root CA (whose certificate is installed in the server)

   3. In case a certificate is deemed to be invalid, the mutual authentication fails.


The statements made in QID 38173 are incorrect:




“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.”


This explanation is partial. We operate a mutual authentication between the server and the dedicated small set of "client laptops" that use that SSL service ; i.e. the server authenticates the client (as well as the client authenticating the server).



“By exploiting this vulnerability, man-in-the-middle attacks in tandem with DNS cache poisoning can occur.”


This statement is partially incorrect. The same vulnerability exists whether we use our own secure PKI or a third-party PKI. A MITM attack could

succeed if the hacker could compromise the CA (our CA or the third-party CA). Our CA is secure, respects our security policy, is segmented from

other operational systems, and it is verified by our QSA as it is fully included in our PCI scope of assessment.


i.e. the origin of the certificate (whether it is signed by our own CA or by a "trusted" third-party CA) does not impact the security level of our SSL





“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.”


In our case, we are in this situation indeed.


Based on these facts, we reinforce the fact that Qualys should not consider these as a false positive, and should allow the upload the private certificate chain in the involved Qualys scanners to solve the case raised by these two QIDs.


any help on that front is very welcome...(note that other ASVs recognize that configuration as we do).