padlock icon

Who should you trust? A Secure Certificate architecture on the web

Tom Lofts - 10 May 2018

If you’ve come across a website with the message ‘your connection is not private’ or ‘your connection is not secure’ then you’ve already experienced first-hand some of the difficulties which occur when trying to keep communication on the web secure.

The architecture behind the padlock icon in your browser requires co-operation from web site operators, browser makers and internet service providers to ensure everything you send and receive is kept private.

Securing the Internet

First some history – originally web traffic was sent between computers using the Hyper Text Transfer Protocol – now usually just known as HTTP. This protocol isn’t secure in that the data is visible to the owners of the networks it passes over – at a minimum – your home WiFi/office network, your ISP, the ISP of the site you’re accessing, their host, and many other networks in between.

To combat this HTTPS (HTTP Secure), an extension to HTTP was developed where the data sent has a form of encryption applied – originally, Secure Socket Layer (SSL), and now TLS (Transport Layer Security).

To fully understand the encryption process, you’ll probably need some knowledge of advanced mathematics, but in short, an encryption key is agreed upon by the browser and the server which is kept secret between them. This key is a long random piece of text which is used to encrypt the transmitted data so it cannot be accessed while it is transmitted over the internet. Once received, the key is used again then to decrypt the data allowing data to be shared back and forth between the browser and the server without anyone else being able to access it.

Encryption and Authentication

But encryption only solves part of the problem – it ensures your communication is encrypted, but not necessarily that you’re communicating with who you expect. When you visit communication between this site and your browser is encrypted, but how can you be sure that the page you see is actually from OWA and hasn’t been replaced or tampered with by anyone else?

This issue of authenticating the identity of a site is also solved by HTTPS with the use of certificates. As part of the connection, the server will present a certificate to your browser. The browser will then check that the certificate matches the domain of the site ( in our case) and that the certificate trusted – the idea being that only the site owner should be able to obtain a trusted certificate for their own domain.

Trust on the Internet

So what is a trusted certificate and how do you obtain one? While you can create a certificate yourself for your own domain (known as a self-signed certificate), this won’t be trusted by any browsers.

In order for a certificate to be trusted it needs to be signed using a certificate which is already trusted. To stop anyone from obtaining any certificate, these trusted certificates are carefully controlled by certificate authorities.

Certificate authorities are responsible for issuing certificates to site owners. Using their trusted certificates they can issue a certificate for any domain on the internet from to so they need to be very careful when they issue a certificate that it’s to the rightful owner of the domain and not an attacker attempting to impersonate them.

To combat this, certificate authorities ask the domain owners to prove they have control of the domain e.g. by placing a file on the site or receiving an email to a specific email address on the domain.

Once you’ve proved to the certificate authority you own the domain, they’ll issue you a trusted certificate, which is signed by one of their own trusted certificates – these certificates are then trusted by web browsers (Chrome, Edge, Firefox, etc.) so that when you load a site with a certificate it can check firstly that it’s been issued by a certificate authority and secondly that it trusts that certificate authority.

While it is possible to manage which certificate authorities are trusted, most people will never change these settings, giving browser vendors a large amount of power over secure sites. The most notable example of this is the distrust of certificates issued by the certificate authority Symantec which is starting to have an effect on sites already.

When the trust is broken

Back in 2017, Symantec was found to have issued a number of certificates without following industry guidelines on determining ownership - they’d provided certificates to people for domains they didn’t own.

While a certificate authority can issue a certificate for any domain, the failure to determine proper ownership was serious enough for browser makers to agree to remove or distrust Symantec’s trusted certificates from browsers, which would ultimately distrust hundreds of thousands of certificates issued by Symantec and cause warnings on all the sites using these certificates.

To try and reduce the impact on site owners (and visitors), browser makers agreed to a phasing out of Symantec issued certificates rather than an outright distrust. The proposals differed slightly between vendors, with Google’s proposal for Chrome receiving the most attention due to Chrome having the largest market share.

Google proposed that rather than distrust all Symantec certificates immediately, older certificates issued before June 2016 would become distrusted in a release of Chrome scheduled for the 15th March this year, with the remaining newer certificates becoming distrusted in a later release in September.

The impact on the web

This has resulted in some problems for websites using secure certificates, as the owner needs to determine if their certificate was issued by Symantec (which is easier said than done, as they own a number of different brands which are also affected), work out when it needs to be replaced by to avoid it becoming distrusted, and work through the process of obtaining a replacement certificate – all because they were unlucky enough to be using a Symantec provided certificate in the first place.

The March deadline for older Symantec certificates has already passed, with a number of sites being caught out using distrusted certificates. There’s still plenty of times for those sites which will be affected in September to sort out replacement certificates, but I expect we’ll still see some big names being caught out by this when September’s Chrome release is rolled out to users.

As with many of the incidents site owners and developer have had to contend with, this is just another example of how a small part of the web’s architecture can have far reaching consequences and underlines the importance of understanding the technologies your site relies on and keeping up to date on recent developments.