Solutions for PCI DSS Non-Compliance in HTTPS Certificate Deployment

Deploying HTTPS on a site is an irresistible trend at present, so many blog sites have been upgraded to HTTPS, but when deploying HTTPS, there may be more or less problems, so it is necessary for us to use 3rd party platforms (such as myssl.com) to test to see if we are A+ rated, PCI DSS compliant, ATS compliant, etc. Today we will focus on the issue of PCI DSS non-compliance.

Solutions for PCI DSS Non-Compliance in HTTPS Certificate Deployment - Sheet 1 - Yigujin (www.yigujin.cn)

PCI DSS
PCI DSS, the full name of Payment Card Industry Data Security Standard, is the third-party payment industry data security standard.

As early as June 30 last year, the PCI Security Standards Committee officially published a blog post to disable early SSL/TLS on June 30, 2018 (latest) and implement a more secure encryption protocol (TLS v1.1 or later, strongly TLS v1.2 is recommended) to meet the requirements of the PCI Data Security Standard to protect payment data.

As time approaches, we have adjusted the PCI DSS compliance criteria in advance (on top of the original standard, encryption protocols that support TLS v1.0 or earlier will be determined to be non-compliant), so that you can adjust your Services to avoid the risk of non-compliance.

According to the above introduction, early SSL/TLS has been disabled since June 30, 2018, that is, TLSv1.0 is disabled. In other words, if the site also supports the TLSv1.0 encryption protocol, it will be judged as PCI DSS non-compliant. As shown below:

Solutions for PCI DSS Non-Compliance in HTTPS Certificate Deployment - Sheet 2 - Yigujin (www.yigujin.cn)

Now many tutorials for deploying HTTPS on the Internet still use the TLSv1.0 decryption protocol. Generally, the ssl_protocols configuration given is similar to the following:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
The TLSv1 in the above code is actually TLSv1.0, which means that if we still use TLSv1 when configuring SSL, there will be PCI DSS non-compliance. Now that you know the problem, the solution is very simple. Disable TLSv1.0 directly in the SSL configuration, that is, delete TLSv1 directly. The modified code is as follows:

ssl_protocols TLSv1.1 TLSv1.2;
If your site environment supports TLSv1.3, it can be modified to:

ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
After modifying ssl_protocols, remember to restart nginx (smooth restart nginx command:

/usr/local/nginx/sbin/nginx -s reload), and then go to myssl.com to re-detect, if there is no change, click the "Refresh Report" button on the right to refresh. For example, the test report after the modification of this site is as follows:

Solutions for PCI DSS Non-Compliance in HTTPS Certificate Deployment - Section 3 - Yigujin (www.yigujin.cn)

As shown in the figure above, after the site deletes TLSv1 in the SSL configuration and restarts nginx, PCI DSS is compliant.

If you are also using Youpai Cloud CDN, remember to go to Feature Configuration >> HTTPS >> Pull down to find "Minimum TLS Version" >> Click the "Management" button >> Select TLSv1.1 and click the "OK" button. As shown below:

Solutions for PCI DSS Non-Compliance in HTTPS Certificate Deployment - Sheet 4 - Yigujin (www.yigujin.cn)

In this way, if TLSv1.0 is directly disabled on the server, and the minimum TLS version is selected as TLSv1.1 on Youpaiyun, it can be said that it is foolproof, and the PCI DSS in the test report must be compliant. If you have time, it is recommended that bloggers and webmasters also check whether there is PCI DSS non-compliance on their own sites. If so, just follow the method in this article.