The internet is by far the most ambitious data repository ever imagined. In fact, it’s estimated that on average 1.7 MB of data is created every second, for every individual person on the earth—and that number is only growing. With so much information constantly on the move, the need for secure encryption has never been higher. TLS/SSL is a standardized internet technology that has long been trusted with keeping internet connections secure and safeguarding sensitive data as it travels between machines. But while TLS/SSL is a proven data-security solution, it’s not entirely infallible.
When modern TLS/SSL certificates run into problems, they are likely to block website access to prevent unauthorized transmission of sensitive data. This is a valuable security feature, but when it results in error messages and in-browser warnings about the safety of your site, it can erode the trust your users have in your business. Here, we address common TLS/SSL errors, and how you can keep them from negatively impacting your company or your customers. But first, let’s discuss some terminology.
SSL stands for secure socket layers, and was first developed in 1994 by Netscape. SSL was originally created to secure connections between customers and online businesses, but later expanded for use in non-commercial sites and all different kinds of client/server communication (client to client, server to server, and client to server). Within a few years of its original introduction, SSL was replaced with transport layer security (TLS), an updated cryptographic protocol that continues to be supported and improved upon to this day.
TLS fulfills essentially the same roles as SSL but does so more effectively and efficiently. And although the original SSL technology is now entirely defunct, the name lives on in IT terminology—security certificates are often still referred to as “SSL certificates,” though it would be more accurate to call them TLS certificates. Today, few bother to make much of a distinction between the earlier technology and its successor, and even certificate authorities may refer to TLS as SSL or TLS/SSL.
TLS/SSL operates by applying asymmetric cryptography. Asymmetric cryptography relies on secret keys—one public and one private—which are used to encrypt and decrypt data. TLS/SSL certificates hosted by the server make this possible, containing the server’s public key which can then be paired with the private key to allow data transfer. These certificates are issued and maintained by a trusted third-party certificate authority (CA). Secure websites (those with URLs that begin with https) encrypt data as it travels between the server and the client, providing confirmation that the website is indeed what it claims to be.
When a browser cannot fully verify all of the relevant SSL certificates held by a site, then it encounters a TLS/SSL error. When this occurs, the client-side browser blocks the site and instead displays an error message warning the user that the site cannot be validated and should not be trusted. This can have a major impact on a business’ revenue and reputation.
TLS/SSL protocol errors cause outages, preventing your customer from accessing your site with confidence. Although the end results are often the same, it’s important to know the differences between common TLS/SSL error types, so that you can take the right steps to address them.
A TLS/SSL “handshake” describes the asymmetric cryptographic process where the browser uses key pairs to establish a secure connection before allowing the transfer of any data. A handshake TLS/SSL error is an umbrella term for many different kinds of errors and can occur when the TLS/SSL protocol or cipher suite is not supported by the server, the hostname in the URL does not match the certificate, or for many other issues related to incomplete or expired certificates or TLS/SSL connection errors.
Solution: Because a handshake error can have so many different root causes, it’s advisable to review and update your certificates on your web server, while also double-checking to ensure that the site hostname matches the certificates in use. If necessary, contact the certificate authority to determine specifically what the problem is.
An expired certificate is probably the most common TLS/SSL error. TLS/SSL certificates do not last indefinitely. To help ensure that all in-use certificates are using the latest security standards and are in the hands of the correct owners, companies, and domain names, every certificate has a built-in validity period. Once that validity period ends, the certificate expires and is no longer valid. Browsers check to ensure that all of the certificates in the chain are up to date, and any expired certificates are automatically rejected.
Solution: Most certificates include validity periods of about one year, but there are exceptions. Keep an automated inventory of all of your TLS/SSL certificates, including their start dates and expiry dates, and update your certificates before they can expire and cause problems. If a certificate expires unexpectedly, you will need to work quickly to install a new certificate, generate a signing request, and contact a certificate authority to request a new certificate.
Given the increasing threat from man-in-the-middle (MITM) attacks, modern TLS/SSL certificates are designed to verify that the client is interacting with the correct server before allowing any data to transmit. To do this, the browser compares the hostname for the website against the list of approved hostnames included in the leaf certificate. A missing-hostname error occurs when the browser is unable to find a match for the website’s hostname, resulting in a blocked connection.
Solution: A common cause of a missing-hostname error is using the same certificate for multiple sites and subdomains. Check to make sure that all the webpages are covered by the certificate and that the TLS/SSL certificate itself is correctly configured. Better yet, protect each webpage with a unique TLS/SSL certificate to avoid unanticipated errors.
A certificate chain (also called a certification path) is a list of connected certificates leading from the server’s certificate and ending with the root certificate. Every standard browser maintains a set of trusted root certificates; when the browser encounters a certificate from a server, it will attempt to chain website certificates until it can connect with a root certificate. If all of the certificates in the chain are not present, the client will reject the certificates and the user will be unable to access the site.
Solution: An invalid or incomplete certificate chain is something that you will need to contact your hosting provider to resolve. They can work with you to add the missing intermediate certificates to your configuration.
The SHA-1 hashing algorithm was designed to authenticate messages sent between the client and server during the TLS/SSL handshake. Unfortunately, SHA-1 was discovered to include major vulnerabilities, and was officially deprecated in 2011. If users are seeing an ‘insecure SSL’ warning, then your web server may be using unsecured SHA-1 certificates.
Solution: If any of your servers are still using SHA-1 certificates, you will need to replace them with new SHA-2 certificates. SHA-1 certificates are no longer issued by certificate authorities.
Some certificates may become compromised or rendered otherwise ineffective before they reach their scheduled expiration date, and end up being revoked. Because it is standard practice to trust a certificate unless told otherwise, certificate authorities keep a regularly updated and openly available list of revoked certificates. If any of the certificates in the certificate chain are present on the list of revoked certificates, the browser will automatically reject the certificate and block the connection.
Solution: Revoked certificates should be disabled and replaced as quickly as possible.
Although these are some of the most common TLS/SSL error types, they are not the only ones that you might encounter. To ensure that your site and its visitors are fully protected, you should take steps to identify and prevent the root causes of TLS/SSL errors within your domain.
In nearly all cases of TLS/SSL error, organizations can eliminate potential problems by more effectively monitoring their certificates.
TLS/SSL certificate monitoring is not overly complicated. In fact, it’s possible to check certificates directly through most modern browsers. Simply check the webpage URL to see if it begins with https. If it does, then the page is protected by an SSL certificate. You can then click on the padlock icon next to the URL in the address bar to see specific information relevant to the page’s certificate. That said, keeping close tabs on all of your business’ certificates can be extremely time-consuming.
To help ensure accuracy and efficiency in certificate management, many businesses are now turning to TLS/SSL certificate monitoring tools.
Certificate monitoring automates many of the most important certificate management processes. Certificate expiration dates can be automatically tracked and reminders scheduled in preparation for replacing outdated certificates. Hostnames can be easily verified against certificate lists, and revoked and outdated certificates quickly identified and flagged. Automated reports can help track and verify certificate chains. And finally, Certificate Authorities can be continuously monitored for any changes that might impact in-use certificates.
Click here to learn more about certificate management best practices.
With the right certificate management and monitoring solution, you’ll have the visibility and automation to locate and resolve TLS/SSL errors before they can hinder the reliability or accessibility of your site.
Venafi, the industry leader in machine identity management empowers businesses across all industries with the tools they need to manage their vital TLS/SSL certificates. Learn more about Venafi certificate management tools and solutions, and download our TLS/SSL Machine Identity Management for Dummies guide to see how the right machine identity management can make a significant difference to the future of your organization.
Ready to get started? Try Venafi as a Service for free for 30 days, and take control of your certificates.