• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

PCI compliance fail - self signed cert on multiple ports

C

CliveK

Guest
Hi,

I am failing a PCI scan because the default self signed SSL cert is used on the following ports: 8443,995,993,465,143 & 110. See message below from McAfee regarding the scan...

"The SSL certificate you have for port 443 from RapidSSL is good. However, the SSL Self-Signed Certificate vulnerability is reported on ports (8443,995,993,465,143 & 110). Our scanner identified that self signed certificate is installed on these ports.

Recently, PCI raised the severity level for 'SSL Self-Signed Certificate' as high. PCI council states that all communication via SSL should have a certificate signed by a CA (Certificate Authority).

Below are the options you may consider to fix the issue :

1. Install a certificate from CA for applications on the port reported.
2. Remove the certificate for applications on the port that do not use/require certificate.
3. Filter access to the port that is reported."


What is the best course of action to fix this? Can I use the existing valid SSL cert for the specific domain to secure these ports? If so how do I do this? Can I remove the cert altogether from these ports or does there have to be a cert?
 
What operating system? What version of O/S? What is running on the other ports in question? Did you import the CERT into a global cert store?

I suspect you'll have to learn how to have the other ports not use the cert or block them entirely with a firewall if you don't need them available from the outside.
 
"What operating system? What version of O/S?"

Running CentOS 5.4.

"What is running on the other ports in question?"

The ports in question are running only what Plesk runs on them by default. IMAP, POP3 etc.

"Did you import the CERT into a global cert store?"

Can you explain what you mean by this? The SSL cert is installed for a specific domain name, this is the domain which is being scanned by the PCI compliance scanner.

"I suspect you'll have to learn how to have the other ports not use the cert or block them entirely with a firewall if you don't need them available from the outside."

Erm, well yeah I probably do need to learn how to have the other ports not use the cert, which is exactly why I'm asking on here how to do that, if indeed that's actually possible :)
 
Also, you can get a free CA signed certificate for a single domain (meaning it won't sign other certs) from https://www.startssl.com/ .

And their master certs are in the master certs in all the web browsers so nobody has to import a cert when they browse to your site.
 
Running CentOS 5.4.

Time to upgrade, that's quite a number of revisions behind. Current is 5.8.

The ports in question are running only what Plesk runs on them by default. IMAP, POP3 etc.

You're going to need to isolate EXACTLY which daemon runs each port. You'll need the name of that daemon so you can study it. This isn't a Plesk problem, it's a generic Linux problem.

The SSL cert is installed for a specific domain name, this is the domain which is being scanned by the PCI compliance scanner.

So, you imported this cert via the Plesk control panel?

I probably do need to learn how to have the other ports not use the cert, which is exactly why I'm asking on here how to do that, if indeed that's actually possible :)

You start by identifying what is driving each port in your installation. Then go study how that software uses certificates. Once again, it isn't Plesk answering those doors when your scanner knocks. It's some generic Linux software that Plesk is taking advantage of. So stop thinking Plesk and start thinking Linux daemons. You may have to go to a support group for that software to get your answer.

Before you start that process, you determine if you actually use all those ports and block any of them at the firewall that you don't need. That shortens the process. Actually, you should do that just for general security. Any port not offered to the world is one that can't be hacked upon.

Here's some good reference links:

http://www.mysql-apache-php.com/important_linux_ports.htm

Or you could just go get a signed cert and get it over with.
 
Thanks for the detailed reply.

"Or you could just go get a signed cert and get it over with"

I've no problem doing this at all. My only question is do I need to get a server wide SSL cert to do this? I already have an SSL cert which has been installed via the plesk panel for a specific domain. I assume I cannot use this SSL cert to secure these ports (even if its only securing the ports for this specific domain)?

Do I need to install a server wide SSL cert and this will then secure these ports regardless of domain? In this case if I purchase this server wide SSL cert should the common name just be the hostname of the server? (i've only ever installed SSL certs for specific domains so I'm not sure how this works.

Thanks.
 
Do I need to install a server wide SSL cert and this will then secure these ports regardless of domain? In this case if I purchase this server wide SSL cert should the common name just be the hostname of the server? (i've only ever installed SSL certs for specific domains so I'm not sure how this works.

Thanks.

Is your cert self signed as you stated above? I think that it being self signed is what your vulnerability scanner is complaining about. I suspect the cert from startssl will do the trick assuming your vulnerability scanner has their master cert in it's store. A question for McAfee support.

I'm not coming from a place where I've solved these specific problems so I can't be any more detailed. But it looks like you have a self signed cert that is causing the vulnerabilty scanner to cough up a problem report.

You might also be able to ask McAfee what the scanner is telling you and ask if it's assuming your running a Windows server. There might be a different template for scanning Linux boxen. Dunno.

Have you run nmap against this machine? Is McAfee complaining about the list of ports available in nmap? If so, the scan may be making some invalid assumptions about services on unix. McAfee has always been a Windows centric company so it would not surprise me.
 
I think they have a stupid scanner. One of the ports they mention is 110. To my recolleciton, pop3 has never had any ability to support a certificate.
 
I think that it being self signed is what your vulnerability scanner is complaining about.

Yes this is exactly the problem. Again, my question is how to resolve this?

Can I turn the certificate off for these ports and if so how?

Can I use the existing CA validated SSL certificate which is installed for a specific domain to protect these ports and if so how?

Or do I need to install a new SSL certificate at the server level (not for a specific domain), and if so do I just use the server hostname as the common name for the SSL certificate?

I think they have a stupid scanner.

Every PCI sscanner uses exactly the same rules as defined by the PCI Security Council.
 
Yes this is exactly the problem. Again, my question is how to resolve this?

Can I turn the certificate off for these ports and if so how?

Can I use the existing CA validated SSL certificate which is installed for a specific domain to protect these ports and if so how?

Or do I need to install a new SSL certificate at the server level (not for a specific domain), and if so do I just use the server hostname as the common name for the SSL certificate?



Every PCI sscanner uses exactly the same rules as defined by the PCI Security Council.

Say what you want. It's complaining of an unsigned cert on a port that can't possibly use ANY cert.

Certificates in Plesk are assigned to IP addresses. First, move the site to it's own IP address. Then import a new signed cert for that domain. Then go to the IP Address panel and assign the new cert to the new IP address that you just put it on.
 
Certificates in Plesk are assigned to IP addresses. First, move the site to it's own IP address. Then import a new signed cert for that domain. Then go to the IP Address panel and assign the new cert to the new IP address that you just put it on.

The site already has its own dedicated IP address and the CA signed cert is already installed and working for this IP address/domain.

If you look at the message from McAfee the very first thing they say is:
The SSL certificate you have for port 443 from RapidSSL is good.

So, the CA signed cert installed for this IP address/domain does not cover the ports 8443,995,993,465,143 & 110, instead these ports for some reason continue to use the default Plesk self signed certificate.

Anybody any idea how to make the CA signed cert work for these ports instead of the default Plesk self signed cert? Or is there any other way to solve this?
 
Thanks for all your replies philb but they aren't really answering my questions unfortunately.

As I've said before, what I need to know is:

Can I turn the certificate off for these ports and if so how?

Can I use the existing CA validated SSL certificate which is installed for a specific domain to protect these ports and if so how?

Or do I need to install a new SSL certificate at the server level (not for a specific domain), and if so do I just use the server hostname as the common name for the SSL certificate?

The only way I can proceed is to get answers to these specific questions. Any help is much appreciated!
 
Thanks for all your replies philb but they aren't really answering my questions unfortunately.

As I've said before, what I need to know is:

Can I turn the certificate off for these ports and if so how?

NO. Some of these services don't use a cert. So you can't turn off something it doesn't use. And since you can't, there's no point in pursuing this path. But lets say you could fix all of them but POP3. Doesn't that still leave you broken?

Can I use the existing CA validated SSL certificate which is installed for a specific domain to protect these ports and if so how?

NO. POP3 DOESN'T USE A CERT!!!!! Your vulnerability scanner is BROKEN!!!

Or do I need to install a new SSL certificate at the server level (not for a specific domain), and if so do I just use the server hostname as the common name for the SSL certificate?

The only way I can proceed is to get answers to these specific questions. Any help is much appreciated!

Install a signed cert in place of the global self signed cert and get on with life. You seem to be under the impression that you can fix the results of an idiotic brain dead scanner by fixing each thing it's wrongly complaining about. I doubt it.

If you can't get rid of the brain dead vulnerability scanner and you can't fix services that already don't use a cert to not use a cert, the SELF SIGNED CERT is the only thing you can change. Get rid of it.

I don't know any more ways to say it. I'm done.
 
Last edited by a moderator:
Some of these services DON'T USE A CERT

Hmmm not really getting anyway here! Here's an idea, lets just worry about the ports listed above that you think DO use a self signed cert and forget about the ones that you think don't, now just assume I've repeated my questions again.

Install a signed cert in place of the global self signed cert and get on with life.

As I've said several times, I'm just asking how to do this (if indeed it will actually solve the problem), I already have a CA signed cert installed for the domain which is being scanned, and at the risk of repeating myself for about the 5th time...I'm asking do I need to install another CA cert at the server level and how is this done? And if I do this will it protect the ports above for every domain on the server?
 
Dude. I gave you a course and you don't want to take it. I even told you where to get a signed cert to replace the self signed cert for FREE. What are you waiting for? There's no guarantees. Nobody here has your exact answer. You'll have to try things to see if they work. It's called hacking. Try things until you find the combination that works. If you wait for an exact answer you'll never get it.

If your question has evolved to "How do I replace the master self signed cert with a CA signed cert, I suggest you open a new thread because anyone who looks at this one will just shake their head and move on.
 
I gave you a course and you don't want to take it

No, you didn't. You gave extremely vague general advice which doesn't really solve the problem, presumably because you don't know the answer.

I even told you where to get a signed cert to replace the self signed cert for FREE

This is completely irrelevant, I am happy to purchase a new cert, its not an issue.

What are you waiting for? There's no guarantees. Nobody here has your exact answer

Speechless.

You'll have to try things to see if they work. It's called hacking

When something as important as PCI compliance is at stake I'd prefer to get solid advice from someone who knows what their talking about instead of stabbing in the dark.

I suggest you open a new thread because anyone who looks at this one will just shake their head and move on

By this I assume you mean that a certain level of knowledge and expertise is a pre-requisite before gaining the right to ask a question on these forums. Well, I apologise for not having the required knowledge and I'll move onto somewhere else where someone may be more willing to answer my questions, thanks for your time :|
 
lol at going back and editing your last reply.

Look, thanks for the replies, the bottom line is you're not sure of the exact method of how to solve this which is fair enough so i'll soldier on and try and find the solution.
 
I work as a senior analyst for a Fortune 100 company in the Point of Sale department. I've been doing PCI and SOX compliance work steadily for half a decade. Don't tell me how it works. I keep 50 big servers (pairs of 8 way clustered) and nearly 4000 terminals in a dozen time zones in PCI and SOX compliance as part of my work. My compliance scanning software is not braindead like yours so don't tell me they are all alike.

POP3 has never, will never and can't use a certificate. It's a 30 year old service that was created LONG before certificates were around.

In short, your PCI Compliance scanner is broken.

You can never fix POP3 so it uses a cert.

Since you can't and since a partial solution is the same as no solution in the PCI and SOX compliance world, you are chasing a dead end by trying to fix just some of it. While you may get some of those services to handle a certificate, you will never get them all.

So the easy thing left for you to do is to get rid of the self signed certificate and put in a CA signed one so your brain dead broken scanner will stop complaining.

Either that or file for an exception and file a bug report with your compliance software vendor.

Another solution is to get two servers and get your web and mail server away from the server that needs to meet PCI compliance. If you are using a web based credit card solution, you need to get away from that. Since I don't have a clue how your hardware and software is set up or being used I can't make an intelligent suggestion for what you need to do, but we have hundreds if not thousands of web and email servers where I work and none of them are required to meet PCI requirements. I can only guess you have combined PCI software onto the same server as you host web and mail sites and are thus trying to bring them into compliance.

So there's at least three options that I have given you to get past this. Pick one or don't, but don't cast aspersions on those who try to help you and tell them that they don't know what they are talking about when you know nothing of their background.
 
Last edited by a moderator:
CliveK,

First off I would like to say that we are a partner with McAfee, an Approved PCI Compliance Scanning Vendors (ASV), and POP3, IMAP and SMTP ports are now scanned for self signed certificates. Rest assure, the scan is not "broken". Self-signed SSL Certificates nullify the use of SSL as anyone could establish a man in the middle attack against the remote host.

A POP3 server listens on port 110. Encrypted communication for POP3 is either requested after protocol initiation, using the STLS command, or by POP3S, which connects to the server using Transport Layer Security or Secure Sockets Layer (SSL) on TCP port 995. Therefore, POP3 can be encrypted by a SSL Certificate.

It's very unfortunate when some forum participants show such blatant disregard for the question at hand by beating around a bush and supplying false information. Going and getting a signed cert is not going to just magically fix your issue. Neither is installing a signed cert into Plesk, as it's is a more complex issue.

As a side note, the only issue that is Plesk related is port 8443, the others are not.

I would be more than happy you here if you tell me what you are trying to secure. Is it Qmail, Postfix, Courier, Dovecot or a combination of them?

I have also created a PCI compliance guide for all of them which you can see by going here.

Best of luck.
 
Last edited:
Back
Top