Introduction
During recent years, HTTPS adoption has been rapidly increasing (Google provides a transparency report that shows this progress more visually). HTTPS uses SSL/TLS certificates to protect data, and is one of the most important browser security mechanisms against cyber threats. The web Industry is now encouraging (or requiring) HTTPS as a replacement for insecure HTTP.
However, this added security has inevitably increased operational complexity for both browser users and web server administrators. HTTPS depends on components that can potentially fail and produce obscure error messages.
In addition, security warnings do not necessarily mean that the server or browser is under attack. Expired, revoked or misconfigured certificates can also produce similar messages. For this reason, many users can get confused (or annoyed) and ignore HTTPS errors, even though disregarding security error messages can be quite dangerous. (In fact, browser providers are making security warnings increasingly difficult to bypass.)
Administrators face the additional concern that their websites’ consistent display of security warnings to visitors can have a negative effect on the site’s reputation. It is imperative that site administrators quickly investigate and fix any underlying issue.
To help with this, we will examine some of the most common HTTPS error warnings, explain what they mean and suggest how administrators can remedy them.
“Not Trusted for this Website”
SSL/TLS certificates are usually issued by third-party entities called Certificate Authorities, or CAs. CAs (such as SSL.com) cryptographically sign each certificate they issue. This allows browsers to confirm that the certificate for a particular website was issued by a trusted CA (one that has already been added to the browser’s certificate stores).
The “Not trusted” error means that a web server presented a certificate signed with a digital signature the browser does not recognize. A browser will show this error message in two cases:
- The server employs an untrusted self-signed certificate, or
- The certificate installation on the server has failed, so the browser cannot correctly verify its authenticity.
Self-signed certificates are just like normal certificates, but are created locally by web server administrators instead of trusted CAs. Such certificates might be used for internal URLs, static pages or low traffic web sites.
Since self-signed certificates are not linked to a trusted CA, browsers do not trust them automatically. A user must manually bypass a security warning (typically by telling the browser to “trust” the self-signed certificate) before they can visit the site. The procedure varies from browser to browser and unless you know exactly who issued the untrusted certificate (and why) we recommend that you avoid bypassing such warnings
The second case occurs when an installation fails (or is done incorrectly). A common occurrence is to leave out intermediate certificates, also called a certificate chain, when performing the installation. This breaks the chain of trust from the CA to the website certificate, so browsers do not recognize the certificate as trusted and present this error to visitors.
When receiving the “Not trusted” error, consider the page being visited. A high traffic page or one handling sensitive user information (like credit cards, billing addresses and so on) is highly unlikely to use a self-signed certificate.
Thus, it could be one of two possibilities: the server (or the connection) was hijacked (and attackers replaced the original certificate with their own) or the administrator tried to update the server certificate and failed somewhere in the process.
Erring on the side of caution, we recommend that users avoid using any web site displaying this error until the underlying issue is resolved.
How to fix a “Not trusted” error
It is not recommended to use self-signed certificates for external or Internet-facing pages such as log-in pages or customer check-out. In fact, most standards and certifications documents, such as PCI-DSS, require the use of properly signed certificates from an accredited CA for any such sensitive operation.
If you’ve purchased a certificate from a CA and still encounter this error, you should verify that the installation did not produce any errors and that you’ve followed the steps correctly. If that doesn’t help, you should contact the issuing CA for further assistance.
“Your connection is not secure”
Some browsers might state that the connection is “not private” instead of “not secure” but the they all refer to the same problem: the server certificate cannot be validated. Here, the browser will terminate the connection to the website and show this error message instead. Certificates fail to be validated when they are either revoked or expired.
Digital certificates can be revoked for many reasons, and trusted CAs maintain services to publicly display their revoked certificates. (These include Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responders.) Browsers consult with these services before they trust a certificate. Users stumbling upon revoked certificates should avoid using the web site, as this means that their connection might be compromised.
SSL certificates also naturally expire after a period of time and must be renewed. This helps ensure that all credentials are periodically checked, offering a reasonable assurance that the certificate covers a server controlled by a legitimate owner and not a malicious attacker.
How to fix the “Not secure” error
We recommend that you renew your certificates before they expire to avoid this error. SSL.com customers can use our integrated expiration alert service to warn about upcoming certificate expiration.
“Mixed Content”
A mixed content warning refers to components of HTTPS websites that are retrieved over HTTP. Common examples include remote images, scripts, or any other element that is transmitted insecurely (even if on the same server).
Attackers can exploit unsecured HTTP connections to compromise a visitor’s browser (or even computer). Despite the evident risk, many web sites still use HTTP to retrieve remote components. To warn users against mixed content connections, browsers show a negative security indicator.
Users should avoid all such connections if possible, but unfortunately numerous legitimate web sites have not yet resolved this issue. Therefore, we suggest caution and use of good judgment when choosing to visit web sites that display the mixed-content warning.
How to fix a “Mixed Content” warning:
Administrators should search through their web site’s source code for URLs starting with http://. To stop browsers from showing the mixed content warning, replace all HTTP URLs with HTTPS (i.e. they should start with https://) URLs pointing to the same resource. The following snippets show an example:
<img src="http://www.example.com/outdated.jpg" alt="Outdated HTTP image" >
Should change to:
<img src="https://www.example.com/modern.jpg" alt="Modern HTTPS image" >
If the remote server already supports HTTPS, you can just change the URLs in your source code. However, if you don’t have control of the remote server, you’ll have to either negotiate with the third party that does control the server or find a different service with HTTPS support to eliminate this warning.
“Name Mismatch”
Browsers show this error message when a server presents a digital certificate for a different domain name. This can occur because the certificate domain was mistaken (e.g. certificate requested for domain.org instead of domain.com) during the purchase of the certificate, through misconfiguration (presenting another certificate instead of the expected one) or because the certificate fails to cover multiple domains or sub-domains used in the web site.
How to fix the “Name Mismatch” error
If the domain is not correctly spelled, you should contact the issuing CA for possible solutions.
Misconfiguration can be resolved by updating the site to utilize the correct certificate.
Finally, if administering a website that contains multiple domains (or sub-domains), consider using a Subject Alternative Name (SAN) certificate instead of several individual certificates. A single SAN certificate can protect hundreds of different domains and even wild-card domains (e.g. *.ssl.com) in addition to being much easier to manage and maintain than multiple certificates (not to mention that it may be easier on your pocketbook).
Conclusion
One may think of HTTPS as a black box, but it is actually a collection of interconnected components that must work in harmony for it to be effective. The warning messages we’ve described are an annoying but vital part of the Internet. We hope that providing a basic understanding of those messages can help keep users secure and make administrators more efficient.
Thank you for choosing SSL.com! If you have any questions, please contact us by email at Support@SSL.com, call 1-877-SSL-SECURE, or just click the chat link at the bottom right of this page.