HTTPS and Certificates
The HTTPS protocol uses TLS to secure web communication. It is also called “HTTP over TLS”, or even more commonly “that little lock symbol on your browser”. The lock symbol is not the only clue a website is using HTTPS to communicate, the URL also begins with “https://”. Most web communications take place on port 80, while HTTPS traffic is sent over port 443.
HTTPS is most widely known for and used for e-commerce and online payments, but is quickly becoming standard practice in many other contexts because of the privacy and data integrity advantages it offers. (See the guide on SSL and TLS for details.) Many services now offer “HTTPS-only” as a user-configurable preference, while others are making HTTPS automatic and mandatory. Beginning in August 2014, Google Search began including HTTPS as a rank-increasing attribute in tallying website rankings.
Over the past decade, there has been a major push for making HTTPS a standard feature of all websites. The Electronic Frontier Foundation (EFF) ran a campaign called “HTTPS Everywhere” to advocate for encrypting all web communications with TLS. The extension was sunset in January 2023 — by that point, about 90% of web page visits used HTTPS and major browsers had introduced a built-in HTTPS-only mode that serves the same purpose. Another related effort called “Let’s Encrypt” offers free certificates signed by a certificate authority.
Public-Key Certificates
HTTPS uses TLS, which requires a public key to begin communication. HTTPS uses a Public-Key Certificate, often referred to as an “SSL certificate” or “SSL cert” (even though it does not use SSL anymore) to prove ownership of a public key. It validates the authenticity of the public key so that a user can recognize and trust digital signatures made using the private key which matches this public key. The certificate itself is comprised of the public key, information about the owner of the public key, a certificate start and expiration date, and the digital signature of a Certificate Authority (CA). The CA signature indicates that someone reputable has vouched for this key and other information. It also ensures that the public key has not been modified.
HTTPS in Practice
To set up a server for HTTPS, the server administrator creates a Certificate Signing Request (CSR) which is the combination of a public key and some basic information about the organization requesting the certificate. The administrator sends the CSR (along with any fees) to a Certificate Authority (CA). The CA’s role is to validate the website making the request by verifying their identity and performing a basic background check for a history of fraud, phishing, or other red flags. Then the CA issues the administrator a Public-Key Certificate for the website. The administrator installs the certificate on the web server and adds configuration information to link all activity on port 443 to the Public-Key Certificate. Going forward, when a browser requests a URL using “https://”, the request will be sent to port 443 on the server, the configuration will find the Public-Key Certificate, and an HTTPS connection will be established.
Web browsers trust CA-signed certificates because they have been pre-installed with a list of trusted certificate authorities, such as Sectigo (formerly Comodo CA, rebranded in November 2018), GoDaddy, GlobalSign, IdenTrust, DigiCert, and Let’s Encrypt. The Symantec/VeriSign/Thawte/GeoTrust roots that were once a major CA brand were distrusted by major browsers in 2018 (Chrome timeline) after the issuance business was sold to DigiCert in late 2017. Browsers display “the little lock symbol” if a certificate domain matches the current domain, has been signed by a trusted CA, and is still within the start and expiration dates. They will display warnings on invalid or self-signed certificates that ask the user if they are sure they want to trust the certificate before proceeding.
Certificate Authority
The role of the Certificate Authority is to verify the relationship between a public key and its owner. It does not guarantee more than this. It does not vouch for the owner’s integrity, the health of their business, or their past business practices. It simply asserts that the owner owns the domain name, owns this public key, and did not raise any red flags during a brief background check.
CA background checks were once a rigorous process and required providing many business documents as proof of identity. Certificates were also expensive, in part due to the labor-intensive background checks. Over time and as certificates became more popular, they became less expensive—typically costing $10-70 per year, and quickly becoming entirely free—the background checks became much more lax. The basic requirement for proof of identity in most cases has now been reduced to being capable of receiving a verification email at an address on the same domain which sounds official (admin@somesite.com, webmaster@somesite.com, etc.).
This lower threshold of identity verification has opened the door to a number of vulnerabilities in the CA validation process. Attackers can easily get certificates signed by CAs. Many attackers use public-key certificates because it makes the sites they use for malicious purposes such as phishing seem legitimate. A user does not notice who owns a certificate, they only notice that a server has a certificate. Users trust “the little lock symbol” a little too much. An attacker can go through the normal CSR process for their domains or, if they can gain control of an official-sounding email address on another domain, they can get a certificate issued on a domain they do not even own.
Extended Validation (EV) Certificates
Certificate authorities also offer Extended Validation (EV) Certificates. EV certificates are a result of the lower fees and increasingly lax verifications on regular certificates, and in many ways, they resemble the public-key certificates of old. For EV certificates, the CA performs more rigorous background checks and the certificates cost more money per year to obtain. EV certificates were once visually distinct to users because they turned the browser address bar green and displayed the official company name. However, major browsers (Chrome 77, Firefox 70, Safari 13) removed the EV indicator from the address bar in 2019 after research showed users did not understand its significance and it offered little protection against phishing. Today, EV certificate details are accessible only by clicking the padlock icon. EV certificates are sometimes required by credit card companies, usually based on the dollar amount of payments which will be accepted. It is debatable if EV certificates add any more security to the process. Certificate authorities would like customers to believe they are important because they generate higher fees. But an EV certificate will use the same public-key and same encryption; it just indicates that the business has gone through a more rigorous identity verification. And in several instances, attackers have been able to get EV certificates despite the promise of better identity validation.
Self-Signed Certificates
Certificates do not need to be signed by a Certificate Authority to be valid. They can be self-signed instead. A self-signed certificate verifies that the public key is legitimate and has not been altered. It simply does not make a third-party representation to the identity of the organization who generated the public-key. Self-signed certificates are used when two parties already trust each other’s identities. Self-signed certificates are commonly used for an organization’s internal servers.