Will my secure site pass credit card PCI compliance scans?

If you accept a large volume of credit cards, your site may be required to pass a PCI scan or a similar “security vulnerability” scan.

Our servers are configured to help you pass these scans. We have many customers who are regularly scanned without any problems.

However, you may need to ask us to make some minor changes to the way your site is set up before a scan.

On this page:

SSL certificate

First of all, you’ll need your own SSL certificate. A free certificate we offer should work fine.

You may also need a dedicated IP address in some cases (explained below). A dedicated IP address costs an additional $2.00 per month (per domain name).

Disabling SSLv3 and TLS 1.0 protocols

Some PCI scanning companies require that you disable “SSLv3” and “TLS 1.0”. You can do this in our control panel; we have a helpful blog post that explains how.

Disabling “SSL/TLS Weak Encryption Algorithms”

This problem, also referred to as either “CVE-2013-2566” or “CVE-2015-2808”, is related to SSLv3. Disabling SSLv3 as described above should fix this, too.

Disabling FTP, SSH and remote MySQL connections

Some scanning companies require your site to reject certain connections. We can do this for you if so (you’ll need a dedicated IP address for an additional $2.00 per month).

Specifically, some companies require your site to reject FTP connections. To help you pass the test, we can block access to FTP (ports 21 and 20) at the firewall level for your IP address if you contact us.

Also, if you don’t use remote MySQL connections or SSH connections, we can also disable MySQL access (port 3306) and SSH access (port 22) from outside our network at the firewall level.

MySQL databases

If you do require remote MySQL connections, things are more complicated. You’ll have to convince your PCI scanning company that you don’t store credit card numbers in your database so it’s not a security risk.

SSH version numbers

Similarly, if you do require SSH connections, we’ve received reports that at least one scanning company claims our version of SSH (“6.6p1-4~bpo70+1”) is vulnerable to security issue CVE-2014-2653.

This is not the case, though. This vulnerability was fixed in the Debian Linux version of SSH that we use, which can be confirmed here:

You should be able to successfully “appeal” this to your scanning company based on that. Tell them:

We're using Debian Linux OpenSSH version 6.6p1-4~bpo70+1, which has backported security patches applied and is not vulnerable to CVE-2014-2653.

SSL ciphers and the “BEAST Vulnerability”

One customer reported that their PCI scan company complained about a possible “BEAST (Browser Exploit Against SSL/TLS) Vulnerability” problem.

This isn’t actually the case, so if this happens to you, you should be able to successfully appeal it by sending the company this text:

This server is not vulnerable to the BEAST attack because it prefers RC4 ciphers over block-based ciphers. This can be verified at <https://www.ssllabs.com/ssltest/>, which shows "BEAST attack Mitigated server-side".

We’ll be glad to talk to your PCI compliance company if they still have a problem with it after seeing that.

SSL ciphers and the “SWEET32 Vulnerability”

One customer reported that their PCI scan company complained about a possible “SWEET32 Vulnerability”, aka “CVE-2016-2183”.

This isn’t an actual risk, because the “vulnerability” can only be used if the server doesn’t limit the number of “keepalive connections”, and our servers do.

However, you can avoid having your PCI company think this is a problem by choosing the High security SSL option in our control panel, which disables the “3DES ciphers” that they are looking for.

If you can’t use “High security” settings, you may be able to successfully appeal it by sending your PCI scanning company this text:

This server is not vulnerable to the CVE-2016-2183 "SWEET32" attack because it limits keep-alive connections to 100 requests, then resets the connection. This prevents attackers from sending the necessary data to take advantage of this vulnerability.

Can you certify that my site is PCI compliant?

Since we don’t provide any credit card handling services to customers, we can’t certify that the way you use our service is PCI compliant. In other words, while it’s possible for you to use our service and be compliant, using our service doesn’t automatically make your site compliant.

Your PCI provider will require you fill out a questionnaire each year verifying that the way your site is hosted meets some specific requirements. For example, they will require you to use servers that implement firewalls, require that all software receives regular security updates, and so on.

We believe that we meet those requirements (our own site passes monthly PCI compliance scans and annual self-assessment questionnaires from Comodo HackerGuardian), and will try to answer any specific questions you have about them. But ultimately, it’s software that you install and control on your site that determines many of the compliance details.

If you’re looking for a hosting company that handles everything related to accepting credit cards on your site, and is PCI-certified for that purpose, we’re not the right company to choose. You should instead search for ecommerce-specific hosting companies that include credit card handling services and therefore manage your site’s PCI compliance.

Note that most security experts strongly recommend that you do not actually collect credit card numbers using software on your own site, instead outsourcing that part to a service provider. If you do that, you’ll still have to pass PCI compliance scans, but the questionnaire you’ll need to fill out is much simpler.