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.
Modern Additions to the HTTPS Ecosystem
The original certificate model above still describes the core trust relationship, but browsers, CAs, and standards bodies have added several layers on top of it to close common attack paths. Four of them are worth knowing.
HTTP Strict Transport Security (HSTS)
Serving a site over HTTPS does not, on its own, stop a network-level attacker from downgrading a first visit to plain HTTP. HSTS (RFC 6797) is a response header that instructs the browser to only ever contact the host over HTTPS for a specified duration:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
The MDN Strict-Transport-Security reference recommends a max-age on the order of one to two years, applying includeSubDomains so subdomains inherit the policy, and (once the site is stable) submitting the domain to the browser preload list so that even the first visit is protected. Without HSTS, an attacker on the network path can strip a http:// request before it is ever upgraded.
Certificate Transparency (CT)
Historically, a mis-issued or fraudulent certificate could go undetected until the affected domain owner happened to notice. Certificate Transparency is a system of publicly-verifiable, append-only Merkle-tree logs that record every certificate a participating CA issues. Domain owners, browsers, and researchers can monitor these logs to spot unauthorized issuance for their domains, and modern browsers require certificates to include Signed Certificate Timestamps proving they were logged. Free monitoring services (for example, crt.sh) let a site operator subscribe to notifications for their own domains.
CAA DNS Records
Certification Authority Authorization (RFC 8659) lets a domain owner publish, in DNS, the CAs authorized to issue certificates for that domain. A compliant CA is required to check for a CAA record before issuing, and to refuse if the record does not name it. A minimal record restricting a domain to Let’s Encrypt looks like:
example.org. IN CAA 0 issue "letsencrypt.org"
Let’s Encrypt documents that it checks CAA before every issuance. CAA does not prevent a compromised CA from ignoring the record, but it turns rogue issuance into a policy violation that is straightforward to detect via CT logs.
Shorter-Lived Certificates
Certificate revocation has always worked poorly in practice: CRLs are large and cached, OCSP soft-fails when the responder is unreachable, and stapling is not universally deployed. The industry response has been to shrink certificate lifetimes so that a compromised certificate expires on its own within days. Let’s Encrypt’s January 2025 announcement introduced an optional six-day certificate profile (alongside the existing 90-day certificates) explicitly for this reason. Six-day certificates require full automation of the renewal path — typically an ACME client such as Certbot — so they are a good fit for sites that already use automated issuance.