Link to home
Start Free TrialLog in
Avatar of Jeanette Durham
Jeanette DurhamFlag for United States of America

asked on

PCI Issue with self signed security certificate

Dear Experts,

On our PCI security scan I have 2 items I need help deciding what I should do with.
As far as getting a specific certificate for our web hosting server machine, I am ok with that. Should I do that? And if I do, does it need to point to Also, what use is the security certificate for the machine itself anyways? Do you guys suppose that maybe FTP uses it or something and that is why securitymetrics sees it?

Here is the first one:

The SSL certificate chain for this service ends in an unrecognized self-signed certificate.

The X.509 certificate chain for this service is not signed by a recognized certificate authority. If the remote host is a public host in production, this nullifies the use of SSL as anyone could establish a man-in-the-middle attack against the remote host. Note that this plugin does not check for certificate chains that end in a certificate that is not self-signed, but is signed by an unrecognized certificate authority.

Purchase or generate a proper certificate for this service.

Data Received:
The following certificate was found at the top of the certificate chain sent by the remote host, but is self-signed and was not found in the list of known certificate authorities : |-Subject :

Also, the second item really confuses me.. has it's own security certificate and it's working great. How is security metrics even seeing the certificate for the machine, and why does that matter? They aren't complaining about our other certificate for our other website on the machine?
How do you see a certificate chain? I'd like to see what they're talking about, because maybe then it'd make more sense.

And the 2nd:

SSL Certificate with Wrong Hostname
The SSL certificate for this service is for a different host.

The commonName (CN) of the SSL certificate presented on this service is for a different machine.

Purchase or generate a proper certificate for this service.

Data Received:
The identities known by SecurityMetrics are : The Common Name in the certificate is :

Thanks guys! I'm mainly looking for understanding on what these items mean and advice on what approach I should take to fix them..
Avatar of Deepin
Flag of United Kingdom of Great Britain and Northern Ireland image

you appear to have a mismatch for your SSL  - your PCI scan is scanning and resolving to however your rapid SSL certificate doe not have this name on the certificate - hence "SSL Certificate with Wrong Hostname"

Option 1  - reissue with this SAN name added

Option 2 - if you have multiple static IP address's with your broadband change your PCI scan to point to another IP address
When you request a cert you don't always put the lan host name... You use the name it will PUBLICALLY respond to... That is why you are getting the name mismatch...   IE... the server may be named, but if you go to its web page with that would be the actual common name on the cert... As was said above, a cert can have more than one common name...
Avatar of Jeanette Durham


So... when the security metrics does the scan on, it resolves the domain name back to the ip address and then somehow the machine's security certificate is linked to that ip? As far as I know, that IP address should only work for the website.. it's not the ip address of our web server machine. On their webpage they say that they are scanning our domain, and there doesn't seem to be an option to change the ip address it's scanning.

so, is it a good idea to include the lan name? Is the mismatch simply because the server name doesn't match the domain name?
Avatar of Greg Hejl
Greg Hejl
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Including the lan name is only useful if internal machines need to connect using the internal name AND need the cert to show valid... It is just as easy to do split DNS, and have the same name resolve to public IP outside and private IP on the inside...  For example our exchange servers internal name is not on the cert (at least not anymore since they changed the rules about having non publically resolvable names on certs). All mail access is done by its public name, even though its internal server name is completely different... The name resolves to our internal lan ip on the inside, and to its public ip on the outside...

As long as the name you put in the web browser matches the name on the cert, that error goes away...

And PCI will NEVER accept a self signed cert...
Ok, I'm thinking that based on what I understand.. the issue here is that the and isn't covering the other services, just the website.

The errors from PCI both say they are TCP, so I believe that means it is my remote desktop stuff they are complaining about.

So, for the remote desktop, can I use the security certificate for, perhaps? That would save me the need to buy one..
If not, or that's not the best idea perhaps, would you guys recommend just buying one for the server itself, and then somehow setting the tcp to use it?

Thanks everyone!
Actually you can provide justification for that open port and the self signed certificate, then remove the alert from your PCI Scan.

Call your PCI Scanner for how to do this.
Ok I looked up how to set the certificate for TCP, and I set it to the one. So I think I'm good. I'm going to rerun the scan. It will probably take until after 5 when it's done..

So, for the moment, I might have this fixed.

I'll come back tomorrow and if it works, close the question up and all that good stuff.

Thanks a bunch everyone!
If it is Remote Desktop port that PCI is picking up you could also try this:

You'll also want to put a HTTPS Redirect rule in your web.config to force traffic to use SSL.
Turns out the certificate was a wildcard certificate. So assigning it to the TCP service fixed it. So I'm going to go with this as the best answer. Thanks everyone for all your input and advice. I understand security certificates much better than I did before!