Understanding SSL/TLS Certificates, CAs, and PKI: Types, Generation, History, and Security Practices

Through deep transformation of hundreds of applications and millions of pages, Alibaba has become the only company worldwide to enable site‑wide HTTPS for its e‑commerce platform.

Certificates, Private Keys and CAs

In common usage, a certificate usually refers to a server certificate, which consists of a public key together with domain name, organization information, serial number, signature, and other fields.

The private key corresponds to the public key; data encrypted with the private key can only be decrypted with the public key and vice‑versa. Because the public key cannot be used to infer the private key, you can replace a certificate while keeping the same key pair—only the additional information in the certificate changes, resulting in a new signature.

A CA (Certificate Authority) also consists of a certificate and a private key. Its certificate looks similar to a regular server certificate, except that the Basic Constraints field has CA=True, which allows the CA to issue other certificates.

Classification of Server Certificates

Certificates can be classified from two perspectives. From a commercial viewpoint, server certificates are divided into DV, OV, and EV certificates.

DV (Domain Validation) certificates only verify domain ownership, typically by sending an email to the WHOIS‑registered address and requiring the recipient to follow the instructions.

OV (Organization Validation) certificates require the DV checks plus verification of the organization, often by consulting business registries such as Dun & Bradstreet and confirming the request by phone.

EV (Extended Validation) certificates add a requirement for a financial institution’s account license or other strong proof of the entity’s legal existence, though the exact process varies among CAs.

From a business perspective, certificates can also be single‑domain, multi‑domain, wildcard, or multi‑wildcard (Wildcard SAN) certificates.

Because DV certificates have a low assurance level, they only expose domain information, whereas OV and EV certificates also display organization details; EV certificates are shown with a green address bar in browsers, giving a professional and secure impression.

DV certificates target individual users, have weaker security guarantees, and only support single‑domain or multi‑domain certificates. Free DV certificates are offered by some CAs (e.g., domestic wosign and the upcoming Let’s Encrypt).

OV and EV certificates are more expensive due to manual validation and higher insurance coverage—if a CA’s private key is compromised, the liability can exceed one million US dollars per certificate.

The most distinctive offering is the multi‑wildcard (Wildcard SAN) certificate, sometimes called WSAN. Although not always listed as a separate option on CA portals, major CAs such as DigiCert and GlobalSign support it.

How to Generate and View CA/Server Certificates

For a practical guide on creating a Root CA, issuing intermediate CAs, and generating server certificates, see: https://jamielinux.com/docs/openssl-certificate-authority/

The current two‑tier CA architecture consists of a self‑signed Root CA and an Issuing CA signed by the Root. Historically, CAs used a single Root CA to issue all certificates, but because a Root CA’s certificate has no constraints, it is risky; therefore a pathlen=0 Issuing CA is used to limit the ability to issue further CAs.

History and Incidents of CAs

VeriSign, founded in 1995, was the first major CA and was acquired by Symantec in 2010 for $1.28 billion. The current top‑5 CAs (Symantec, Comodo, GoDaddy, GlobalSign, DigiCert) control over 90 % of the market.

Notable CA incidents include:

2002 – VeriSign issued a Microsoft certificate without Microsoft’s authorization, leading Microsoft to release an emergency patch.

2008 – Researchers created a rogue CA by exploiting an MD5 collision, allowing the forged CA to be trusted by browsers.

2011 – DigiNotar was hacked by Iranian attackers, who issued more than 500 unauthorized certificates; browsers and operating systems revoked the entire Root, causing the company’s bankruptcy.

Google later discovered many MITM attacks (e.g., TURKTRUST, ANSSI) using HPKP.

PKI Overview, Vulnerabilities, and Solutions

The PKI model relies on browsers trusting a set of built‑in Root CAs; any certificate signed by these Roots is accepted. If a rogue CA issues a certificate for a legitimate domain, traffic can be hijacked without the user’s knowledge.

Two mainstream mitigation approaches are HPKP (HTTP Public Key Pinning) and Certificate Transparency.

HPKP works by having the server send a hash of the expected public key in the response header on the first visit; subsequent visits compare the presented certificate’s key hash to the pinned value and can reject mismatches.

HPKP’s drawback is the “first‑visit‑trust” assumption, which cannot be guaranteed.

Managing a large number of certificates makes it difficult to update pinning headers promptly, especially after mass revocations (e.g., Heartbleed).

Only Chrome 38+ and Firefox 36+ support HPKP, and configuration details are available online.

Certificate Transparency requires CAs to publish all issued certificates to public logs, enabling domain owners to audit whether unauthorized certificates have been issued for their domains.

Author’s Note

This article was originally titled “CA and Certificate Matters”.

---

For readers who genuinely want to learn, the author offers a giveaway: a cute “Tao” notebook (3‑in‑1 calendar, sticky notes, and notebook). To enter, comment on the article; the five comments with the most likes will receive the prize.

Finally, the author asks readers to share the article widely to increase the community.