# What is an SSL certificate? Inside the file

> An SSL certificate is a signed file that binds your domain name to a public key, issued by an authority browsers trust. Here is everything inside it.

Updated 2026-10-27 · Security · HTML version: https://getreport.app/guides/what-is-an-ssl-certificate

An SSL certificate is a small signed file that binds one or more domain names to a public key, issued by a certificate authority that browsers already trust. That is the whole object: a few names, a key, two dates and a signature. This guide opens the file up: what each field means, how a browser decides to trust it, the types you can get and why most sites need the simplest one, and how long certificates last in 2026. For the wider picture of how the certificate, the protocol and the redirects fit together, start with [the SSL and TLS checks that matter](https://getreport.app/guides/ssl-tls-checks-that-matter).

## Quick answer

- **What it is**: a file, in a standard format called X.509 (RFC 5280), that says "this public key belongs to these domain names", signed by a certificate authority (CA).
- **What's inside**: the names it covers, the public key, the issuer, a "not before" and "not after" date, a serial number and the CA's signature. Nothing secret; anyone can read any site's certificate.
- **Why browsers believe it**: the signature chains up to a root certificate shipped inside the browser or operating system.
- **The types**: DV, OV and EV describe how much the CA checked before signing. Browsers show all three identically, so almost every site only needs DV, which is [free](https://getreport.app/guides/free-ssl-certificate-lets-encrypt).
- **How long it lasts**: at most 200 days for certificates issued since 15 March 2026, heading to 47 days by 2029, so renewal must be [automated and monitored](https://getreport.app/guides/certificate-expiry-automate-it-then-monitor-it).
- Read yours in seconds with the [SSL checker](https://getreport.app/tools/ssl-check).

## An SSL certificate is a file, nothing more

Strip the mystery away and a certificate is a few hundred bytes of structured data. The format is X.509, defined in RFC 5280, which is why error messages sometimes mention "x509". Your server holds two related files: the certificate, which is public and sent to every visitor, and the private key, which never leaves the server. The certificate contains the public half of that key pair; whoever holds the private half can prove they are the server the certificate describes.

The signature is what turns the file into proof. A certificate authority (Let's Encrypt, DigiCert, Sectigo, Google Trust Services and a few dozen others) first checks that you control the domain, then signs the file with its own key. Change a single byte afterwards, the name or a date, and the signature no longer verifies. So when your browser receives a certificate, it is reading a statement the CA made and sealed: "at the time of issue, the holder of this key controlled these names."

## What's inside an SSL certificate

Run `openssl x509 -text` on any certificate and you get something like this (abridged, for the fictional shop we use as an example):

```text
Certificate:
    Serial Number: 04:7c:9a:1e:…        (unique per certificate)
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: C = US, O = Let's Encrypt, CN = R11
    Validity
        Not Before: Oct  5 08:14:21 2026 GMT
        Not After : Jan  3 08:14:20 2027 GMT
    Subject: CN = example-shop.hr
    Subject Public Key Info: EC public key, P-256 curve
    X509v3 Subject Alternative Name:
        DNS:example-shop.hr, DNS:www.example-shop.hr
    Authority Information Access:
        CA Issuers - URI:http://r11.i.lencr.org/
```

Field by field:

- **Subject and Subject Alternative Names (SANs)**: the domain names the certificate covers. Browsers only read the SAN list (Chrome stopped reading the older Common Name field in 2017) so every name visitors type, `example-shop.hr` and `www.example-shop.hr`, must be listed there.
- **Issuer**: who signed it. Here it is R11, one of Let's Encrypt's intermediate certificates, not the root itself; CAs keep their roots offline and sign day-to-day certificates with intermediates.
- **Validity**: the "not before" and "not after" timestamps. Outside that window, every browser rejects the certificate, whatever else is right about it.
- **Public key**: the public half of the server's key pair, today usually a 256-bit elliptic-curve key (P-256) or 2048-bit RSA. This is the key the TLS handshake builds on.
- **Signature and algorithm**: the CA's signature over all of the above, and the algorithm used to make it, such as SHA-256 with RSA.
- **Serial number**: a unique identifier the CA assigns, used when a certificate has to be revoked or looked up in certificate transparency logs.
- **Extensions**: smaller flags and pointers, such as what the key may be used for, and the Authority Information Access URL, where the issuing intermediate can be downloaded.

![An SSL certificate drawn as an annotated ID card listing subject and SANs, issuer, valid-from and valid-to dates, public key and the CA's signature, with a small chain beside it connecting the certificate to an intermediate and then a root in the browser's trust store](https://getreport.app/guides/img/what-is-an-ssl-certificate/diagram.svg "The certificate is the card; the trust is the chain beside it: your certificate, signed by an intermediate, signed by a root the browser already holds.")

Notice what is not inside: the private key, and anything secret at all. Certificates are public by design (certificate transparency logs publish every one issued, searchable at crt.sh) so a certificate hides nothing about your site. It only proves something.

## How browsers decide to trust it

Your browser or operating system ships with a store of about a hundred root certificates, run by the Chrome, Mozilla, Apple and Microsoft root programs. A CA earns its place there by passing yearly audits against the CA/Browser Forum's Baseline Requirements, the rulebook every public CA must follow, and loses it when it misbehaves. Those roots are the only certificates a browser trusts unconditionally; everything else must prove a connection to one of them.

That connection is the chain. The root signs an intermediate certificate, the intermediate signs yours, and your server sends its own certificate plus the intermediates with every connection. The browser verifies each signature up the ladder until it reaches a root it holds, then checks that a name in the SAN list matches the address bar and that today falls inside the validity window. All three pass and the page loads; any one fails and the visitor gets a warning instead. When the chain is the problem (typically a server sending its certificate without the intermediate, which works on desktop Chrome and fails on phones and in apps) the diagnosis and fix are in [certificate chain errors and intermediate certificates](https://getreport.app/guides/certificate-chain-errors-and-intermediate-certificates).

The certificate itself does no encrypting. It is used once per connection, during [the TLS handshake, where the browser verifies it and both sides agree on encryption keys](https://getreport.app/guides/ssl-handshake); everything after that runs on those keys. Think of the certificate as the ID shown at the door, not the lock on it.

## The types of SSL certificates: DV, OV and EV

Certificate authorities sell three validation levels, which differ only in what the CA checks before signing:

| Type | What the CA verifies | Typical price | What visitors see |
| --- | --- | --- | --- |
| Domain Validated (DV) | You control the domain: a DNS record, a file on the server or an HTTP response | Free | Padlock |
| Organization Validated (OV) | The domain, plus that your company is registered | Paid, yearly; prices vary by CA | The same padlock |
| Extended Validation (EV) | The domain, plus a longer legal-identity check | Paid, more than OV | The same padlock |

The honest version of this table is the last column. EV certificates once turned the address bar green with the company name next to it; Chrome and Firefox removed that interface in 2019, after research showed visitors did not notice its absence, and no major browser has shown it since. OV and EV details still exist inside the certificate, one click deep, where almost nobody looks. Encryption strength is identical across all three.

So the type to get is DV, free and issued in minutes, unless a contract, tender or compliance rule explicitly demands OV or EV in writing. How to get the free one on any host is covered in [Let's Encrypt: get a free SSL certificate and keep it renewing](https://getreport.app/guides/free-ssl-certificate-lets-encrypt).

## Wildcard and multi-domain certificates

Separately from the validation level, a certificate can cover names in three shapes:

- **Single name**: in practice two SAN entries, `example.com` and `www.example.com`. Both belong on it, because visitors reach both.
- **Multi-domain (SAN)**: many unrelated names on one certificate, such as `example.com`, `example-shop.hr` and `example.de`. Let's Encrypt allows up to 100 names per certificate. One certificate to renew, but every name shares its fate and is publicly listed together.
- **Wildcard**: `*.example.com` covers every direct subdomain, `shop.example.com` or `blog.example.com`, but not `example.com` itself and not two levels down (`a.b.example.com`). Wildcards are requested together with the bare domain, and with Let's Encrypt they require the DNS-01 validation method.

None of these cost more in encryption or trust; they are bookkeeping choices about how many certificates you want to renew.

## Is it an SSL certificate or a TLS certificate?

The same file, two names. SSL (Secure Sockets Layer) was the 1990s protocol that first encrypted web traffic; TLS (Transport Layer Security) replaced it in 1999, and every SSL version has long been retired as insecure. Technically everything today is TLS, and the certificate is "a TLS certificate" or just "an X.509 certificate", but twenty-five years of habit keep "SSL" in every product name, including our checker's. Use whichever name you like; servers, however, should speak only TLS 1.2 and 1.3.

## How long SSL certificates last in 2026

Certificate lifetimes are in the middle of a planned, industry-wide shrink. In April 2025 the CA/Browser Forum passed ballot SC-081v3, which steps the maximum validity of public certificates down from the old 398 days on a fixed schedule: at most **200 days** for certificates issued on or after 15 March 2026, **100 days** from 15 March 2027, and **47 days** from 15 March 2029. Let's Encrypt already issues 90-day certificates and has announced its own steps ahead of those deadlines: 64 days from 10 February 2027 and 45 days from 16 February 2028.

The reasoning: a certificate is a snapshot of who controlled a domain at issue time, and revoking a bad one never worked reliably in browsers, so the industry is shortening how long any snapshot stays valid. The practical consequence for you is blunt: renewing by hand, on a calendar reminder, stops being realistic. When a renewal is missed, the moment the "not after" date passes every browser swaps your site for a full-page warning, and on a site that sends HSTS there is no "proceed anyway" link at all. Automating renewal on your stack, and monitoring it from outside so a silent failure gets loud, is the whole subject of [renew an SSL certificate: automate it, then monitor expiry](https://getreport.app/guides/certificate-expiry-automate-it-then-monitor-it).

## Do SSL certificates affect SEO?

Serving your site over HTTPS does: Google has used HTTPS as a lightweight ranking signal since 2014 (announced on the Google Search Central blog), and a page behind a certificate error cannot be crawled at all. The certificate's brand, price and validation level do not. Googlebot validates your certificate the way a browser does (trusted, matching, in date) and reads nothing else about it, so a free DV certificate and a $400 EV certificate are indistinguishable to search. Claims that paid certificates "boost SEO" are marketing; spend the money on content instead.

## How to look inside your own certificate

In any browser, click the icon to the left of the address (a padlock in most browsers, a "tune" icon in Chrome since 2023) then **Connection is secure → Certificate is valid**. The panel shows the subject, the SAN list, the issuer and both dates, the fields walked through above.

From a terminal, one line fetches the certificate your server actually sends and prints the headline fields:

```bash
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
```

Both of those show the certificate your device received. To test it the way a strict client does: chain validation against the public roots, days to expiry, the names, plus the protocol versions and redirects around it:

> **Free tool:** [SSL checker: free SSL certificate and TLS test](https://getreport.app/tools/ssl-check): Free SSL checker: test certificate expiry and chain, TLS versions, HTTPS redirects, HSTS and mixed content on any site, with the fix for each. No sign-up.

> **Check: Certificate expiry.** When the certificate expires, every browser shows a full-page warning and most visitors leave. Automatic renewals fail silently more often than you would expect.
>
> 1. Renew the certificate now; with Let's Encrypt, run certbot renew and check the auto-renew job's logs.
> 2. Add a monitor so you get an email 14 days before the next expiry.

> **Check: The TLS certificate chain validates.** Browsers cannot verify who issued the certificate, so visitors see "Your connection is not private" instead of your page. The usual causes are a missing intermediate certificate, an expired certificate or a name mismatch.
>
> 1. Install the full chain (your certificate plus the intermediate) that your certificate authority provides, not just the leaf.
> 2. Check that the certificate covers exactly this hostname, with and without www.

## Questions people ask

### What does an SSL certificate actually contain?

Six things: the domain names it covers (the subject and its Subject Alternative Names), the site's public key, the issuing certificate authority, a "not before" and "not after" date, a serial number, and the CA's digital signature over all of it, plus a few small extensions. It does not contain the private key, which stays on the server, and nothing in it is secret: every issued certificate is published in public transparency logs.

### What are the types of SSL certificates?

Two independent choices. By validation: DV (the CA checks you control the domain), OV (plus a company-registration check) and EV (plus a longer legal check); browsers display all three identically, so most sites need only DV. By coverage: a single name with its `www`, a multi-domain certificate listing many names, or a wildcard such as `*.example.com` covering one level of subdomains. Encryption is the same in every combination.

### Do I need to pay for an SSL certificate?

No, almost certainly not. A free DV certificate from [Let's Encrypt](https://getreport.app/guides/free-ssl-certificate-lets-encrypt) or your host uses the same encryption and shows the same padlock as any paid one, and browsers stopped displaying EV company names in 2019. Paying makes sense only when a contract or compliance rule requires an OV or EV certificate in writing, or when a legacy device cannot automate renewal.

### Is SSL the same as TLS?

In everyday language, yes: "SSL certificate" and "TLS certificate" mean the same file, and products keep the old name. Strictly, SSL is the retired 1990s protocol and TLS is its successor, in use everywhere since 1999; servers today should accept only TLS 1.2 and 1.3. The certificate does not change with the protocol; the same file serves whichever TLS version the connection negotiates.

### Does the type of SSL certificate affect SEO?

No. Google's ranking input is HTTPS itself, a lightweight signal since 2014, and search engines read nothing about your certificate beyond whether it validates. DV, OV, EV, free or paid rank identically. The only SEO damage a certificate can do is operational: an expired or broken one blocks Googlebot like any other visitor, and days of that start to cost rankings.

### Can a site with a valid SSL certificate still be unsafe?

Yes. A certificate proves you are connected to the domain in the address bar and that nobody can read the traffic in between: nothing about who runs that domain. Phishing sites routinely carry valid free certificates for their own look-alike domains. Treat the padlock as "this connection is private", never as "this site is honest", and judge the site by its address, not its icon.