Every time you see the padlock in your browser, behind it there is a certificate and a chain of trust. It’s the vocabulary that keeps coming back in every howto about certificates, so let’s put it in order once and for all — what a CA is, why certificates chain together, what sets DV, OV and EV apart, how they’re revoked, and how you can find out whether someone issued a certificate for your domain behind your back.

A certificate, in one line

A digital certificate (the X.509 format) binds a name to a public key, and that binding is signed by an authority you trust. Inside, in the clear, you find: the name it is valid for (in the Subject Alternative Name field), the public key, the validity dates, who issued it, and what it may be used for. There is no secret inside the certificate: the secret is the private key, which stays on the server and never leaves the device. The certificate says “this public key belongs to www.example.com“; whoever holds the matching private key can prove it, and nobody else.

The CA: why we trust a stranger

A Certificate Authority (CA) is an organization that signs certificates after verifying who asks for them. But why should your browser trust a CA’s signature? Because your device carries a trust store: a list of root certificates (the roots) considered trustworthy, installed by the operating system or the browser. If a certificate chains up — we’ll see how — to a root that is in your trust store, the padlock is green. If it doesn’t chain up, you get a security warning.

Trust, then, is not magic: it is a list. Whoever controls that list (Apple, Microsoft, Mozilla, Google) effectively decides which CAs the world trusts. Getting in requires strict audits and years; getting kicked out — if a CA misbehaves — is a matter of one update.

The chain: root, intermediate, leaf

A certificate is not signed directly by the root. A chain is formed:

leaf (your server)   ← signed by →   intermediate   ← signed by →   root (in the trust store)
  • The leaf is your server’s certificate, the one with your name. CA:FALSE: it cannot sign others.
  • The intermediate is a “working” CA that signs leaves every day. CA:TRUE, but with restricted powers: often pathlen:0 (it cannot create further CAs below it) and a limited Extended Key Usage (for example only “TLS Web Server”).
  • The root is the trust anchor: it is self-signed (subject equals issuer) and lives in the trust store.

Why this three-step dance instead of signing everything with the root? For protection. The root’s key is too precious to use every day: it stays offline, in a hardware module, in a vault. The intermediate signs the daily traffic; if an intermediate is compromised, you revoke it and bring up another without having to replace the root in billions of devices. The chain is also a chain of decreasing powers: each link can do a little less than the one above.

Cross-signing: how a brand-new root is trusted from day one

There is an elegant trick to introduce a new root. An old device doesn’t know it, so it wouldn’t find it in its trust store. Solution: the new root is cross-signed by an old root, already present everywhere. That way a device that doesn’t recognize the new root climbs one more step and reaches the old one, which it knows — and trusts.

A real example, seen in the lab: a 2026 Let’s Encrypt certificate chains up to ISRG Root YR (a new root), which is itself cross-signed by ISRG Root X1, the historic root present in every system for years. Result: the certificate is valid even on devices that have never heard of “Root YR”.

DV, OV, EV: why one is free and another costs hundreds

Here’s the paradox that confuses everyone: there are free certificates and certificates costing hundreds of euros a year (wildcards aside) — yet the encryption is identical. A 0 € certificate protects the connection exactly like a 500 € one. So what are you paying for? Not the cryptography, but the human verification work and the liability the CA takes on. The three levels:

  • DV — Domain Validated. The CA verifies only that whoever asks controls the domain — and does it automatically: put a DNS record or a file on port 80, a machine checks, done in seconds. No human, no cost: this is Let’s Encrypt’s type (OID 2.23.140.1.2.1).
  • OV — Organization Validated. The CA also verifies that the company really exists and is yours. Here the manual work kicks in: they check the legal name in the business registries, the address, and they phone you — at a number they find independently (directories like D-U-N-S/Dun&Bradstreet or public registries, not the one you wrote in the request) to hear a real person confirm the request is authorized. Days of time, some documents, a fee.
  • EV — Extended Validation. The same, but with in-depth legal verification: legal existence, years of activity, physical premises, authorized signatories, following strict CA/Browser Forum guidelines. Longer, pricier.

A word on that OID: it stands for Object Identifier and has nothing to do with SNMP. It’s the same kind of universal “hierarchical code” (the ISO/ITU tree used, yes, by SNMP MIBs too, but also by LDAP, by cryptographic algorithms…), but here it lives inside the certificate to declare what kind of validation was done. 2.23.140.1.2.1 is the code the CA/Browser Forum assigned to “Domain Validated” (read in pieces: 140 = CA/Browser Forum, 1.2.1 = DV); the siblings are …1.2.2 for OV and …1.1 for EV. Seeing it in the certificate is a standard, verifiable way for the CA to say “this is a DV”.

That’s why “they call you on the phone”: they are not checking the cryptography (that’s maths, free), they are checking that you are who you say you are. It’s a due diligence service, not an encryption one. And the price, besides the people doing the checks, often includes a warranty/insurance: the CA pays out (up to stated amounts) if it mis-issues to an impostor.

Are the padlocks all the same, or are some more “prestigious”?

Clear answer, surprising to many: today, in the browser, the padlocks are all the same. DV, OV and EV show the exact same padlock. A few years ago EV used to show the company name in green next to the address bar — it was the “prestigious padlock”. But around 2019 Chrome and Firefox removed that special indicator: studies had shown almost no user noticed or understood it, and that it could even be abused to deceive. Today the only way to see who is behind an OV/EV certificate is to click the padlock and open the details: the organization’s identity is there, written in the Subject field, but with no visual prominence over a DV.

Practical consequence: for a normal website, an EV certificate costing hundreds of euros and a free DV are, to the user’s eye, indistinguishable. OV/EV keeps meaning in specific contexts (B2B, regulated sectors, tenders, where having the legal identity inside the certificate and a contractual warranty matters), not for the padlock.

And beware the most dangerous misconception: a DV certificate is encrypted exactly like an EV, but it says nothing about who is on the other side, only that the connection to that name is encrypted and intact. That’s why even a phishing site can have a perfectly valid padlock (free, DV, for its domain). The padlock certifies the channel, not the honesty of whoever runs it: always look at the name, not just the padlock.

Checking the validation level yourself

Since the browser no longer shows it, if you need to know — typical in B2B, “am I talking to the right company?” — you read it from the certificate. By hand, in any browser: click the padlock → show/view certificate and look at the Organization (O) field of the Subject: if it’s there, it’s OV/EV; if there’s only the domain name, it’s DV. From the command line, with openssl, reading the policy OIDs:

level() {
  host="$1"
  cert=$(echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null)
  pol=$(echo "$cert" | openssl x509 -noout -text 2>/dev/null \
        | sed -n '/Certificate Policies/,/Signature/p' | grep -oE 'Policy: [0-9.]+')
  if   echo "$pol" | grep -q '2.23.140.1.1';   then lvl="EV";
  elif echo "$pol" | grep -q '2.23.140.1.2.2'; then lvl="OV";
  elif echo "$pol" | grep -q '2.23.140.1.2.1'; then lvl="DV";
  else lvl="?"; fi
  org=$(echo "$cert" | openssl x509 -noout -subject 2>/dev/null | grep -oE 'O = [^,/]+')
  echo "$host  ->  $lvl   ${org:-(no Organization)}"
}

level www.paypal.com     #  ->  EV   O = "PayPal, Inc."
level example.com        #  ->  DV   (no Organization)

Browser extensions. In Firefox you can automate it: an extension reads the certificate via the browser.webRequest.getSecurityInfo() API (with certificateChain/rawDER), checks O= and the policy OIDs, and warns you — a notification or a toolbar badge — when a site isn’t OV/EV. In Chrome this is not possible: certificate access was removed from extensions, so there only the manual check from the padlock is left.

The catch with this check. Today DV is the norm, even for very serious sites: a “not OV/EV” warning would fire on half the legitimate web, and you’d learn to ignore it. “Not OV/EV” does not mean “not trustworthy”. For B2B the right question isn’t “is it OV/EV?” but “is it really them?“: if they use OV/EV, check the O= is exactly the expected legal name; if they use DV, verify the agreed domain through independent channels and possibly pin the expected certificate’s fingerprint, or watch their CT logs.

RSA or ECDSA: which key to put in the certificate

A certificate binds a name to a public key, but that key can belong to two families, and the choice has practical consequences. Let’s Encrypt (like other CAs) issues both; on the router you choose the type in the issuance command.

  • RSA. The historic family, compatible everywhere, even with very old clients. The keys are large: 2048 bit is the common minimum, 4096 for the paranoid. Bigger = slower handshake maths and more CPU load.
  • ECDSA (elliptic curve, typically the P-256 curve). Elliptic-curve cryptography gets the same strength with much smaller keys: a 256-bit EC key is roughly equivalent to a 3072-bit RSA one. Smaller keys mean faster handshakes, less CPU and less bandwidth — a real advantage on a router or a small appliance, and on a very busy server.

The difference is not in the channel’s security (both, with current parameters, are solid), but in cost and compatibility. Today ECDSA P-256 is an excellent default: lightweight and supported by all modern clients. You stay on RSA only if you need to talk to really dated clients. Many servers keep both certificates and serve one or the other depending on what the client declares it can handle.

Expiry and revocation: two ways to “switch off” a certificate

Certificates expire on purpose: the shorter the life, the less damage a stolen key does before anyone notices. Web certificates today last at most a few weeks or months (Let’s Encrypt: ~90 days), and this forces renewal automation.

And if a certificate has to be invalidated before expiry (compromised key, mistake)? You revoke it. Historically, two mechanisms:

  • CRL (Certificate Revocation List): a list, published by the CA, of revoked certificates. The client downloads it and checks.
  • OCSP (Online Certificate Status Protocol): the client asks the CA, in real time, “is this still valid?”. Convenient, but with privacy issues (the CA sees what you visit) and scaling problems.

The 2025 trend is clear: drop OCSP. Let’s Encrypt retired it in 2025, betting on certificates with such a short life that revocation matters less (they expire before revocation is needed) plus CRLs. In practice: short life is the new revocation.

Certificate Transparency: the light on every issuance

How do you find out whether a CA — by mistake or because it was tricked — issued a certificate for your domain without you asking? Thanks to Certificate Transparency (CT): public, append-only logs (you add to them, you don’t delete) in which every certificate issued by public CAs is recorded. Browsers reject a certificate that doesn’t carry the proof of having been logged: that proof is the SCTs (Signed Certificate Timestamps) embedded in the certificate itself.

The practical consequence is powerful: you can watch your own domain. An aggregator like crt.sh shows you every certificate ever issued for your names:

curl 'https://crt.sh/?q=%25.yourdomain.com&output=json' | jq .

If a certificate you didn’t request shows up, you’ve found a mis-issuance — an attack that would otherwise have stayed invisible. CT turns a fraudulent issuance from a secret into a public fact.

CAA: stating who may issue for you

You can also do prevention, not just surveillance. The CAA DNS record (Certification Authority Authorization) lists which CAs are authorized to issue certificates for your domain. A rule-abiding CA reads the CAA before issuing: if it’s not in the list, it refuses.

yourdomain.com.   CAA   0 issue "letsencrypt.org"

It’s not a cryptographic barrier (it relies on the CA being correct), but it narrows the surface a lot: an attacker would have to trick exactly the CA you authorized.

ACME and the challenges: how you prove ownership

The protocol that automates all of this is called ACME (RFC 8555). To issue, the CA sets you a challenge that only the true owner can pass. The three forms:

  • http-01: you place a file at a precise address on your server, on port 80. The CA reads it. (Port 80 must be reachable.)
  • dns-01: you publish a TXT record in your DNS. The CA queries it. (No open port needed — handy for internal services.)
  • tls-alpn-01: you answer on port 443 with a special TLS handshake.

In the howtos we see http-01 in action (and why, since 2025, Let’s Encrypt verifies it from multiple network perspectives to defend against BGP hijacking).

Who’s behind Let’s Encrypt, and why it’s free

Let’s Encrypt is run by ISRG (Internet Security Research Group), a US non-profit founded in 2015 with a stated goal: make HTTPS the norm, free and for everyone. It is funded by donations and sponsors (large tech companies, foundations), not by charging you for certificates. Today it is the most used CA in the world.

The pros: free, fully automatic (ACME), ubiquitous and trusted everywhere; the short life of the certificates plus automation raises the average security level of the network. The cons, worth knowing: it issues DV only (no organization identity — if you need that, you turn to a commercial OV/EV CA); the 90 days force you to have working automation (a missed renewal = broken site); and relying on a single CA is a dependency — CAA and a fallback plan help.

Reference card for the “Certificates on RouterOS” series. Concepts and values verified in the field in the lab (a real Let’s Encrypt issuance on CHR 7.25): DV policy 2.23.140.1.2.1, ~90-day validity, no OCSP URL (CRL only), embedded Certificate Transparency SCTs, chain leaf → intermediate YR1 → ISRG Root YR cross-signed by ISRG Root X1. No CVE (KB card rule). Generic device.