Understanding HTTPS Certificates
HTTPS is a complex piece of technology as, by its nature, it needs to serve several different requirements.
The end goal of HTTPS is to allow communication between two parties without anyone else being able to see what you either request or receive. Without it, things such as internet banking would be incredibly dangerous.
To reach this end, there are two separate parts.
The first is encryption. This modifies the requests between you and the website so nobody who is in the middle of the request can understand what data is being sent. The second is about being able to trust that the other party (in this case, the website) is who they say they are.
Establishing trust that the website is indeed correct is done by the use of Certificate Authorities. These are established organizations that have to obey strict standards to show that they are trustworthy.
A list of accepted certificate authorities is normally stored inside your web browser (Chrome etc) and potentially inside your operating system as a list of root certificates.
For a website to use HTTPS, it needs to negotiate with a certificate authority to get a certificate. This is about proving to the certificate authority that you are who you say you are.
For example, if you wanted to use HTTPS on your site example.com, you would request a certificate from a certificate authority who might ask you to prove that you are example.com by hosting a file at example.com/i-control-this-website.txt. The owner of the website would then need to install this certificate on the web server.
When you then view the website, it will provide you with a certificate chain, which is a list of certificates, each with information about the parent certificate that issued it. Using cryptography you can look at a set of parent/child certificates and verify that the parent certificate was used to create the child certificate.
The aim of this is to create a trust chain that should allow you to verify that the root certificate was responsible for the creation of the website certificate.
In the most simple form, a chain can consist of just the website certificate. If this points to a certificate you trust (most likely a root certificate) then it can deem the certificate trustworthy.
In practice, root certificates are very rarely used to sign certificates directly. They are normally used to sign other intermediary certificates that may either be used to sign additional intermediary certificates or the website certificate.
This means that a trust chain could consist of 5 separate certificates between your website certificate and the root authority that your computer trusts.
Missing Intermediate Certificate Chains
A common website misconfiguration is to not provide all the intermediary certificates from being provided by the web server and only provide the website certificate.
This means that the browser can’t correctly resolve whether the certificate is trusted or not.
This issue tends to be muddied by many modern browsers tending to include common intermediary certificates as part of their “accepted certificates”. This means that while the certificate chain that is provided is not complete, people using Chrome and Firefox will not see any SSL errors while using the site (however, some people using older browsers will).
From a technical perspective, the fix for this (certificate authority depending) is to ensure you’re using fullchain.pem not chain.pem
- User roles
- Search campaign
- Invisible text
- Support levels
- Uptime monitor
- Bounce rate
- Fully qualified URL
- SSL and TLS
- Content Management System
- Alternative text
- Cascading Style Sheets (CSS)
- Computed source
- HTTP status code
- Invisible text
- Link building
- Link rot
- Links to fragments of a page
- Page title