PCI's June 30 Deadline: Turning Off TLS 1.0 Without Locking Out Customers

In eleven days, a deadline that has been on the calendar since 2015 finally arrives. From June 30, the PCI Security Standards Council requires that SSL and "early TLS", which in practice means TLS 1.0, no longer be used to protect cardholder data. If you accept card payments and your servers still negotiate TLS 1.0, you'll be out of step with PCI DSS in less than two weeks.

This deadline was originally set for June 2016 and pushed back two years because too many organisations weren't ready. A lot of teams used that extension to forget about it. If you're one of them, the good news is that for most web servers the change itself is a one-line config edit. The work is in checking what it breaks first.

Why TLS 1.0 is on the way out

TLS 1.0 dates from 1999. Over the years it has collected a set of well-known weaknesses, and attacks like BEAST and POODLE in the SSL/early-TLS family showed that the older protocols' design choices could be exploited in practice. Modern browsers have mitigations for most of these, but the protocol itself can't be fixed, only replaced.

TLS 1.2 has been available since 2008 and supported by every mainstream browser for years. The PCI requirement is to use TLS 1.1 or higher, and the council strongly recommends TLS 1.2. We'd skip straight to allowing only 1.2 where you can: TLS 1.1 offers little that 1.2 doesn't, and it's likely to be the next thing on the list.

Who PCI's rule applies to

If you process, store or transmit card data, or your systems can affect the security of that data, the requirement applies to the connections involved. For many sites that means:

• The checkout pages themselves, if payment details are entered on your domain.
• APIs that receive card data or tokens from your front end or mobile apps.
• Connections from your servers out to your payment processor or gateway.
• Admin interfaces for systems inside the cardholder data environment.

If you use a hosted payment page or an embedded form from your processor, a lot of this sits with them. But "a lot" isn't "all": your own checkout page still loads the embedded form, and your server still talks to their API. Ask your processor and your assessor precisely which connections count, rather than guessing.

There's also a specific exception for certain point-of-sale terminals that can be shown not to be exposed to known exploits. It's narrow and it's not about web servers.

Step 1: find out what you negotiate

Before changing anything, check what each of your public endpoints accepts. OpenSSL can test one version at a time:

# should FAIL after the change
openssl s_client -connect shop.example.com:443 -servername shop.example.com -tls1 < /dev/null

# should succeed
openssl s_client -connect shop.example.com:443 -servername shop.example.com -tls1_2 < /dev/null

For a fuller picture, including cipher suites, nmap's ssl-enum-ciphers script lists every protocol version and cipher the server accepts:

nmap --script ssl-enum-ciphers -p 443 shop.example.com

Run these against the address the public actually reaches. If a load balancer or CDN terminates TLS in front of your servers, its settings are the ones that matter, and they're usually configured somewhere different from your web server.

Step 2: find out who still uses TLS 1.0

Turning off TLS 1.0 blocks clients that can't do anything newer. On today's web that's a small group, but it's not zero, and it tends to include exactly the users who complain loudly:

• Very old Android versions (roughly 4.3 and earlier) with their stock browsers.
• Internet Explorer 8 to 10 on Windows 7 with default settings, and anything on Windows XP.
• Old versions of Java, OpenSSL and other libraries in server-to-server integrations. This is the one that surprises people: a partner's billing system from 2011 calling your API.

You can measure this rather than guess. nginx can log the negotiated protocol:

log_format tls '$remote_addr [$time_local] "$request" $status '
               '$ssl_protocol $ssl_cipher "$http_user_agent"';
access_log /var/log/nginx/tls.log tls;

Leave it running for a week and count:

awk '{print $(NF-2)}' /var/log/nginx/tls.log | sort | uniq -c

(Adjust the field position to match your log format.) If TLS 1.0 traffic is a fraction of a percent and mostly bots, you're clear. If a specific integration shows up, contact that partner now, not on July 1st.

Step 3: change it

For nginx:

ssl_protocols TLSv1.2;

Or TLSv1.1 TLSv1.2 if your measurements show you need 1.1 for a while. For Apache with mod_ssl:

SSLProtocol -all +TLSv1.2

Reload, then re-run the OpenSSL tests from outside to confirm TLS 1.0 is refused and TLS 1.2 still works. Do this on every hostname, including the ones handled by a CDN or cloud load balancer, where the setting is usually a security policy you select in the provider's console.

Step 4: don't forget outbound connections

The client side is easy to miss. If your application calls your payment gateway over HTTPS, it's the TLS client in that conversation, and your language runtime decides which version it offers. Gateways have been announcing their own TLS 1.2 cutoffs, and an old runtime will simply start failing to connect.

Checks worth doing:

• Old PHP builds linked against old OpenSSL, older Java versions where TLS 1.2 may need explicit configuration, and older .NET Framework defaults are the usual suspects.
• Most gateways offer a test endpoint that only accepts TLS 1.2. Point a staging environment at it and run a test transaction.
• openssl version on your application servers tells you whether the underlying library supports TLS 1.2 at all (anything from 1.0.1 onward does).

After June 30

Once the change is live, the remaining risk is regression: a new server built from an old template, a load balancer policy reset during a migration, a CDN configuration change that quietly re-enables older protocols. Put the TLS version check somewhere it runs regularly, not just once for the assessor.

This is part of a longer pattern of the web's security baseline being raised on a schedule, like the cut to 825-day certificates earlier this year. TLS 1.3 is close to being finalised, and the older versions will keep getting squeezed. Knowing what your servers negotiate today, and noticing when that changes, is the habit that makes each of these deadlines a small job instead of a scramble. It's also the kind of external check CompleteStatus is built to run.