Having SSL problems? One of the most common issues our team handles is related to websites not properly displaying over HTTPS, whether it be the website either not loading entirely, or just not showing the green padlock:
If you’re sure that the SSL certificate is installed properly, but your site isn’t showing as secure, there are many things that can cause this.
Note: If your certificate is not installed properly, most all browsers will prompt you about this prior to loading the website. This is typical in situations where the certificate is installed for a different domain than what you are accessing (a.k.a “domain mismatch”), the certificate is expired, or it’s invalid or self-signed. If this is the case, you need to install the certificate correctly first. See cPanel’s documentation for installing an SSL certificate or using AutoSSL. Need help? Contact us!
First, go to https://www.whynopadlock.com and enter your domain name with https:// in front of it. I’m a huge fan of this website, because it will pretty much tell you exactly what the problem is. If your website is failing in any area, it might not load correctly for some visitors. I’ll go through each of the tests below.
It used to be that you only had to load your site over HTTPS for things like login or order forms, but by current standards, that’s no longer the case. Your site should always load over HTTPS. The most common way to do this is via .htaccess. If you have WordPress or another domain-specific CMS, you may want to consider a plugin like this one. Some applications may require you to adjust their configuration to load over a specific URL.
As noted, this should be an obvious one, because your site will probably not load without a notice that the certificate is invalid. The URL bar in your browser may also show a red broken “x” or padlock icon to warn you about this. For your certificate to be valid, it must be signed by a certificate authority for the domain you are accessing, and must not be expired. A self-signed certificate is not acceptable. You can use LetsEncrypt or Comodo (provided by cPanel AutoSSL), though.
I also touched on this, but the certificate has to match the domain you are accessing. There is a difference between www.domain.com and domain.com, but nowadays most all certificate authorities will automatically issue the certificate to both. Subdomains would not be included unless you specifically added them to your certificate or have a wildcard certificate.
At present, your certificate must use the sha256 hashing algorithm, or SHA-2. This usually will not be problem if your certificate was issued in or after 2016, but if for some reason it is, just have your authority reissue the certificate.
As stated, your certificate must not be expired. If it is, you’ll need to renew it.
This one is a server-side issue, and you may be surprised how many newer browsers have really tightened up on enforcing secure protocols. SSL protocols eventually become deprecated and non-compliant with PCI and other security standards. If your server supported connections on these expired protocols, some browsers may refuse connection to them over HTTPS.
To fix this for Apache on a cPanel server, edit /var/cpanel/conf/apache/local and make sure the sslprotocol line reads as:
sslprotocol: All -SSLv2 -SSLv3 -TLSv1
Then run /scripts/rebuildhttpdconf and restart Apache. You can also change this in the Apache Configuration section of WHM. This will specifically disable the currently-outdated SSL protocols.
If you’re running Nginx over Apache, you’ll need to also edit this in the nginx.conf file and restart Nginx. For Engintron users, the setting will be in common_https.conf.
This can be one of the hardest issues to resolve, depending on the framework of your site. This error basically means that some parts of your website, whether its a CSS file or image, is loading over HTTP while the rest of your site is loading over HTTPS. The report should give you a list of these resources.
In the simplest of situations, this is usually a matter of just changing all instances of “http” to “https” in your website’s code, or using relative paths instead of full URLs (which of course, will only work for local resources). In more complex cases, such as with WordPress sites, you’ll need to do a search/replace within the database. This article explains the process, but you will need to do it from command line.
Most other issues are apparent by the client’s browser not being able to connect to the website over HTTPS at all, even when the above tests pass. In these cases, more often than not, we’ve seen it to be caused by the client’s environment. Older operating systems, like Windows XP, CentOS 5, simply cannot access HTTPS websites anymore unless the servers hosting them support very old protocols. These users are probably also seeing the same issue with accessing other websites as well, especially for banks or other highly-secured websites. We have also seen rare cases when user antivirus software or firewalls have caused a problem. If your tests indicate no clear failures but a client is not able to connect over HTTPS, it’s most likely an issue on their end.
In conclusion, most SSL problems can be easily resolved if you know what is causing them. As always, feel free to contact our team if you need assistance with your website not loading over HTTPS.
Recently, the following error was thrown whenever I try to process a payment in PayPal.
“Stripe / PayPal no longer supports API requests made with TLS 1.0. Please initiate HTTPS connections with TLS 1.2 or later”
on further investigation it is found that common payment gateways such as PayPal are updating their API servers to only accept requests made using the new TLS 1.2 protocol for encryption. This is intended to secure all external connections made to the payment gateways. Interestingly the same issue happened during Stripe checkout as well, ruling out any issues specific to PayPal alone.
Even though the server is enabled with TLS 1.2, the default connections uses TLS 1.0 for establishing connections with payment gateways and it creates the compatibility issue.
This issue was a good one. Took me 1+ hour to figure out. Google helped by lighting the path
Here is what I did.
1.Checked in the Qualys SSLLabs using the link https://www.ssllabs.com/ssltest and confirmed that TLS 1.2 is enabled.
2.Worked in the SSL settings of web server / virtual host to enable only TLS1.2 by using the following entry in my virtual host entry
SSLProtocol -all +TLSv1.2
You need to tweak it in accordance with your webserver settings. I also tried adjusting the priorities of TLS v1 TLS v 1.2 etc.
3. Checked for the latest version of OpenSSL and Curl
4. Tried matching the libcurl version in CLI and the phpinfo page and they turned out to be the same.
5. OpenSSL versions also matched in phpinfo and CLI
6. Tried running curl in the CLI with –tlsv2 option enabled. It worked there, but still not on the website.
I tried running the php script and it was returning me TLS 1.0 . So that was the turning point. For some reason system is taking TLS 1.0 and not trying to negotiate TLS 1.2
As anyone can guess, the issue is with the default version.
By default it is taking TLS 1.0. Issue would be solved if I can somehow get TLS v 1.2 to load. I tried setting CURLOPT_SSLVERSION, but unfortunately (or fortunately) it didn’t work
Finally an interesting discussion came as Bug 1272504 in https://bugzilla.redhat.com/show_bug.cgi?id=1272504 .
Luckily, the server was a VPS and hence we could update the package. yum update nss.i686 and the issue got resolved. The above code displayed TLS 1.2 and I knew the problem solved. It did!!
The post Steps to enable TLSv1.2 for PayPal /Stripe connections appeared first on SupportSages – Your IT Infrastructure partner !!.