How to Upgrade OpenSSH and Disable SSLv3.0, TLSv1.0, & Weak Encryption for PCI Compliance

Since June of 2015 Trustwave and others have begun failing e-commerce sites that previously had been passing their monthly PCI security audits.  Apparently it’s no longer ok to let people access your site who are running IE 10 and older, Android 4.3 and older, OS X 10.8.4 and older, or a long list of others.  While this software may not be THAT old, it’s old enough that it doesn’t work with the latest security protocols & ciphers, and so when you lock-down your site to support only the most secure stuff, you’ll end up blocking those folks on older platforms from visiting your site. But what can you do? Unless that minority of visitors on older technology is bringing in enough revenue to justify the cost of not being PCI compliant (if that’s even an option with your payment processor), it has to be done.  (Unfortunately, these people who try to visit your newly locked-down site will usually just get a generic error page from their browser saying the site couldn’t be found, so they’ll never know that the site is alive and well and they just need to update their software! Oh well…)

So, if you want to pass your PCI certification and keep Trustwave’s TrustKeeper PCI Manager (among others) happy, how can you do it? Here’s what worked for me…  

On the site I most recently had to do this to, there were two main problems showing up repeatedly in the Scan Results/Findings:

  1. Errors about OpenSSH vulnerabilities. For instance, “OpenSSH Wildcards on AcceptEnv Vulnerability,” and the only suggested remediation was to “Update to OpenSSH 6.6 or higher.”
  2. Lots of errors about “SSLv3.0 & TLSv1.0 Supported” and “SSL/TLS Weak Encryption Algorithms” with no really helpful info about remediation at all.

For problem #1 (OpenSSH is too old), the VPS running this e-commerce site was running CentOS 6.6, Apache 2.2.29, OpenSSL 1.0.1e-fips, and OpenSSH 5.3p1. That’s the latest version of everything but OpenSSH, which apparently wasn’t getting automatically upgraded with other packages on this server, so it had to be upgraded manually. I don’t have the exact procedure that I followed to do it in front of me, but I ended up loosely following these instructions:  I say “loosely” because that procedure  is for a much older version of CentOS, Apache, etc., and so not all directories matched exactly with what he lists here. However, if you follow what he says, and make modifications when necessary, based on any errors you’re getting (mostly directories not existing that it expects to be there), then you’ll be fine.  Of course, you’ll also need to consult to see what the current version is, and use that instead of what he’s using (including the one instruction where he inexplicably references an old 5.8 version – just use the latest version for all of it and it’ll work fine).

Ok, so now that my OpenSSH version was now updated to 6.9sp1, I could move on to problem #2: weak security ciphers, weak encryption algorithms, and weak security protocols.

If you’re running your own Apache server, you can edit the relevant lines in httpd.conf (and other relevant files) and recompile, but since I was on a VPS, I figured I’d use the WHM interface instead, since it’s much easier.

This problem actually broke down into two main sub-parts: weak protocols and weak ciphers.  Since Trustwave scanned the entire server, and not just the ports used by the web site, I had to modify the protocols & ciphers in a number of places, to address each poorly-secured port.

First, I started with the easiest one to test: the web site itself, on port 443.

In the “Apache Configuration” section, look at the field called “SSL/TLS Protocols.” Mine was already set to the “default” of:

All -SSLv2 -SSLv3

But, I changed it to this instead :

+TLSv1.1 +TLSv1.2

…That way everything other than TLSv1.1 and TLSv1.2 would be switched off – including TLSv1.0, which was causing a lot of my grief.

Now I just had to tweak the security ciphers.  This was a little trickier.

Still in the “Apache Configuration” section, look at the field at the top called “SSL Cipher Suite.” Mine was already set to their “PCI recommended” value of:


…but obviously that didn’t work for today’s stricter PCI certification requirements, so I consulted Mozilla’s handy-dandy SSL Configuration Generator and after giving it my Apache and OpenSSL versions, I had my own (massive) custom string that I could add instead. It looked like this:


…but that didn’t pass PCI certification scans either!

TrustWave was now giving me fewer errors now, but I still wasn’t passing due to “weak encryption algorithms” among others. Clearly, Mozilla’s tool wasn’t going to cut it.

Trustwave was taking 12 hours to get around to telling me whether my changes had worked though, and I was getting tired of waiting to see if my latest tweak was fixing the problem, so thankfully I found the very awesome SSL Server Test.  This site is great!  It allows you to run scans against your domain to check all aspects of your web site’s security, and after only a few minutes, it’ll give you a detailed report of what it found, with a letter grade from A-F. That’s a huge improvement over the vague errors from Trustwave, and their 12 hour turn-around between tests.  Now, I could make a change, wait a few minutes, and immediately know if it helped or hurt!

My site was already getting a “B” grade at the SSL Server Test, but after adding this line in the “SSL Cipher Suite” field in WHM’s Apache Configuration, it became an “A” grade:


You may recognize that from one of Trustwave’s suggestions in your list of failures and suggested remediations. The first part of that is what they say is “recommended” for “the best guarantee for strong encryption,” presumably to be able to pass. But, even using their suggested ciphers, I still failed! So, I consulted the list of ciphers at Apache‘s site and added my own additions to the end, to specifically address Trustwave’s complaints. This is what finally allowed me to get an “A” grade and to then pass the PCI scans!

So, now that we’ve gotten the site (i.e., traffic over port 443) to be complaint, we need to address the rest of the errors that repeat over and over again about weak encryption algorithms. Those repeating errors appear because each one is for a different port. As it turned out, ports relating to FTP needed to also be updated, along with email (IMAP, POP, SMTP, webmail), and cPanel, and WHM.  Now that we know what works for the web site, we can use those same concepts (with some minor variations) to fix the rest of the non-compliant ports/services too.

Here’s a much quicker run-down of how I got a passing grade for them:

In WHM, go to FTP Server Configuration. Edit the TLS Cipher Suite:
Old setting was:


Now changed to:



In WHM, go to Mailserver Configuration, and disable IPv6 (optional, but might as well if you’re not using it), then in the SSL Cipher List:
Old setting was:


Now changed to:


Now, still in Mailserver Configuration, edit the SSL Protocols:
Old setting was:

!SSLv2 !SSLv3

Now changed to:

!SSLv2 !SSLv3 !TLSv1

Now, go to Exim Configuration Manager->Advanced Editor:
Under openssl_options it used to be:

+no_sslv2 +no_sslv3

Now changed to:

+no_sslv2 +no_sslv3 +no_tlsv1

Under tls_require_ciphers it used to be:


Now changed to:


NOTE: When you disable TLSv1.0 you’ll break Outlook’s (all versions) ability to connect to your server. (At least as of this writing.) However, there’s a registry change that you can make which will get it working again. Check out my recent post on the subject to learn more: How to Allow Outlook to Connect via TLSv1.1/TLSv1.2

ALSO NOTE: Don’t let your eagerness to pass your PCI compliance scans cause you to go nuts disabling everything you find relating to SSLv3.0 and TLSv1.0! (As I originally did!)  You only need/want to disable these protocols – leave the ciphers alone! If you make the mistake of adding in something like “!SSLv3:!TLSv1” to your ciphers, then you’ll inadvertently also disable ciphers used by TLSv1.1, which are the same ones used by SSLv3.0, and thus will make it impossible for an email client to connect! As long as the right protocols are disabled, nobody will be able to connect using them, so disabling the related ciphers isn’t necessary.


In WHM, go to cPanel Web Services Configuration, and in the TLS/SSL Cipher List:
Old setting was:


Now changed to:


Also in cPanel Web Services Configuration, edit TLS/SSL Protocols:
Old setting was:


Now changed to:



You may also want to do this in WHM’s cPanel Web Disk Configuration, though it’s disabled on my server, so I didn’t test it.

Now, with all of those issues addressed, I asked Trustwave to rescan, and now their scan comes back with a PCI Compliance Status of PASS!

Woo hoo! :)