SSL/TLS certificates are used on millions of websites to provide security and confidentiality for online data sensitive transactions. However, there are a few problems that can occur with their deployment that cause error messages to be shown to website visitors. In addition, there are cases when the certificate authorities have either issued mistaken certificates (like Trustwave did back in 2012) or the certificates have been compromised by malicious actors, like the DigiNotar case.
Certificate validation and management is a process that requires agile management and automation in order to effectively audit, monitor and resolve flaws and pitfalls that will endanger the trust model on which the internet is currently (and has been) designed. Therefore, it is essential to identify the various certificate validation and management flaws.
An internet browser will state that a website certificate is untrusted if that certificate has not been signed by a trusted Certificate Authority (CA). In order for a browser to accept a certificate, it must be able to link it to a trusted root certificate. Trusted root certificates are embedded into popular browsers and they are used as trust 'anchors' to verify the legitimacy of all website certificates that the browser encounters. If a browser encounters a certificate that is not signed by one of these roots, then it will state it is untrusted and visitors will see an error message. Most trusted root certificates in a browser are owned by an accredited CA. When a CA signs the certificate of a website, it is effectively 'linking' that website's certificate to one of their trusted roots in the browser certificate store. For security reasons, most CA's do not sign end-entity/website certificates directly from the root, but will instead use an intermediate certificate to create a chain of trust to the root. In this system, the root certificate will sign the intermediate and the intermediate is used to sign the certificates of individual websites. 'Untrusted' errors, therefore, are usually caused for one of two reasons:
In many cases, this is because the website is using what is known as a Self-Signed Certificate. As the name suggests, a self-signed certificate is one that the website owner has generated and signed for themselves using their webserver software. Therefore, the certificate is not associated with any trusted root in the browser's certificate store and the browser will display an 'untrusted' error.
Self-signed certificates do have their advantages. They are free to generate and are fine for use on intranet and development servers where the only people expected to trust the server are internal personnel such as company employees. However, they should never be deployed on commercial websites that the general public are expected to trust.
Another potential reason for the 'Untrusted' error is because the website administrator has not correctly installed all intermediate certificates on their webserver. Companies obtain root certificates from only trusted CAs, or entities which are authorized to verify someone's identity. Most web browsers and operating systems ship out to consumers with a trust store containing a list of trusted CAs. A device such as a web browser, in turn, uses that list to validate an SSL/TLS certificate's issuer.
In the event the device does not find a match, it navigates up what is known as the certificate chain of trust by checking any and all intermediate certificates. These digital certificates sit between the end-user (SSL/TLS) certificate and root certificate. As such, an intermediate certificate signs/issues the certificate.
The device determines whether the intermediate certificate of the issuing CA was signed by a trusted CA. In the event it wasn't, the device continues this process across subsequent intermediate certificates until it discovers a trusted CA match or until it reaches the root certificate. If it ultimately finds no match with a trusted CA along that entire chain of trust, the device displays an error message.
The 'certificate name mismatch' error occurs when the domain listed on the SSL certificate presented by the server does not match the domain that the browser is connected to. For a HTTPS session to commence, the domain on the certificate must exactly match the domain in the browser address bar. The mismatch could happen because the website was accessed using an IP address, but the certificate was issued only to the public Fully Qualified Domain Name (e.g. www.domain.com), or the certificate was issued to domain.com, but www.domain.com was typed into the browser ('www' is actually a sub-domain of domain.com). The latter can still occur but is becoming less common because most major CAs issue single domain certificates that cover both domain.com and www.domain.com.
The name mismatch error can also occur when multiple websites are hosted on the same IP address. This is often the case in many shared hosting environments. As a result, the server does not have the information required to decide which certificate to send and will often present the wrong certificate. If there is only one website and one certificate on an IP, then this shouldn't be a problem. However, if there are multiple websites on the same IP, the server may provide a certificate for the wrong domain.
For a secure, HTTPS connection to be established, every item on the page must be served from a secure source. This means all embedded images, videos, flash movies, iframes and Java scripts must be served from a secure location. If any items are not, then website visitors will see an error message like the one below
If the visitor chooses 'Yes', then all items will be displayed but the connection will revert to insecure HTTP. If the visitor chooses 'No', then only the secure items will be displayed. This could mean that certain images and videos are not shown or that the page will fail to execute important scripts. Either way, this is bad signal to send to your website visitors. This is arguably the most widespread of all SSL errors, but is also one of the easiest for an admin to fix since HTTPS is so easy to enable and should be enabled everywhere, even in static websites.
Other certificate validation errors have to deal with the CAs themselves. There are so many certificate authorities, so problems with one certificate authority can affect everyone. Studies have found that some certificate authorities have failed to do even minimal due diligence when issuing certificates. They’ve issued SSL/TLS certificates for types of addresses that should never require a certificate, such as “localhost,” which always represents the local computer.
In fact, in 2011, the EFF found over 2000 certificates for “localhost” issued by legitimate, trusted certificate authorities. In the wrong hands, such a certificate could make man-in-the-middle attacks easier. This is actually where Extended Validation (EV) certificates come in handy. An extended validation (EV) certificate is a type of SSL/TLS certificate. It is highly valued because it requires the most amount of effort by a certificate authority (CA) to validate. As such, an EV certificate provides a high degree of trust for visitors to a website operated by the certificate owner.
Whether it is inadequate internal controls, human error or technology malfunction, a certificate validation error can allow attackers to perform man-in-the-middle attacks to impersonate legitimate properties or can allow attackers to issue fraudulent certificates for virtually any site. Organizations can simplify management of certificates and prevent business interruptions by using an automated solution for machine identity protection such as the Venafi Platform. This utility validates that certificate and chain on every server is correctly installed on a nightly basis. It also supports the automated installation of CA certificate chains with certificates along with the ability to provision and manage such chains. All the while, the Venafi Platform has the ability to enforce trust stores across all systems.