This is the fourth in our series of insights which seek to explore and simplify the topic of SSL (and TLS) in the context of web application hosting.
In our previous insight we looked at the different types of SSL certificate validation, in this insight we’ll explore the purpose of certificate authorities and the signing process.
Certificate Authorities (CA)
A Certificate Authority (CA) is a trusted organisation who issues SSL certificates and the primary role of a CA is to establish trust.
The CA establishes trust by following robust standards and ensures the certificates it issues are only issued to validated/verifiable others (organisations and domain names).
A CA which has established trust becomes trusted by others; operating systems, web browsers and other software maintain a list of trusted certificate authorities.
Should a CA become untrustworthy, it can be removed from the list of trusted authorities.
To help establish trust and develop these standards, there is a voluntary consortium of certification authorities known as Certification Authority Browser Forum or CAB for short.
The Signing Process
CSR Generation
A certificate signing request (CSR) is typically generated in a control panel or on the command line in the format required by the web server. You will also generate a private key at the same time, it’s important to securely save both.
CSR Submission
The certificate signing request (CSR) is securely passed to a certificate authority, often via an intermediate provider such as a web hosting company.
Validation
Depending on the type of SSL certificate (see our previous insight) the certificate authority will validate the domain and/or organisation using robust process to ensure they only issue certificates to those with authority to request them.
Certificate Issuance
Once validation is completed the certificate authority will issue the certificate and securely communicate it back to you along with any recommended intermediate certificates.
Certificate Installation
Once you have the SSL certificate it is placed alongside the private key and any intermediate certificates on the web server.
The Chain of Trust
We’ve mentioned certificates, intermediate certificates, certificate authorities and trust, in the simplest terms here’s how they work together:
Root Certificate
These are issued by Certificate Authorities who have established significant trust and encouraged others to install their certificates into software such as web browsers.
Intermediate Certificates
Root certificate authorities generally speaking don’t issue certificates to end-users, they generate multiple intermediate certificates to issue the end-user certificates.
End-User SSL Certificate
An end-user SSL certificate is signed by an intermediate certificate, an intermediate certificate is signed by a root certificate, the root certificate is trusted by the web browser.
Browser Validation
When you visit a website, your web browser receives the initial certificate (and often an intermediate certificate), it verifies that the first certificate is signed by the intermediate, it verifies the intermedia is signed by the root, if verifies the root certificate is one in its database that it trusts.
The Database of Mistrust / OCSP
Now that we’ve established trust, what if someone (typically the end-user or the certificate authority) realises their certificate and private key have been disclosed publicly and can no longer be trusted? This is where the OCSP (Online Certificate Status Protocol) comes into play whereby a web browser can query a certificate authorities database of SSL certificates and find out its status.
The Post Signing Process
Once we’ve got our SSL signed and installed we then need to make sure it’s properly used in our web application as covered in our following insights.
Keep updated with the latest from Pipe Ten by subscribing below.
More in the Simplifying SSL/TLS series
- SSL Basics – What is SSL?
- SSL Certificate Terminology
- EV vs DV vs OV vs FREE SSL Certificates
- Certificate Authorities and The Signing Process
- TLS and Versions
- Web Server Headers
- Mixed Content Warning
- Testing & Tools
Author: Carl Heaton
Carl is a founder of Pipe Ten and uses his role as Technical Director to drive the company’s vision to transform business online in delivering it’s mission to forge agile technical partnerships that accelerate web success. Carl boasts an illustrious career spanning over two decades, starting as a fledgling web developer in his teens, he swiftly ascended the ranks, honing his skills in architecting secure web application infrastructure. With his finger on the pulse of emerging web technologies, Carl has tracked and influenced the ever changing world of cyber security, internet governance, industry regulations and information security compliance ensuring Pipe Ten successfully achieved and maintain ISO/IEC 27001 certification.