# Bridge SSL — full text Every published page of bridge-ssl.com, in build order. Generated from the same sources as the site. --- https://bridge-ssl.com/ --- # Bridge SSL A certificate you never have to renew. Issued where the site is served, renewed without you, and a record that says when. Bridge SSL is the certificate layer of Bridge CDN: [TLS certificates](/certificates/) and the *.example.com wildcard are issued and renewed automatically where your site is served. A browser warning has no grace period: the day a certificate runs out, every visitor sees it at once. There is no file to install and no date to remember. What it covers is specific, and the specifics are the rest of this page. $0. Certificate and wildcard, included with Bridge CDN. No per-certificate charge, no renewal to buy. At commercial authorities a wildcard is a second, separately priced certificate. Covers: Domain-validated, *.example.com, Renewal. All included with the account. One wildcard per domain; nothing to install. ## Zero for the certificate. Zero for the wildcard. The account you already have pays for both. What the certificates cost example.com · one account - Domain-validated certificate included - Wildcard *.example.com included - Renewals, for as long as the domain is yours included - Installation and configuration nothing to do Included with a Bridge CDN account. Current terms live where signup does. - Here $0 Certificate and *.example.com issued and renewed for you, inside the Bridge CDN account. - Commercial authorities Sold A wildcard is a separate, separately priced certificate, renewed by you before it expires. DigiCert, GlobalSign, Sectigo, GoDaddy. - Let’s Encrypt $0 + your job The certificate is free; the DNS-01 client, the renewal job and the reload are yours to run and watch. Challenge types. The price is the same on every page of this site: nothing per certificate, nothing per wildcard, nothing per renewal. Checked 25 August 2026 against the issuers’ published pages. ## If this is not your site, nothing on this page fixes it. A certificate error is the site’s to fix, not the visitor’s, and that comes first because the opposite assumption costs people the most time. If the site is yours, the five codes below are the ones people paste into a search box most often, and each links to the page that says what it means and what to do in the next ten minutes. The five most searched browser certificate errors: the exact code, the browser that prints it, the heading the visitor sees, whose fix it is, and whether Bridge SSL removes it. | Exact code | Browser | What the visitor sees | Whose fix | On Bridge SSL | |---|---|---|---|---| | NET::ERR_CERT_AUTHORITY_INVALID | Chrome, Edge | Your connection is not private | Site owner | Removed | | NET::ERR_CERT_DATE_INVALID | Chrome, Edge | Your connection is not private | Site owner, or the visitor’s clock | Partly: a wrong device clock stays | | NET::ERR_CERT_COMMON_NAME_INVALID | Chrome, Edge | Your connection is not private | Site owner | Partly: names deeper than the wildcard | | SEC_ERROR_UNKNOWN_ISSUER | Firefox | Warning: Potential Security Risk Ahead | Site owner | Removed | | ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Chrome, Edge | This site can’t provide a secure connection | Site owner | Partly: an outdated client can still fail | Two browser windows for the same address. Before: the warning page, Your connection is not private, with the code NET::ERR_CERT_DATE_INVALID. After: the page itself, with the padlock, because the certificate is issued and presented at the edge. What the visitor sees on the day the certificate runs out, and what they see when the serving layer renewed it ahead of that day. Fix it there first. The rest of this page is about the second question, which is how to make it not come back. ## You renewed it. Or you thought you had. A certificate expiring is not the failure that hurts. The failure is the one nobody saw: the cron that did not fire, the renewal that succeeded while the server kept serving the old file, the reminder that was set on a calendar somebody left. Each of these is silent until a visitor is not. ### Waiting for someone to remember Certificate held on the server. Renewal depends on a job, a person, or both. A renewal log kept on a server: certbot renews in March and the certificate is due in June; in May the cron job produces no output twice; on the first of June the certificate expires, and support hears about it that morning. - Renewal depends on a job you don’t watch - Success reported by the thing that can fail - Old file kept serving after renewal - No grace period for visitors Silent failure. The warning is the first notification anyone gets. ### Renewed where it is served Certificate issued and used in the same place. Nothing travels, so nothing is left behind. The same period as a record kept by the serving layer: issued in March, renewed in May and presented at once, renewed again in July. Every line is written down. - Renewal ahead of expiry, not on a reminder - Issued and served by the same layer - No file on your server to go stale - Every issue and renewal written down No handover. The certificate is used where it is issued. Renewal is attempted ahead of expiry; the platform does not publish a guaranteed time for issuing or renewal. Keep an outside check on what your hostnames present. ## How Bridge SSL issues and renews at the edge. The certificate never travels. Every step of a traditional installation is a handover between you and a server, and a handover is the only place this can break. Here the certificate is issued in the layer that terminates TLS for your site, and it is used there. There is no copy to make, no chain to assemble and no service to reload, because nothing ever leaves. 1. You → Bridge CDN: Add the domain 2. Edge → Authority: Proves control of the name. HTTP-01 for a hostname; DNS-01 for a wildcard, with the record placed and removed by the platform 3. Authority → Edge: Signed certificate 4. Edge → Browser: Presented on every request. Renewed ahead of expiry by the same layer, step 2 onward, without you - Issued The authority signed it. This is what a certificate is: a signature on a public key, and issuing one costs the authority almost nothing. That is why free public authorities exist, and why the price of the same domain-validated certificate ranges from nothing to several hundred dollars depending only on who sells it. - Presented The edge is actually serving it. This is the part that breaks in a traditional setup when the file is renewed but the service is not reloaded. Here it cannot, because there is no reload. - Monitored Something outside is checking what the hostname presents. This one stays yours: a check that asks the renewing system whether renewal happened reports success until that system is the thing that failed. Issued and presented are one place. Monitored should not be, and that is the one job this does not take away from you. ## Installing a certificate is nine steps and a recurring reminder. Here it is one, and it does not come back. Nothing below is unfair to the traditional route: it is the documented procedure every certificate authority publishes, and each step exists for a reason. All nine are handovers between you and the server. ### The usual procedure (9 steps · then again before expiry) 1. Generate a private key 2. Create a signing request 3. Buy the certificate 4. Prove you control the name 5. Download the bundle 6. Copy it onto the server 7. Assemble the chain 8. Edit the server config 9. Reload the service Miss the repeat and every visitor sees a browser warning, at once, with no grace period. ### An ACME client on your server (5 steps · then a job to keep alive) 1. Install the client on the server 2. Prove control of the name 3. Point the server at the files it wrote 4. Reload the service 5. Schedule the renewal job, and watch it Renewal succeeds; the reload is a separate step that can be missed. A wildcard needs DNS-01 and API access to your DNS. ### Bridge SSL (1 step · no repeat) 1. Add the domain - Issued at the edge - Renewed ahead of expiry - Presented without a reload - Written down, per hostname 0 manual steps. Issued, renewed and presented in one layer, so there is no handover left to fail. - Handovers between you and the server 9 each one a place it can break · then again before expiry - Handovers, with an ACME client 5 two of them repeat, silently, with every renewal - Handovers on Bridge SSL 0 one action, once: add the domain Nine on one route and five on the other, none of them difficult, all of them handovers. The five-step route is automatic until the day the job that runs it is not. ## Ninety days is not the number that matters. Day sixty is. A domain-validated certificate from a public authority lives about ninety days, and the renewal is meant to happen around day sixty, leaving a month for something to go wrong and be noticed. Drawn out, the three ways of doing it differ not in the length of the line but in where on it a failure can sit unseen. Renewing with a third of the lifetime left is the window Let’s Encrypt recommends for ninety-day certificates. The platform renews ahead of expiry and does not publish its own day as a guarantee. - By hand, the failure is a person. A reminder is set, or it is not, and the certificate does not know which. - With a job, the failure is silence. The job that did not run produces no output, and the renewal that ran produces a file the server may not have loaded. - At the edge, the failure would have to be the layer serving the site. An outside monitor therefore has to be something other than that layer. Same ninety days on every route. What changes is whether anything on the line can go wrong without being written down. ## What the Bridge SSL wildcard covers. Exactly one label, like every wildcard. The Bridge SSL wildcard is *.example.com: it matches api.example.com, and it does not match eu.api.example.com. This is not a vendor limitation, it is how wildcard matching is defined: one asterisk, one label. Names one level deeper are outside it, and this page does not claim otherwise. A domain tree. example.com and its third-level names www, api and shop are covered by the wildcard *.example.com. The fourth-level names eu, us and dev under api.example.com fall outside it. One asterisk, one label, on every authority, and on this one. ## Every row below is a published fact, taken from the other side’s own documentation. No prices are quoted, because they change and because the structural difference is the point: what is one product here is two or three products elsewhere. Read the caveat under the table before you use any of this to make a decision: it matters, and leaving it out would make the comparison dishonest. How certificate price, wildcard depth, installation and renewal compare between Bridge SSL, Cloudflare Universal SSL and commercial certificate authorities. | What you get | Bridge SSL | Cloudflare Universal SSL | Commercial authorities | |---|---|---|---| | Certificate price | Included with Bridge CDN | Free on every plan | Sold per certificate | | Apex and third level example.com, api.example.com | Covered | Covered | Covered by a wildcard, sold separately | | Fourth level eu.api.example.com | Not covered — one wildcard, one label | Not covered by Universal SSL — needs Total TLS or an Advanced Certificate | Needs a second wildcard certificate | | Installation | Add the domain | Automatic once the domain is proxied | Yours: key, request, bundle, config, reload | | Renewal | The serving layer’s job | Automatic | Yours, before the expiry date | | Record of issue and renewal | Written down per hostname | Current state shown in the dashboard | Whatever your client, or you, wrote down | | Certificate on your server | None — nothing to install | None — nothing to install | Required | The caveat that belongs with that table. Cloudflare’s fourth-level limit, like ours, applies to a full setup, where Cloudflare runs the domain’s nameservers. On a partial, CNAME-based setup, each proxied hostname is issued its own certificate regardless of how deep it sits, so the depth limit does not apply there. If that is how you are set up, that row reads in their favour. Source: Cloudflare — Universal SSL. Commercial issuers referenced by their published product pages: DigiCert, GlobalSign, Sectigo, GoDaddy. Checked 25 August 2026. ## Whether this is worth switching on. The honest answer depends on how your certificates fail today, not on how many you have. - Worth switching on. You run more than one hostname, and renewal is a job somebody has to keep alive. Catalogues, APIs with regional subdomains, staging environments that multiply: each one is a certificate, and each certificate is a date. - Not the mechanism you need. You hold a certificate you must keep using, organisation- or extended-validated, or from an authority your compliance regime names, or the site cannot be served through Bridge CDN at all. There is no upload path here. - Worth switching on quietly. One domain, an ACME client that has worked for two years, nobody checking whether it still does. Nothing is wrong today. The question is whether “nobody checking” is a setup you chose or one you inherited. ## Four things this deliberately does not do. Better said here than discovered later. - You cannot bring your own certificate Bridge SSL has no certificate upload. If you hold an existing certificate (an organisation-validated or extended-validation one, or one issued by an authority your company mandates), it cannot be installed here. The whole argument above rests on the platform owning the key, and owning the key means it has to issue its own. - You cannot choose the authority The issuing authority is the platform’s decision, not a setting. If your compliance regime names a specific certificate authority, that requirement and this layer do not fit together. - There is no time commitment on issuing Certificates are obtained on demand and renewed ahead of expiry, and we do not publish a guaranteed time for either. Keep an independent check on what your hostnames present: that recommendation does not change because renewal moved somewhere else. - It does not work on a site served from anywhere else The certificate is issued and presented by the layer that terminates [TLS](/tls/) for your site, and that layer is Bridge CDN. If the site is served from your origin directly, or through another CDN, there is nothing here that can hold the key for it. Switching on Bridge SSL is switching the site’s delivery to Bridge CDN; the certificate is what you get for doing that, not a thing that can be added on its own. ## How Bridge SSL records every issue and renewal. How you know it happened. Bridge SSL writes down every certificate issue and renewal, per hostname. Not as a promise about what a browser will show, which an outside check answers better, but as a record of what this side did: the hostname, what happened to it, when, and what is now being presented. The panel below replays a stretch of such a record, one line at a time; it is an illustration of the form, not a client’s log. Recent entries Illustration, replayed — not live data Certificate log: time, hostname, event, validity and outcome. | Time | Hostname | Event | Valid to | Outcome | |---|---|---|---|---| | Mar 02 03:14 | example.com | issued | Jun 01 | presented | | Mar 02 03:14 | *.example.com | issued | Jun 01 | presented · warmed on add | | Mar 02 03:20 | api.example.com | first request | — | served by *.example.com | | Mar 09 10:41 | example.org | issued | Jun 08 | presented | | Mar 09 10:41 | *.example.org | issued | Jun 08 | presented · DNS-01, record removed | | May 02 03:14 | example.com | renewed | Aug 01 | presented | | May 02 03:14 | *.example.com | renewed | Aug 01 | presented | | May 09 10:42 | *.example.org | renewal attempt | Jun 08 | authority: 503, retry queued | | May 09 11:12 | *.example.org | renewed on retry | Aug 08 | presented | | May 14 11:02 | shop.example.com | added | — | covered by *.example.com | | Jul 02 03:14 | example.com | renewed | Oct 01 | presented | | Jul 02 03:14 | *.example.com | renewed | Oct 01 | presented | A retry is written down the same way as a success, and both lines stay. Reading this log is not the same as knowing what a visitor’s browser sees, and it does not pretend to be: for that, keep a check outside this layer. What the log answers is the question that comes first and usually goes unanswered: did the renewal actually happen, and is the new certificate the one being served. ## Where Bridge SSL sits: DNS, CDN, certificate. Three layers, one account. - DNS answers where the name points. Bridge DNS holds the records. A [wildcard](/free-wildcard-ssl/) is issued when the domain’s DNS is on Bridge DNS, because that is where the DNS-01 proof is placed and removed, by the platform rather than by you. - The CDN answers who serves the request. Bridge CDN terminates TLS and delivers the page, which is why the certificate can live there. - The certificate answers whether the browser trusts it. Bridge SSL is that layer, and only that layer: it does not deliver, cache or route anything. Keep the monitor. Keep the origin. The certificate is the part that stops being yours to carry. ## Everything above has a page behind it. Eight sections, and what sits under each. The landing argues; these explain. Each section below is a hub with its own pages underneath, written for the person who arrived from a search box with a specific error or a specific question rather than from an advertisement. ### Errors (2 pages), https://bridge-ssl.com/errors/ What each browser SSL error code means, whether you or the site owner can fix it, and where to go next. - ERR_CERT_AUTHORITY_INVALID - ERR_CERT_DATE_INVALID ### Certificates (9 pages), https://bridge-ssl.com/certificates/ A certificate is a signed statement about who controls a name. What it contains, what an authority checks, and the four stages of its life. - Certificate chain - CSR explained - Certificate revocation - SAN certificates - DV, OV and EV certificates - Wildcard certificates - Certificate formats - Self-signed certificates - Certificate authorities ### ACME (1 page), https://bridge-ssl.com/acme/ The ACME protocol (RFC 8555) gets and renews certificates with no person involved. Four steps, and how HTTP-01, DNS-01 and TLS-ALPN-01 differ. - ACME clients ### Installation (1 page), https://bridge-ssl.com/install/ Installation is the same five steps on every server. Most failures are one of those five left incomplete, and three outside checks find which. - Install an SSL certificate on Apache ### TLS (3 pages), https://bridge-ssl.com/tls/ Between clicking a link and seeing a padlock, two sides agree how to talk and one proves who it is. Where in that order each failure appears. - Forward secrecy - TLS handshake - TLS versions ### Comparisons (2 pages), https://bridge-ssl.com/vs/ Authorities differ in automation, validation levels, support and terms, not in the encryption they provide. The criteria that decide, and what to ignore. - Let's Encrypt alternative - ZeroSSL vs Let's Encrypt ### Tools (1 page), https://bridge-ssl.com/tools/ Six checks for certificates, keys and signing requests, each run on your own machine. What each one settles, and the page that… - Certificate and key match ### Glossary (6 pages), https://bridge-ssl.com/glossary/ Definitions for the terms with no section of their own here, each pointing at the page that covers the mechanism in full.… - What is HSTS? - What is mTLS? - What is SNI? - SSL vs TLS - Port 443 - What is certificate transparency? ## Bridge SSL FAQ. What people ask first. **My site is showing a certificate error right now. What do I do?** Go to the error library. The page for your exact code says what it means, who can fix it and what to do first. Bridge SSL is the second question, not the first: it is how the error stops coming back, not how it is cleared today. **How do I know a renewal actually happened?** Every issue and renewal is written to the certificate log: hostname, event, time, validity, and what is now presented. A retry is recorded the same way as a success. Keep an outside check as well: it asks what the hostname presents, not the system that renewed it. **Do I still need to monitor certificates?** Yes. A check that asks the renewing system whether renewal happened reports success right up until that system is the thing that failed. An outside check, asking what the hostname actually presents, shares nothing with the part that can break. **What happens on my server?** Nothing. TLS is terminated at the edge, so there is no certificate file on your machine, no chain to assemble and no service to reload. That is also why the whole class of “renewed successfully but the server kept serving the old one” failures cannot occur. **Is the SSL certificate really free?** The Bridge SSL certificate is included with a Bridge CDN account: there is no separate SSL plan, no per-certificate charge, and no extra line for wildcards. Bridge SSL is not sold on its own, so “free” here means “already paid for by the account you have” rather than “free to anyone with no account”. It requires the site to be served through Bridge CDN; on its own it is not a product. **Does the wildcard cover eu.api.example.com?** No. A wildcard replaces exactly one label: *.example.com covers api.example.com but not eu.api.example.com, which would need *.api.example.com. The platform issues one wildcard per domain, *.example.com, and no second one a level down. **How is a wildcard authorised?** Through a DNS-01 challenge, which is the only method by which a wildcard can be authorised at all. The platform places and removes the record, which is why a wildcard needs the domain’s DNS on Bridge DNS; a wildcard is also warmed when the domain is added, so the first request does not wait on issuance. **Can I upload a certificate I already bought?** No. Bridge SSL has no import path for a certificate bought elsewhere, and none is planned as a setting. If an existing certificate has to be used, this layer is the wrong fit. **What if I use another CDN or serve from my origin directly?** Bridge SSL cannot hold the key for a site served elsewhere. It is the certificate layer of Bridge CDN and works only for hostnames Bridge CDN serves. ## Add the domain. The certificate is the part you stop thinking about. Bridge SSL is the certificate layer of Bridge CDN, and signup lives there. Current terms, plans and everything else the account covers are on the same page. No certificate to buy, nothing to install, and no renewal date to carry. Requires the site to be served through Bridge CDN. --- https://bridge-ssl.com/acme/ --- # ACME explained: how automated certificate issuance works ACME, standardised as [RFC 8555](https://www.rfc-editor.org/rfc/rfc8555), is a protocol that lets software request, obtain, renew and revoke certificates with no person involved at any step [1]. ACME certificates are ordinary certificates: the protocol changes how a certificate authority checks the request and hands over the result, not what the certificate is [1]. The name stands for Automatic Certificate Management Environment, and knowing that helps nobody. What matters is the exchange it defines. - **Standard** — RFC 8555; the TLS-ALPN-01 challenge in [RFC 8737](https://www.rfc-editor.org/rfc/rfc8737); renewal information in [RFC 9773](https://www.rfc-editor.org/rfc/rfc9773) [1][2][3] - **What it proves** — control of each name, which is domain validation [1] - **Challenges** — HTTP-01 on port 80, DNS-01 through a TXT record, TLS-ALPN-01 on port 443 [1][2] - **Wildcard names** — of the three standard ACME challenges, only DNS-01; HTTP-01 and TLS-ALPN-01 are not allowed [4] - **Renewal** — a new order; the protocol has no separate renewal operation [1] - **Two keys** — the account key signs requests; the certificate key travels in the signing request and must differ from it [1] ## In this section - [ACME clients: how to choose one by class, not by name](/acme/clients/) — Clients differ in where they run and what they can deploy, not in the protocol. Choose by class: built into the server, scheduled, a library or a platform. - [ACME certificate renewal automation that does not fail quietly](/acme/renewal-automation/) — Automated certificate renewal fails quietly. The four steps that break, when to renew, how to test with a dry run, and how to monitor from outside. - [Let's Encrypt: what your client runs and what the authority checks](/acme/lets-encrypt/) — Let's Encrypt is a free ACME certificate authority from the nonprofit ISRG. Client steps, how challenges are checked, which ports to open. ## What the protocol does The ACME protocol starts with an account. The client generates a key pair and signs the account request with it; this account key identifies you in every later request, and it must not be the key that goes into a certificate [1]. With the account in place, a certificate takes four steps, performed by software on your side against a service run by the authority [1]. 1. **Order a certificate for some names** — The client lists the hostnames it wants covered. The authority answers with the authorizations it needs, one or more challenges for each name [1]. 2. **Prove control of each name** — The client completes one challenge per name and tells the authority it is ready; the authority then checks. This is the step everything else depends on, and the different ways of doing it are the main thing to understand. 3. **Finalize with a signing request** — The client submits a certificate signing request carrying the public key to be certified [1]. 4. **Download the certificate** — The authority issues it, and the client fetches the certificate together with its chain, as PEM by default [1]. ### Renewal and revocation [Renewing a certificate](/certificates/renewal/) with ACME means placing a new order: a certificate never changes once issued, and there is no separate renewal operation [1]. The authority can skip the challenge when an authorization the client completed earlier for that name has not expired [1]. RFC 9773 adds a way for the authority to suggest when each certificate should be renewed [3]. Revocation goes through the same interface, as a request signed by an account authorized for the certificate or by the certificate's own private key [1]. ## The three challenges Each challenge proves control of a name in a different way, and each has a situation where it is the only option. In all three, the response is built from the challenge token and a fingerprint of your account key, so it is tied to that account; the certificate authority checks it from its own side [1][2]. | Challenge | How the client proves control | What it needs from you | Wildcard names | |---|---|---|---| | HTTP-01 | serves a file at `/.well-known/acme-challenge/`, fetched over HTTP on port 80 [1] | a web server the name already points to, reachable on port 80; no DNS access | not allowed [4] | | DNS-01 | publishes a TXT record for the name [1] | the ability to change DNS automatically | allowed [4] | | TLS-ALPN-01 | presents a validation certificate during a TLS handshake on port 443, under the `acme-tls/1` protocol [2] | control of the TLS endpoint for the name | not allowed [4] | Circumstance makes the choice, not preference. Only DNS validation is left for [wildcard SSL certificates](/certificates/wildcard/) [4]. A closed port 80 rules out HTTP validation and leaves TLS-ALPN-01 or DNS-01. Everything else can default to HTTP validation, because it needs the least access. ## What automation actually requires The protocol is the easy part. What it demands of your environment is where setups succeed or fail. - **Something must run regularly** — Renewal happens on a schedule, so a process, a timer, or a platform must be responsible for it and must keep running. An automation that was set up once and stopped is worse than none, because nobody is watching. - **Something must be able to satisfy the challenge unattended** — Writing a file into the web root for HTTP-01, or updating a DNS record for DNS-01, has to happen without a person. For DNS validation this means credentials that can change your zone, which is a permission worth scoping deliberately. - **Something must deploy the result** — Obtaining a certificate is not serving it. The software must place the files and reload the server, or the new certificate sits unused while the old one runs out. ACME delivers PEM by default [1]; a server that imports a single bundle, such as a PKCS#12 file, needs the files in that [certificate format](/certificates/formats/) first. When a setup breaks, check those three before suspecting the protocol. ## What it changes operationally Three things, and the third is the easiest to overlook. - **Certificates stop being events** — No purchase, no ticket, no calendar entry. This is the visible benefit. - **Keys can be replaced at every renewal** — Each order is finalized with its own signing request, so a client can put a fresh key into every new certificate [1]. A key then need not outlive the certificate it was made for. - **A new dependency appears** — Your site's continued function now depends on software that talks to an external service on a schedule. That is a good trade against manual renewal, and it is a dependency, so it deserves the same monitoring as anything else you depend on. That dependency is the reason to watch expiry independently of whatever renews. Automation that fails silently produces the same outage as no automation at all. ## What it does not do - **ACME challenges do not verify your organisation** — They prove control of names, which is what a domain-validated certificate attests [1]. Organisation and extended validation also check the real-world identity of the requester [1]. For issuance that cannot yet be fully automated, such as extended validation, RFC 8555 describes external account binding, which can allow an ACME account to use authorizations granted to an account outside ACME [1]. The difference is covered on [certificate types](/certificates/types/). - **It does not manage your server** — Deployment is the client's job or yours, not the protocol's. When it is yours, it is the same five steps as [installing a certificate](/install/) by hand. - **It does not tie you to one authority** — A client starts from the directory URL of an ACME server, and the directory lists the address of every operation [1]. Pointing the same client at another authority means changing that URL and creating an account there. ## What ACME replaced Before ACME, obtaining a domain-validated [SSL certificate](/certificates/) was a set of manual steps. RFC 8555 lists them: generate a signing request, paste it into the authority's web page, place a challenge on the web server or in DNS, or answer an email, then download the certificate and install it [1]. The authors report that in informal usability tests, webmasters often needed 1 to 3 hours to obtain and install a certificate [1]. Automation removed the person from each of those steps, and with them the hours the procedure took. When software can obtain a certificate unattended, encrypting a site stops being a project and becomes a configuration. Shorter lifetimes make that harder to do without. Under the CA/Browser Forum Baseline Requirements, the maximum validity of a publicly trusted server certificate falls to 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029 [4]. Until a certificate expires, [revoking certificates](/certificates/revocation/) is the only way to withdraw one early, so a shorter lifetime caps how long a compromised key stays usable. ## Where to go next The [ACME clients](/acme/clients/) page covers what runs the protocol and how clients differ; Certbot, for example, describes itself as a client that fetches a certificate and deploys it to a web server [5]. [Automating certificate renewal](/acme/renewal-automation/) covers making it reliable rather than merely working. For one authority in practice, see [how Let's Encrypt checks each challenge](/acme/lets-encrypt/) and which ports it needs open. ## Automate certificates with Bridge SSL Bridge SSL is the certificate layer of [Bridge CDN](https://bridge-cdn.com/): the platform issues a certificate through ACME when a hostname needs one, serves it and renews it, so none of the three requirements above becomes something you operate. The new dependency still exists; it sits with the platform rather than with a process on your server, and checking expiry from outside applies here as well. ## FAQ ### The protocol **What is ACME?** A protocol that lets software obtain and renew certificates without a person in the loop, by proving control of the names being certified. The proof is the whole mechanism: the certificate authority sets a task only the name's operator can complete, checks the result, and signs on that basis. **Do I need to understand it to use it?** Not in detail, because a client implements the protocol on your behalf. What you do decide is which validation method fits your environment and where the client runs, and those two choices shape what can go wrong later. **Does ACME issue organisation-validated certificates?** Not through its challenges. They prove control of names, and control is exactly what domain validation certifies. For issuance that cannot yet be fully automated, such as extended validation, RFC 8555 describes external account binding, which can allow an ACME account to use authorizations granted to an account outside ACME. [1] ### Running it **Which validation method should I use?** Whichever your environment permits; its constraints decide. Of the three standard ACME challenges, wildcards allow only DNS-01. A host with port 80 closed can use TLS-ALPN-01 on port 443, or DNS-01. Everywhere else the file-based method asks for the least access and has the fewest moving parts. **What breaks in ACME automation?** The failures sit around the protocol rather than in it: the schedule stopped running and nobody noticed, the challenge cannot be completed without a person present, or the certificate was obtained successfully and never reached the service that needed it. **Is automated renewal safe to rely on?** Yes, on one condition: expiry has to be monitored by something that does not depend on the automation performing it. A check that shares the same machinery reports success right up until the moment both stop, which is the failure that turns into an outage. ## Sources 1. RFC 8555, Automatic Certificate Management Environment (ACME) — sections 1, 4, 7.1.1, 7.1.3, 7.3, 7.3.4, 7.4, 7.4.2, 7.6, 8.3, 8.4, 11.1. 2. RFC 8737, ACME TLS-ALPN-01 challenge — port 443, `acme-tls/1`. 3. RFC 9773, ACME Renewal Information (ARI) Extension — a renewal window suggested by the authority. 4. CA/Browser Forum, Baseline Requirements for publicly trusted TLS server certificates — section 3.2.2.4 (wildcard names: allowed for DNS Change, a value in a TXT record; not allowed for the ACME HTTP and TLS-ALPN methods), section 6.3.2 (maximum validity). 5. Certbot documentation, Introduction. --- https://bridge-ssl.com/certificates/ --- # What is an SSL certificate? Contents and lifecycle An SSL certificate, more precisely a TLS certificate, is a signed statement that a particular public key belongs to whoever controls a particular name. Everything else about it follows from that: what it contains, which certificate authority is willing to sign it, how long the statement stands, and what happens when it stops being true. The encryption itself does not need a certificate. What needs one is the question of who you are talking to, and that is the only question a certificate answers. - **Binds** — a public key to one or more hostnames (the subject alternative name list) - **Issued by** — a certificate authority after domain validation; organisation validation adds company checks - **Maximum validity period** — 200 days for publicly trusted certificates issued since 15 March 2026; 398 days for those issued before [1] - **Validity schedule** — 200 days from 15 March 2026, 100 days from 15 March 2027, 47 days from 15 March 2029 [2] - **Key types in use** — at least RSA 2048-bit or ECDSA P-256; the private key is never part of the certificate [3] - **Ends by** — expiry on the stated date, or revocation before it ## What a certificate contains Six things matter to anyone operating a site, and the rest is detail. - **The names it covers** — A list of hostnames the statement applies to, stored in the [subject alternative name field](/certificates/san/). This is the field browsers compare against, and it is the one that causes the most errors when it does not include what someone typed. One certificate may list several names; a multi domain certificate is nothing more than a long list. - **The public key** — The half of a key pair that anyone may hold. The private key never appears in the certificate and never leaves your control. Today that pair is at least RSA 2048-bit or ECDSA P-256 [3]. - **The validity period** — A start and an end, after which the statement no longer stands. - **The issuer** — Which authority signed it. That signature is what connects your certificate, through an [intermediate certificate](/certificates/intermediate-certificate/), to a [root certificate](/certificates/root-certificate/) in the trust store of the browser. - **The signature** — The authority's cryptographic statement over everything above. - **The subject** — Historically the primary identifier, now largely vestigial. Browsers read the name list instead; Chrome stopped consulting the common name in version 58 [4]. ## What a certificate authority checks before issuing Validation is the part that gives a certificate its meaning, and it is narrower than most people assume. A publicly trusted [certificate authority](/certificates/certificate-authority/) verifies **control of the name**, and for the common type of SSL certificate that is all it verifies. The public key in the request is signed; the private key is never seen. It does not check who you are, whether your business is legitimate, or whether your site is safe. Demonstrating that you can change what a name resolves to, or place a file where that name serves it, is sufficient. Over ACME this domain validation runs without any human intervention; the authority's software asks, your server answers, nobody reads anything [5]. Two consequences follow. Anyone who controls a domain can obtain a certificate for it, including someone who obtained that control improperly. A certificate proves control, not virtue. And whoever controls DNS effectively controls certificate issuance, which is why DNS account security is a certificate concern as much as a naming one. You can constrain which authorities are permitted to issue for your domain by publishing a CAA record that says so. That record lives in DNS rather than in any certificate; the certificate side of the arrangement is that compliant authorities check it before issuing and refuse if they are not listed. ## The lifecycle A certificate's life has four stages, and most operational trouble happens at the transitions. 1. **Request** — You generate a key pair and a [certificate signing request](/certificates/csr/) stating the names you want covered. The request carries the public key and proves you hold the private one. 2. **Validation and issuance** — The authority verifies control and signs. The whole path, from first request to a working certificate, is covered in [how to create an SSL certificate](/certificates/how-to-get/). 3. **Service** — The [certificate is installed on the server](/install/) and presented to clients together with the intermediates that make up the [certificate chain](/certificates/chain/) up to a trusted root. Omitting that second half is a frequent installation fault: it works in your own browser, which has cached the intermediate, and fails for fresh visitors and scripts. 4. **Expiry or replacement** — The statement ends on schedule and [certificate renewal](/certificates/renewal/) issues a new one; nothing is extended. If a certificate should no longer be trusted before its end date, [certificate revocation withdraws it early](/certificates/revocation/), and clients learn of this through CRLs or OCSP. Across a fleet of names, keeping track of all four stages for every certificate is the job of certificate lifecycle management. ## Choosing between the kinds SSL certificates differ along two independent axes, and conflating them is the usual source of confusion. Neither axis changes the validity period, which the certificate authority sets within the same ceiling for all of them. | Axis | Options | What changes | What does not change | |---|---|---|---| | **Validation** | DV, OV, EV | what the authority checked: control of the name only, or the organisation behind it too | encryption strength; the padlock browsers show | | **Coverage** | single name, SAN list, wildcard | how many hostnames one certificate covers | the issuance process | - **By validation** — Domain validation (DV) is automated. Organisation validation (OV) and extended validation (EV) go beyond the name: for OV the authority must verify the identity and address of the organisation [3]. The practical differences, and what browsers do and do not display about them, are on [types of SSL certificate](/certificates/types/). - **By coverage** — A single name, a list of names, or one level of subdomains. A [wildcard certificate for `*.example.com`](/certificates/wildcard/) matches `shop.example.com`. A certificate has a position on both axes. Asking "should I use a wildcard or an organisation-validated certificate" is asking two different questions at once. Whether you pay is a third question, independent of both. [Free SSL certificates](/certificates/free-ssl/) from Let's Encrypt are domain-validated certificates that browsers trust. A [self-signed certificate](/certificates/self-signed/) costs nothing either, but no browser trusts it, which confines it to development and internal use. ## What certificates do not do Four things, each of which someone expects of an SSL certificate and none of which is true. - **It does not make a site trustworthy.** A TLS certificate states that the name is controlled by whoever holds the key, which says nothing about their intentions. - **It does not protect the server.** Compromise of the machine is unaffected by the certificate on it, and a compromised server serves attacker content over a perfectly valid encrypted connection. - **It does not encrypt anything by itself.** The encryption comes from the [TLS protocol](/tls/); the certificate lets you know who you negotiated it with. Nor does it force browsers to use HTTPS at all; that is the job of an HSTS header. - **It does not confirm identity in the everyday sense** unless the authority checked identity, which for the common type it did not. ## Why validity periods keep getting shorter Certificates have become shorter-lived over the years, and the reasoning is straightforward: revocation does not work reliably. When a certificate must be withdrawn early, telling every client in time is not something the system does well, so the alternative is to limit how long any certificate remains valid in the first place. A short lifetime achieves by expiry what revocation is supposed to achieve by announcement, and it requires no client to check anything. The numbers are set by the CA/Browser Forum, the body whose Baseline Requirements every publicly trusted authority follows. From September 2020 the ceiling was 398 days. A schedule adopted in April 2025 lowered it to 200 days for certificates issued since 15 March 2026; the Baseline Requirements set 100 days from 15 March 2027 and 47 days from 15 March 2029 [1][2]. The consequence for operators is a shift in what counts as normal. Manual renewal was a plausible practice when certificates lasted years; at a 47-day lifetime it is a task every six weeks with a deadline that produces an outage when missed, and the only sane response is automation. An [expired SSL certificate](/certificates/expired/) is still the most visible way a site goes dark, and it is entirely self-inflicted. That is also why questions of the form "how long should I buy for" have become less interesting. Building a process that does not care what the number is protects you from the next change. ## Reading a certificate yourself Every browser lets you inspect the SSL certificate a site presents, including its validity period and certificate chain, through the padlock or the warning page; [how to check an SSL certificate](/certificates/check/) walks through Chrome, Firefox and Safari. The fields above are all visible there, and the two worth reading first are the name list and the validity period, because they account for most errors. For a certificate you hold as a file rather than one being served, [OpenSSL can check the certificate](/certificates/openssl-commands/): `x509 -text` renders the same fields and `verify` checks the chain. Which command you need depends on the [certificate format](/certificates/formats/) in front of you: PEM, DER, PFX and P7B hold the same certificate encoded differently. ## FAQ **What is an SSL certificate?** A file (a TLS certificate, strictly) in which a certificate authority states, under its signature, that a given public key belongs to the controller of a given hostname. Browsers use it to decide whom they are talking to before encrypting anything. **What does a certificate authority actually check?** For a domain-validated certificate, only that you control the name: a DNS record or a file at a URL it specifies. OV and EV certificates add a check of the organisation's legal existence against public registers. **Does a certificate mean a site is safe?** No. It means the connection is to the holder of the key for that name. A phishing site can hold a perfectly valid certificate for its own domain. **Does the certificate provide the encryption?** No. TLS negotiates the encryption; the certificate authenticates one party in that negotiation. Without the certificate you would be encrypting to an unknown peer. **Can I control which authorities may issue for my domain?** Yes, with a CAA record in DNS. Compliant authorities must check it and refuse to issue if they are not listed. **How long does a certificate last?** The validity period is up to 200 days for certificates issued since 15 March 2026; the CA/Browser Forum Baseline Requirements set 100 days from 15 March 2027 and 47 days from 15 March 2029. [1][2] ## Deeper reading ### Inside the certificate - [SAN certificates](/certificates/san/) — how one certificate covers many names - [Wildcard certificates](/certificates/wildcard/) — one level of subdomains only - [Certificate formats](/certificates/formats/) — PEM, DER, PFX, P7B - [DV, OV and EV](/certificates/types/) — what validation buys ### The chain of trust - [Certificate authorities](/certificates/certificate-authority/) — what CAs do and why browsers trust them - [Root certificates](/certificates/root-certificate/) — the trust store - [Intermediate certificates](/certificates/intermediate-certificate/) — what signs your certificate, and why the server sends it - [Certificate chains](/certificates/chain/) — what the server must send ### Obtaining and serving - [CSR explained](/certificates/csr/) — generating a signing request safely - [How to get a certificate](/certificates/how-to-get/) — three routes, one process - [Free SSL certificates](/certificates/free-ssl/) — Let's Encrypt and the trade-offs - [Self-signed certificates](/certificates/self-signed/) — when they are the right choice - [Installing a certificate](/install/) — server by server ### After issuance - [Renewal](/certificates/renewal/) — renew before it expires - [Expired certificates](/certificates/expired/) — what breaks and what to do now - [Revocation](/certificates/revocation/) — when it is required and how - [Checking a certificate](/certificates/check/) — browser, command line, online - [OpenSSL commands](/certificates/openssl-commands/) — read, verify, test **Related sections** - [SSL errors: every browser code explained and fixed](/errors/) — This site can't provide a secure connection, and every other browser SSL error: what each code means and whether you or the site owner can fix it. - [ACME explained: how automated certificate issuance works](/acme/) — The ACME protocol (RFC 8555) gets and renews certificates with no person involved. Four steps, and how HTTP-01, DNS-01 and TLS-ALPN-01 differ. ## Sources 1. CA/Browser Forum, [Baseline Requirements for TLS Server Certificates](https://cabforum.org/working-groups/server/baseline-requirements/documents/), §6.3.2 (version 2.3.1) — maximum validity 200 days for certificates issued on or after 2026-03-15; 398 days for those issued before. 2. CA/Browser Forum, [Ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/), adopted April 2025 — schedule of 200 / 100 / 47 days. 3. CA/Browser Forum, Baseline Requirements, §3.2.2.1 — verification of organisation identity and address; §6.1.5 — minimum key sizes. 4. Chrome for Developers, [Deprecations and Removals in Chrome 58](https://developer.chrome.com/blog/chrome-58-deprecations) — support for commonName matching in certificates removed. 5. Let's Encrypt, How It Works — ACME obtains browser-trusted certificates without any human intervention. --- https://bridge-ssl.com/errors/ --- # SSL errors: every browser code explained and fixed An SSL error means your browser could not establish a connection it considers trustworthy, so it stopped rather than continuing without telling you. The screen looks alarming by design, because the alternative is letting you send information down a connection that nobody has verified. Firefox and Safari word it their own way when the connection could not be set up at all, as [Secure Connection Failed](/errors/secure-connection-failed/) and [Safari can't establish a secure connection](/errors/safari-cant-establish-secure-connection/). The first useful question is not what the error means but **who can fix it**. Some errors are yours to resolve in seconds; most are the site owner's, and no amount of clicking will help you. Command-line tools and libraries report the same faults in their own words, for example as [SSL handshake failed](/errors/handshake-failed/) or [unable to get local issuer certificate](/errors/unable-to-get-local-issuer-certificate/). ## Find your code Every browser shows a different code for the same underlying problem. Yours is on the error screen, usually below the message and sometimes behind an "advanced" or "details" control. If you cannot see one, start with [what this screen is](/errors/your-connection-is-not-private/), which covers how to reveal the code in each browser. The heading above the code narrows it down: Chrome shows "Your connection is not private" for a certificate fault, and "This site can't provide a secure connection" when the connection failed before any certificate was checked, as with [`ERR_SSL_PROTOCOL_ERROR`](/errors/err-ssl-protocol-error/) and [`ERR_SSL_VERSION_OR_CIPHER_MISMATCH`](/errors/err-ssl-version-or-cipher-mismatch/). | Code | Underlying problem | Who fixes it | On Bridge SSL | |---|---|---|---| | [`ERR_CERT_AUTHORITY_INVALID`](/errors/err-cert-authority-invalid/) | certificate not from a trusted authority | usually the owner | **removed** | | `ERR_CERT_COMMON_NAME_INVALID` | certificate does not cover this name | the owner | partly | | [`ERR_CERT_DATE_INVALID`](/errors/err-cert-date-invalid/) | expired certificate, or a wrong device clock | either | partly | | `ERR_CERT_REVOKED` | certificate was withdrawn by its authority | the owner | **removed** | | `ERR_SSL_PROTOCOL_ERROR` | connection failed before certificates mattered | either | partly | | [`ERR_SSL_VERSION_OR_CIPHER_MISMATCH`](/errors/err-ssl-version-or-cipher-mismatch/) | no shared protocol version or cipher | the owner | partly | | `SEC_ERROR_UNKNOWN_ISSUER` | Firefox equivalent of authority invalid | usually the owner | **removed** | | `SSL_ERROR_BAD_CERT_DOMAIN` | Firefox equivalent of name mismatch | the owner | partly | | `SEC_ERROR_EXPIRED_CERTIFICATE` | Firefox equivalent of expired | either | partly | The last column is the honest one. Three of these nine are removed outright, because the certificate and its chain are issued, replaced and served by the same layer. Six are marked *partly*. A name deeper than the `*.example.com` wildcard is not covered and still produces a name mismatch. A wrong clock on a visitor's own device is never the site's to fix. An outdated client can still fail to agree a protocol version or cipher, and the edge cannot answer for a broken origin or for a middlebox on the visitor's path. Claiming otherwise would be the kind of promise this page exists to argue against. The pairs matter: `ERR_CERT_COMMON_NAME_INVALID` and `SSL_ERROR_BAD_CERT_DOMAIN` are the same fault seen through different browsers, so a fix described for one applies to the other. ## The four things that actually go wrong Behind every code in that table is one of four situations, and recognising which one you are looking at is most of the diagnosis. **The certificate does not cover the name you asked for.** A certificate is issued for specific names, and a visit to a name not on the list fails even though the certificate is perfectly valid. The usual cause is `www` and the bare domain being treated as one name when they are two. **The certificate is not trusted.** Either it was not issued by an authority the browser trusts, or the server did not send the intermediate certificates that connect it to one. The second is far more common and looks identical to the first from the outside. **The certificate is out of date.** Expired, not yet valid, or revoked. The interesting case is the device: a clock set wrongly makes every valid certificate look expired, which is why this error sometimes appears on one machine and nowhere else. **The connection failed before certificates were reached.** Protocol version mismatches, cipher mismatches, interception by antivirus or corporate proxies, and plain network problems. These produce the vaguest codes and need the most elimination. ## If you are a visitor Three checks resolve the errors a visitor can fix, and they take about a minute. **Check your device clock.** If it is wrong, certificates appear expired or not yet valid everywhere at once. A site failing on your machine while working elsewhere points here first. **Try a different network.** Public and corporate networks intercept connections, and interception is indistinguishable from an attack as far as your browser is concerned, which is the honest reason it complains. **Try without extensions or antivirus interception.** Security software that inspects encrypted traffic is doing exactly what the warning describes, and some do it badly. If none of those changes anything, the problem is at the site, and there is nothing further you can do from your side. Proceeding past the warning is possible in most browsers and it is a bad idea on any page where you would type anything. ## If you own the site The order that finds the cause fastest is fixed: check what certificate is actually being served, then whether it covers the name, then whether it is current, then whether the chain is complete. That order matters because the last one is the most commonly missed. A certificate can be valid, current, and correctly named, and still fail for a large share of visitors because the server was configured without its intermediate certificates. Browsers that happen to have cached the intermediate see no problem, which is why "it works for me" is not evidence. Each code's page covers its own causes in order of how often they occur, with the fixes separated by who applies them. ## Why the browser refuses instead of warning A question worth answering, because the strictness looks excessive until you consider the alternative. An unverified connection is the condition an interceptor needs. If browsers rendered the page with a small warning icon, the warning would be ignored the way most warnings are, and the protection would be worth nothing precisely when it mattered. Stopping is what makes the check real. The same reasoning explains why there is no way to permanently silence these warnings for arbitrary sites, and why the option to continue is deliberately awkward. A check that can be waived in one click is a check that gets waived by habit. It also explains why a certificate problem takes a site down completely rather than degrading it. There is no partial state between verified and unverified, so a forgotten renewal produces an outage, and that is the practical reason certificate maintenance deserves the attention it rarely gets until the first incident. ## Errors that are not certificate problems Two frequently-searched errors are not SSL faults and are not covered here, because treating them as such sends people down the wrong path. `ERR_TOO_MANY_REDIRECTS` is a redirect loop. It often appears alongside a certificate change, which is why it feels related, and the cause is redirect configuration rather than anything cryptographic. `ERR_CONNECTION_CLOSED` and its neighbours are network or hosting failures. The connection ended before anything about certificates was decided. ## Fix certificates with Bridge SSL Bridge SSL issues and renews certificates automatically over [the ACME protocol](/acme/), intermediate chain included, which removes the two most common causes on this page: expiry that nobody noticed and an incomplete chain that fails for some visitors and not others. Certificates cover the names you publish, so `www` and the bare domain do not become two separate problems. See what the platform offers at [Bridge CDN](https://bridge-cdn.com/). ## FAQ **What does an SSL error mean?** An SSL error means the browser could not verify the connection is what it claims to be, so it stopped rather than continuing quietly. The specific code names which check failed: the identity in the certificate, its validity dates, the chain back to a trusted root, or the ability to agree on a protocol at all. **Can I fix an SSL error as a visitor?** Sometimes, and there are exactly three causes that live on your side: a device clock set to the wrong date, a network that intercepts connections, and security software inspecting HTTPS. If none of those applies, the fault is at the site and no amount of clearing your cache will move it. **Is it safe to click through the warning?** Not on any page where you would type anything. The warning states that the identity of the other end could not be confirmed, which is precisely the condition an interceptor needs in order to read what you send. On a page you only read, the risk is lower but the certificate is still unverified. **Why does the site work for the owner but not for me?** Usually because an intermediate certificate is missing from the server's response, and the owner's browser already holds a copy from somewhere else. It fills the gap silently, so the person who configured the site sees a working page while first-time visitors see a warning. **Why do browsers show different codes?** Because each browser names the same underlying checks in its own vocabulary. `ERR_CERT_COMMON_NAME_INVALID` and `SSL_ERROR_BAD_CERT_DOMAIN` describe one fault: the certificate does not cover the name being visited. Matching the code to the check rather than to the browser is what makes diagnosis transferable. **What is the most common cause overall?** Expiry and incomplete chains, in that order. Both are failures of process rather than of technology: a date nobody watched, or an installation that copied one file instead of two. Automated issuance removes the first, and serving the chain the authority supplied removes the second. --- https://bridge-ssl.com/glossary/ --- # SSL and TLS glossary: short definitions Eight terms that come up constantly and have no section of their own on this site. Each entry here answers what the thing is; how it works and what breaks about it lives in the sections, and every definition points at the right one. The longer pages below cover terms that need more room than a definition, among them [the default HTTPS port](/glossary/port-443/), the [X.509 certificate](/glossary/x509/) format, [PEM files that carry certificates as text](/glossary/pem/), [public key cryptography and its key pairs](/glossary/public-key-cryptography/), and [pinned certificates](/glossary/certificate-pinning/) in apps. ## Terms defined here **SSL and TLS** are the old and current names for the same family of protocols, which is why the vocabulary mixes them freely and why the distinction matters less than people expect. SSH, despite the similar name, is a separate protocol; see [how SSL and SSH differ](/glossary/ssl-vs-ssh/). **TLS handshake** is the negotiation before any data moves. **Cipher suite** is the named combination of algorithms two sides agree to use for a connection. **SNI** is the field that tells a server which name is being requested, so one address can present the right certificate among many. Configuring what gets sent to an origin belongs to another site in this network. **HSTS** is a declaration that a site should only ever be reached securely, remembered by the browser for a period the site states. **mTLS** is the arrangement where both sides present certificates rather than only the server. **OCSP stapling** is the server presenting recent proof that its certificate has not been revoked, instead of leaving the client to go and ask. **Certificate transparency** is the public logging of issued certificates, which is what makes an unexpected issuance discoverable rather than silent. ## Definitions here, mechanics in the sections An entry here answers what a term means, in a form you can read in half a minute. What happens during a connection is on [TLS](/tls/), what a certificate is and how it is obtained under [certificates](/certificates/), how issuance is automated under [ACME](/acme/), and what a specific browser message means under [errors](/errors/), which sorts by the text you actually saw. A term with a section of its own is better served by that section than by a paragraph here, which is why this list is shorter than the vocabulary of the subject. --- https://bridge-ssl.com/install/ --- # Installing an SSL certificate: steps for any server Installation differs between servers in syntax and in where files live, and not at all in what has to happen. The same five steps apply everywhere, and when an installation fails, the useful question is which of the five was left incomplete. To install an SSL certificate, the server needs three things that belong together: the certificate, the private key it was issued for, and the intermediate certificates linking it to a root that browsers trust. Paths, directives and reload commands are covered per server: [installing an SSL certificate on Apache](/install/apache/), [nginx SSL certificate installation](/install/nginx/), and [an SSL certificate on IIS](/install/iis/), where the certificate is imported into the Windows store rather than read from a file. - **Sent by the server** — its own certificate first, then the intermediates; the root can be left out [1][2] - **Port** — 443, the default for https:// addresses [3] - **Names checked** — the DNS names in the certificate's Subject Alternative Name entries [4] - **Installed where** — wherever TLS terminates: the server, or a load balancer or CDN in front of it - **Finished when** — all three checks pass from outside the server ## In this section - [Install an SSL certificate on Apache](/install/apache/) — The three directives Apache needs, where each of them goes, and the version difference deciding whether the chain lives in a separate file or not. - [Install an SSL certificate on nginx](/install/nginx/) — Configure nginx for HTTPS: the chain file, listen 443 ssl, http2, TLS versions, the HTTP redirect, testing, and TLS in front of an application. - [Install an SSL certificate on IIS](/install/iis/) — Install a certificate on IIS: complete a request or import a PFX, add the https binding with SNI, do it in PowerShell, and keep it bound after renewal. - [Generate a CSR in IIS: wizard and certreq steps](/install/iis/csr/) — Generate a CSR in IIS with Create Certificate Request or certreq: pick a 2048-bit key, list every name, and keep the private key on the server. - [Export and import a certificate with its private key](/install/import-export-certificate/) — Export and import a certificate with its private key: a PFX file via certlm.msc, certutil or PowerShell, PEM files via OpenSSL, exportable keys. ## The five steps To install an SSL certificate on any server, go through these five steps in order. 1. **Generate a key and a request** — The private key stays on the server; the request goes to the authority. Covered on [certificate signing requests](/certificates/csr/). 2. **Obtain the certificate and its chain** — The authority returns your certificate and the intermediates connecting it to a trusted root. Both are needed, and the chain is the part left behind when only the certificate file gets copied. 3. **Place the files where the server expects them** — Location and permissions, with the key readable only by the account that serves it. 4. **Point the configuration at them and enable encryption on the port** — Two distinct things: telling the server where the files are, and telling it to encrypt on the port, 443 for HTTPS [3]. Doing the first without the second produces a server answering in plain text on the encrypted port, which Firefox reports as SSL_ERROR_RX_RECORD_TOO_LONG [11]. 5. **Reload and verify from outside** — Installation is not service. A configuration written and never reloaded changes nothing, and a verification performed from the same machine proves less than one performed from elsewhere. ## What you need: certificate, key and chain Whatever the server, you install the same three inputs, and they only work as a set. - **The SSL certificate** — Issued for the names you serve. It contains the public half of a key pair and nothing secret. - **The private key** — The other half, generated together with the signing request. It never leaves the server, and it has to be the key this certificate was issued for, not one from an earlier request. - **The chain** — The intermediate certificates, sent after yours so that a client can connect your certificate to a root it already holds. The root itself stays out: clients have their own copy, and TLS lets the server omit it [1][2]. Before touching any configuration, compare the public key inside the certificate with the one derived from the private key. Each command prints a hash; the two must be identical. ``` $ openssl x509 -in example.com.crt -noout -pubkey | openssl sha256 $ openssl pkey -in example.com.key -pubout | openssl sha256 ``` Different hashes mean the key belongs to another certificate, and no configuration will make that pair work. ### Two preparations - **Know which configuration is actually in use** — A server with several sites, or one that has been reconfigured over the years, commonly has files that look authoritative and are not loaded. Editing one of those produces changes that have no effect, and the time goes to disbelief rather than to diagnosis. - **Have the current certificate and chain together before you begin** — An installation can fail on its inputs even when every step is done right: downloading the certificate and forgetting the chain, or taking last renewal's chain because it was already on the server. Assembling the inputs first turns installation into a short mechanical task. ## Where each step goes wrong Knowing the failure mode of each step turns diagnosis into elimination. - **Step 2, the chain** — Serving your certificate without the intermediates produces trust errors for some visitors and not others, and works fine for whoever installed it. That makes it the fault least visible to the person who made it, explained under [SSL certificates](/certificates/), where chains have a page of their own. - **Step 3, permissions** — A key readable by more accounts than necessary is an exposure; a key unreadable by the serving account is an outage. Both are worth checking explicitly. - **Step 4, encryption not enabled** — The port is open, the files are configured, and nothing encrypts. The error is unmistakable once you know it, and baffling before. - **Step 5, not reloaded** — The first thing to check when "I installed it and nothing changed". The old certificate keeps being served until the process picks up the new configuration. ## Why the order of the steps matters The five steps are not interchangeable, and two orderings in particular cause avoidable outages. - **Do not point the configuration at files that are not there yet** — A server told to load a certificate it cannot read will refuse to start or refuse to reload, depending on the software, and on a live machine that turns a routine change into an interruption. Place the files first, then edit the configuration. - **Do not remove the old certificate until the new one is verified** — The old files cost nothing to keep for a day, and they are the fastest recovery available if the replacement turns out to be wrong. The wider point is that installation on a live server is a change with a rollback, and treating it that way costs one extra minute. A step becomes irreversible only when nobody kept the previous state. ## Verifying properly Once you install an SSL certificate, verification is three checks, from outside the server, in this order. 1. **What certificate is actually presented**, [by its dates and names](/errors/err-cert-date-invalid/) rather than by what is on disk. This catches steps 3 and 5 at once. 2. **Whether the chain is complete.** An external checker reports missing intermediate certificates; your own browser does not, as the FAQ below explains. 3. **Whether every name you serve is covered**, including the bare domain and the `www` form, which is where a name mismatch error, ERR_CERT_COMMON_NAME_INVALID in Chrome, comes from [10]. A checker performs all three at once, which is why it belongs at the end of every installation rather than only when something is wrong. From another machine, OpenSSL shows what HTTPS visitors receive: ``` $ openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -dates -ext subjectAltName $ openssl s_client -connect example.com:443 -servername example.com -showcerts /dev/null ``` The first prints the certificate's dates and names. The second lists, under `Certificate chain`, what the server sent, yours as `0`; a list ending at `0` means no intermediates were sent. `Verify return code: 0 (ok)` means OpenSSL built a path to a root it trusts. Keep `-servername`: a server hosting several sites needs it to pick the certificate [9]. ## Choose your server The specifics of file locations, configuration syntax, and reloading are on the page for your software. What differs first is the form in which each server takes the three inputs: | Server | How it takes the certificate, key and chain | |---|---| | [Nginx](/install/nginx/) | One PEM file with your certificate first and the intermediates after it (`ssl_certificate`), and the key in its own file (`ssl_certificate_key`) [5] | | [Apache](/install/apache/) | From version 2.4.8, `SSLCertificateFile` holds the certificate and the intermediates, leaf first, and `SSLCertificateKeyFile` the key; earlier versions read the chain from `SSLCertificateChainFile` [6] | | [IIS](/install/iis/) | No file paths: the certificate and its key are imported into the Windows certificate store, for example from a PFX file, and an HTTPS binding on the site selects the certificate [7][8] | When the [certificate request is generated in IIS Manager](/install/iis/csr/), IIS keeps the matching key in the store until the certificate arrives. Moving a certificate to another server means taking that key along: on IIS, an export to a PFX file and a [certificate import on the other machine](/install/import-export-certificate/). If you use a control panel or a managed platform, the five steps still apply and most of them are performed for you. What remains yours is verifying the result, which the panel's success message does not do. ## Where installation is not the answer If a delivery layer or load balancer terminates connections in front of your servers, the certificate belongs there, and installing one on the origin changes nothing visitors experience. Installing in both places is sometimes correct and is a deliberate decision rather than a default. And where certificates are issued and deployed automatically, none of this is manual work at all. The automation performs these steps, which is the point of it, and the material on [ACME certificate automation](/acme/) covers that path. Who performs the installation decides how much of this page stays yours: - **You, by hand** — All five steps, and the check from outside. - **An ACME client on your server** — It obtains and renews the certificate over the ACME protocol ([RFC 8555](https://www.rfc-editor.org/rfc/rfc8555)) [12] and performs the steps described here. The check from outside remains with you. - **A platform that terminates TLS for you** — For example, Bridge SSL is the certificate layer of [Bridge CDN](https://bridge-cdn.com/): the platform issues a certificate through ACME when a hostname needs one, serves it and renews it, so there is no certificate file of yours to install there. Checking the result from outside applies here as on every other path. ## FAQ ### Steps and where the certificate goes **What are the steps to install an SSL certificate?** Five, in order: generate a key and a signing request, obtain the certificate together with its chain, place the files where the server can read them, point the configuration at both and enable encryption on the port, then reload the service and verify the result from outside the machine. **How do I know the installation worked?** By checking from outside rather than from the machine you configured. Three answers matter: which certificate is actually presented, whether the chain reaches a trusted root, and whether every name you serve appears in it. All three can be wrong while the files on disk look perfect. **What if a load balancer sits in front?** The certificate belongs wherever connections are terminated, which is the balancer rather than the server behind it. Installing it on the origin has no effect on what visitors see, and is one of the more time-consuming ways to discover where termination actually happens. ### Chains, roots and reloads **Why does my SSL certificate work for me but not for others?** The likely cause is an incomplete chain. Your browser collected the intermediate while visiting some other site and fills the gap without telling you, while a device that has never seen it cannot complete the path to a trusted root and refuses the connection. **Do I need to install the root certificate?** No. Serve your own certificate and the intermediate certificates above it, and stop there. Clients already hold the roots they trust, and a copy arriving from your server neither adds trust nor replaces a missing one, while adding bytes to every connection. **I installed it and nothing changed.** The files are in place and the running process is still holding the previous ones, because nothing told it to re-read them. Installation and activation are two separate steps, and the second is the one people skip when the first appeared to succeed. ## Sources 1. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446), TLS 1.3, section 4.4.2 — sender's certificate first; a trust anchor may be omitted. 2. [RFC 5246](https://www.rfc-editor.org/rfc/rfc5246), TLS 1.2, section 7.4.2 — the same order; the root may be omitted. 3. [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110), HTTP Semantics, section 4.2.2 — port 443 is the https default. 4. [RFC 9525](https://www.rfc-editor.org/rfc/rfc9525), Service Identity in TLS — DNS names are checked through subjectAltName. 5. nginx documentation, ngx_http_ssl_module, ssl_certificate. 6. Apache HTTP Server 2.4 documentation, mod_ssl, SSLCertificateFile and SSLCertificateChainFile. 7. Microsoft Learn, How to Set Up SSL on IIS 7 or later. 8. [RFC 7292](https://www.rfc-editor.org/rfc/rfc7292), PKCS #12 — the format behind PFX files. 9. [RFC 6066](https://www.rfc-editor.org/rfc/rfc6066), section 3 — Server Name Indication. 10. Chromium source, net_error_list.h — CERT_COMMON_NAME_INVALID. 11. NSS source, SSLerrs.h — SSL_ERROR_RX_RECORD_TOO_LONG. 12. RFC 8555, Automatic Certificate Management Environment (ACME). --- https://bridge-ssl.com/tls/ --- # What is TLS? What happens before the padlock appears TLS, Transport Layer Security, is the protocol that encrypts HTTPS and many other connections. Between clicking a link and seeing a padlock, two sides that have never met agree on how to talk, one of them proves who it is, and both derive keys nobody watching can reproduce. All of it happens before the first byte of your actual request is sent, and every failure on this site happens somewhere in that sequence. - **Stands for** — Transport Layer Security, the successor of SSL (Secure Sockets Layer) - **Current version** — TLS 1.3, defined in [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) [1] - **Still required** — TLS 1.2, defined in [RFC 5246](https://www.rfc-editor.org/rfc/rfc5246); implementations must support it [2][3] - **Withdrawn** — SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1; none of them may be negotiated [3][4] - **Provides** — confidentiality, integrity and authentication of the server ## What TLS actually provides TLS provides three properties, separated here because they fail separately. - **Confidentiality** — What travels between the two sides is unreadable to anybody in the path. This is the property people mean when they say encrypted, and it is the least interesting of the three, because it is also the easiest to have without the others. - **Integrity** — Nothing in transit can be altered without both sides noticing. Encryption alone would not give you this: an attacker unable to read a message can still corrupt it, and integrity is what makes that detectable rather than silent. - **Authentication of the server** — You are talking to the name you asked for, rather than to somebody who arranged to be in the middle. This is the property SSL/TLS certificates exist to establish, and it is the one that fails most visibly, because a browser refuses to continue without it. Confidentiality without authentication is the dangerous combination: a perfectly encrypted connection to the wrong party protects that party's conversation with you. ## The order of events How does TLS work, step by step? A connection goes through four stages in this order, and knowing which one you are in narrows every diagnosis. 1. **A connection opens** — Ordinary networking, before any encryption exists. Failures here are network failures and look nothing like certificate problems. 2. **The handshake runs** — Both sides state what they support, agree on a version and a cipher suite, and establish keys. Nothing is encrypted at the start of this; by the end everything is. 3. **The server presents its certificate** — This happens inside the TLS handshake, not after it, and is listed apart because it fails apart. In TLS 1.3 the certificate already travels encrypted, since every handshake message after the ServerHello is [1]. The client checks it against the name it asked for, the dates it carries, and the chain behind it. This is where a browser warning comes from. 4. **Application data flows** — Your request finally leaves, encrypted. A failure at this stage is your application's, not the protocol's. ## What the handshake settles The handshake settles four questions in one exchange, which opens with the client’s first message, the ClientHello. It can also settle a fifth, which application protocol to speak, such as HTTP/2 or HTTP/1.1, through [ALPN negotiation](/tls/alpn/). - **Which protocol version** — Both sides support several and use the highest they share: TLS 1.3 is the current version, TLS 1.2 the one before it. Where they share none, the connection ends before anything else, which is one of the two ways a handshake fails for everyone at once. - **Which cipher suite** — The specific combination of algorithms used for the rest of the conversation, chosen from what both sides offer. - **Which name is being requested** — A single address can serve many names, so the client states which one it wants in the Server Name Indication extension (SNI, [RFC 6066](https://www.rfc-editor.org/rfc/rfc6066)) early enough for the server to present the matching certificate. Without this, a server could only ever hold one certificate per address. - **The keys themselves** — Derived rather than transmitted, which is why somebody recording the exchange cannot reconstruct them afterwards from what they captured. ## Which version is current: SSL and TLS compared There is no current version of SSL. The latest version of the family is TLS 1.3, and every version that still carries the SSL name has been withdrawn by the IETF, the body that publishes the standard. The name survives in habit and in product names; a connection that follows current IETF guidance runs TLS 1.2 or TLS 1.3 [3]. | Version | Defined in | Status in IETF guidance | |---|---|---| | SSL 2.0 | Netscape specification, never an RFC | prohibited by [RFC 6176](https://www.rfc-editor.org/rfc/rfc6176) | | SSL 3.0 | [RFC 6101](https://www.rfc-editor.org/rfc/rfc6101), published as a historical record | deprecated by [RFC 7568](https://www.rfc-editor.org/rfc/rfc7568): must not be used | | TLS 1.0 | [RFC 2246](https://www.rfc-editor.org/rfc/rfc2246) | deprecated by [RFC 8996](https://www.rfc-editor.org/rfc/rfc8996): must not be used | | TLS 1.1 | [RFC 4346](https://www.rfc-editor.org/rfc/rfc4346) | deprecated by RFC 8996: must not be used | | TLS 1.2 | RFC 5246 | must be supported ([RFC 9325](https://www.rfc-editor.org/rfc/rfc9325)) | | TLS 1.3 | RFC 8446 | should be supported and preferred when both sides have it (RFC 9325) | TLS 1.2 is not on its way out in these documents: the same guidance that forbids the four older versions requires TLS 1.2 alongside TLS 1.3. ## Why the details keep changing The protocol is not stable in the way its name suggests, and understanding why saves you from configuration advice that has quietly expired. [Cipher suites are removed when weaknesses are found](/tls/cipher-suites/), which means a list that was correct when somebody wrote it becomes a liability years later without anything on your server changing. Protocol versions are withdrawn by browsers on their own schedules, so a server that worked yesterday can start failing for visitors whose browser updated overnight. The practical consequence is that configuration copied from an article can leave a server worse off than its default. Defaults are maintained by people tracking these changes; a block of text in a document is not. ## Where each failure appears The stage decides the symptom, which is why the same underlying fault produces different messages in different browsers. - **No shared version or suite**, and the connection ends immediately for everybody. - **The certificate does not match, has expired, or cannot be traced to something trusted.** These are the visible warnings, and they are sorted by code on [SSL errors](/errors/). - **The chain is incomplete**, which fails for some clients and not others, because browsers are more forgiving than libraries. The mechanism is on [certificate chains](/certificates/chain/). ## What this section covers The protocol has more moving parts than this overview walks through: the handshake stage by stage, the differences between protocol versions, how to read a cipher suite, how keys are exchanged, how sessions are resumed and what that costs, how the application protocol is negotiated, what early data buys and risks, how downgrade attempts are refused, and what a client checks before accepting a certificate. Five have pages of their own: [the handshake step by step](/tls/handshake/), [the protocol versions and which to enable](/tls/versions/), [why compromising a key today does not expose yesterday's traffic](/tls/forward-secrecy/), and the two linked above, on cipher suites and on ALPN. ## In this section - [Forward secrecy: why yesterday stays private](/tls/forward-secrecy/) — If a server key is stolen tomorrow, recorded traffic from today should stay unreadable. What arrangement makes that true, and what it does not cover. - [The TLS handshake: what each step actually does](/tls/handshake/) — The TLS handshake step by step: ClientHello, ServerHello, certificate, key exchange and Finished, how TLS 1.3 differs from 1.2, and how to watch one. - [TLS versions: 1.0 to 1.3, and which to enable](/tls/versions/) — TLS 1.0 and 1.1 are deprecated; 1.2 and 1.3 are allowed. What TLS 1.3 changed, whether 1.2 is safe, and how to check and set the versions a server accepts. - [TLS cipher suites: what they are and how to read them](/tls/cipher-suites/) — A cipher suite names the algorithms one TLS connection uses. How to read a TLS 1.2 name, the five TLS 1.3 suites, and which suites a server should allow. - [ALPN: how TLS chooses HTTP/2 or HTTP/1.1](/tls/alpn/) — ALPN lets client and server agree on HTTP/2, HTTP/1.1 or HTTP/3 inside the TLS handshake. How it works, what happens without a match, and how to check it. ## What belongs elsewhere Three boundaries, so this section stays about the protocol. - **Certificates as objects** belong to [certificates](/certificates/): what one contains, what validation levels verify, and how the lifecycle runs. Here they appear only as something the handshake presents. - **Browser errors** belong to SSL errors, which sorts them by the code on screen. This section explains the mechanism behind a failure rather than helping you find yours. - **Single-term definitions** belong in the glossary. A page here explains how something works and what breaks; a glossary entry answers what a word means and sends you onward. ## FAQ ### The protocol and its names **What does TLS mean?** It stands for Transport Layer Security. It is the protocol that encrypts HTTPS connections and replaced SSL, its predecessor, whose name is still used informally. See [SSL vs TLS](/glossary/ssl-vs-tls/). **Is TLS the same as SSL?** In practice the words are used interchangeably, and only one of them names a protocol still in use. SSL was the predecessor and is long withdrawn; TLS replaced it. The older name survives in product names, file names, and habit rather than in anything on the wire. **What is the current version of SSL?** There is none. The last SSL version, 3.0, is deprecated by RFC 7568, and the latest version of the protocol is TLS 1.3, defined in RFC 8446. **What is TLS 1.2?** The version before TLS 1.3, defined in RFC 5246. Current IETF guidance still requires implementations to support it, and to prefer TLS 1.3 when both sides have it (RFC 9325). **What is TLS encryption?** Encryption set up by the TLS protocol: during the handshake the two sides agree on algorithms and derive shared keys, then every message is encrypted and protected against changes. The certificate proves who the server is; it does not do the encrypting itself. ### When something stops working **Does the padlock mean a site is safe?** No. It means the TLS connection is encrypted and the server proved it holds a certificate for that name. It says nothing about who obtained the certificate or what they intend, which is why a padlock on an unfamiliar site establishes far less than people assume. **What is negotiated during the TLS handshake?** The protocol version, the cipher suite, the name being requested, and the keys for the rest of the conversation. Both sides state what they support and the outcome is the best they share, which is why an old client and a modern server can fail to connect at all. **Why did my site work yesterday and fail today?** Usually because something outside your server changed: a browser withdrew support for a version or algorithm you were still offering, or a certificate reached its end date. Neither requires anybody to have touched your configuration, and both are invisible until they are not. **Should I copy a cipher suite configuration from a guide?** Preferably not. Such lists are correct when written and degrade quietly, because algorithms are withdrawn as weaknesses emerge and nothing updates a copied block. Current defaults are maintained by people tracking those changes; a paragraph in an article is maintained by nobody. ## Sources 1. RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 — current version; handshake messages after the ServerHello are encrypted. 2. RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2. 3. RFC 9325 (BCP 195), Recommendations for Secure Use of TLS and DTLS — implementations must not negotiate SSL 2.0, SSL 3.0, TLS 1.0 or TLS 1.1, must support TLS 1.2, should support TLS 1.3. 4. RFC 6176 (SSL 2.0 prohibited), RFC 7568 (SSL 3.0 deprecated), RFC 8996 (TLS 1.0 and TLS 1.1 deprecated). 5. RFC 6066 (TLS extensions, including Server Name Indication); [RFC 7301](https://www.rfc-editor.org/rfc/rfc7301) (Application-Layer Protocol Negotiation). --- https://bridge-ssl.com/tools/ --- # SSL tools: decode, convert and check certificates Six checks, each answering one question about a certificate, a key or a signing request. Each runs with standard tooling on your own machine, without an account, and every one of them is paired with the page that explains what its answer means, because a field read out of context settles less than it appears to. ## What is here **[Certificate check for a host](/tools/ssl-checker/).** How to read what a server presents for a name, one command per check: which names the certificate covers, when it expires, and whether the chain behind it is complete. Paired with [the chain page](/certificates/chain/). **Certificate decoder.** Paste an encoded certificate and read its fields as text. Useful when you have a file and no idea which of your names it is for. Paired with [certificates](/certificates/). **Signing request decoder and generator.** Reads what a request asks for, or assembles one correctly, which is where most re-issues go wrong. Both are paired with [signing requests](/certificates/csr/). **Format converter.** Moves a certificate between the encodings different software expects, without changing what it contains. **[Certificate and key match](/tools/certificate-key-matcher/).** Answers whether a certificate and a private key belong together. A mismatch is the single most common cause of a service that starts without complaint and then refuses every connection, and it is also the fastest thing on this list to rule out. Run it after each renewal of [ACME certificates](/acme/) as well, because most clients generate a new key every time. **Protocol and cipher check.** Reports which protocol versions and algorithm combinations a host will agree to, which is the direct way to confirm what a server actually offers rather than what its configuration file appears to say. ## What they do not do Two boundaries worth stating. None of them needs your private key to leave your machine. The certificate and key match compares public keys derived locally, and a service that asks you to upload a key is being trusted with the one file that cannot be replaced. They also do not grade a configuration or issue a letter score. What a result means is explained on the page each tool is paired with, and for a failing browser message the place to start is [errors](/errors/), which sorts by the message you actually saw. ## FAQ **Do these tools need an account?** No. Each check runs with standard command-line tooling on your own machine, without registration and without sending anything about your domain elsewhere. They exist to settle something specific in seconds, and a sign-up form would defeat that purpose entirely, which is why none of them has one. --- https://bridge-ssl.com/vs/ --- # How to choose a certificate authority: the criteria Every [publicly trusted authority](/certificates/certificate-authority/) issues certificates that browsers accept identically. The encryption is the same, the trust is the same, and no visitor can tell one from another, so the choice between authorities is rarely about security and mostly about how you will operate what they issue. What it is about instead: how issuance fits your process, which validation levels you can obtain, and what you are owed when something goes wrong. Those three, in that order, decide almost every case. ## What does not differ **The encryption.** Determined by the protocol and the server configuration, not by who signed the certificate. **Browser trust.** Any authority in the trust stores produces no warnings. Trust is binary: an authority is either present or it is not, and there is no gradation among those present. **The certificate contents.** The names, the validity period, and the signature all follow the same standards. A domain-validated certificate from one authority contains what a domain-validated certificate from another contains. If a comparison leans on any of these, it is comparing things that are identical and describing the difference as a feature. ## The criteria that decide **Automation.** Whether issuance and renewal happen through a protocol your tooling already speaks, described on [ACME](/acme/). This is the criterion with the largest practical effect, because it determines whether certificates are a recurring task or a solved problem. An authority without automated issuance imposes a manual process several times a year, at current certificate lifetimes. **Validation levels available.** Whether you can obtain organisation validation where a requirement names it, covered on [certificate types](/certificates/types/). Automated issuance handles domain validation; organisation validation involves human checks and not every authority offers it. **Support and accountability.** Whether someone is obliged to respond when issuance fails or a certificate must be revoked urgently. Free automated issuance provides documentation and community; a commercial relationship provides an obligation. Which you need depends on what a failure costs you. **Terms and warranties.** Contractual commitments that exist in paid arrangements and not in free ones. Their practical value is debatable and their absence is a real difference in what you hold. **Operational limits.** Rate limits apply everywhere and differ in shape. They matter only at scale or when something misbehaves. ## What to ignore Three criteria that appear in comparisons and answer nothing. **Encryption strength claims.** No authority provides stronger encryption than another. Such claims describe the protocol, which is your server's configuration rather than theirs. **Browser compatibility percentages.** An authority is in the trust stores or it is not. A percentage expresses that binary fact in a form designed to look like a difference. **Warranty amounts.** A headline number, structured so that claiming is rare. If one matters to you, the terms decide it, not the figure. ## Free versus paid, framed honestly The question underneath most comparisons, and it has a short answer for most cases. Free automated issuance from a publicly trusted authority is the correct default. It runs most of the encrypted web, produces certificates identical in every way a visitor experiences, and carries the automation that current lifetimes require. Paying is correct in three situations: a requirement names organisation validation, you need someone contractually obliged to respond, or a device cannot be automated and needs a longer-lived certificate. Outside those, the case for paying rests on things that do not differ. ## The criterion nobody lists: how long the authority has been trusted Trust stores are conservative, and that conservatism is a property worth understanding when an unfamiliar authority appears. Entering browser and operating system trust stores takes years of audits and operational history; removal takes considerably less once serious problems are found. A long-present authority has survived that scrutiny, while a very new one has cleared the initial bar and not yet been tested by time. This matters in one specific way, and not because of the certificates themselves. Where an authority is distrusted, every certificate it issued stops being accepted and every site holding one must replace it, on a vendor's timeline rather than anyone's convenience. That has happened before, to authorities large and well established at the time. The response is not to avoid newer authorities, which would be unfair and unnecessary. It is to keep replacement cheap: with automated issuance an emergency reissue is a routine operation rather than a project, which turns an authority-level incident from a crisis into an afternoon. Automation is not primarily about convenience; it is what makes every certificate decision reversible. ## What changes when you switch Less than people expect, and knowing this removes most of the weight from the choice. A certificate from a different authority installs exactly like a renewal from the current one: same names, the key old or new as you prefer, and a server configuration that does not care who signed it. Only the chain differs, since it comes from the new authority, and serving the old chain with the new certificate is the mistake to avoid, as described on [certificate chains](/certificates/chain/). Where automation exists, switching is a configuration change in the client. Where it does not, it is the same manual work as any renewal, which argues for automating before choosing rather than after. Two things do not travel. Any organisation validation must be performed again by the new authority, which takes time and documentation. And anything you configured to restrict which authorities may issue for your domain has to be updated, or the new authority will be refused by its own compliance check. ## How to evaluate one Four checks evaluate an authority before you commit anything. **Does it automate the challenge you need?** Wildcards require a client able to change your DNS, which narrows both the authority and the tooling. **How long does issuance take at worst?** Domain validation takes seconds; organisation validation involves human steps and a timeline worth knowing before you depend on it. **How do you revoke urgently?** The route and its speed matter more than any feature, and both are worth establishing before an incident. **Can you leave?** Certificates are short-lived and replaceable by definition, so switching is cheaper here than in most infrastructure decisions, and reversible at the next renewal. ## Where authorities are compared here Provider by provider, with what each does differently rather than a score: [Let's Encrypt](/vs/lets-encrypt/) and [ZeroSSL](/vs/zerossl/). Both follow the same rule as this page: strengths stated first, differences presented as properties and never as verdicts, and nothing resting on claims that cannot be checked. ## Certificates as part of the stack with Bridge SSL Bridge SSL issues and renews certificates as part of serving your site, so the choice of authority becomes an implementation detail rather than a decision you operate. The criteria on this page still apply to the arrangement: automation is the point, validation levels are what they are, and what happens when something fails is worth asking about before it does. See what the platform offers at [Bridge CDN](https://bridge-cdn.com/). ## FAQ **Does the certificate authority affect security?** No. Encryption is decided by the protocol and your server configuration, neither of which the authority touches, and trust is binary: an authority is either in the browser's store or it is not. Two certificates from different authorities protect a visitor identically. **What actually distinguishes authorities?** Five things, none of them cryptographic: whether issuance can be automated with the protocol your tooling speaks, which validation levels are on offer, whether anyone is contractually obliged to answer you, what the terms commit to, and how the operational limits are shaped. **Should I pay for certificates?** Only in three situations: a requirement explicitly names organisation validation, you need a party under contract to respond during an incident, or a device cannot be automated and needs a longer-lived certificate. Outside those, paying buys nothing a visitor could ever notice. **Are free certificates less trusted by browsers?** No, and the question rests on a misunderstanding of how trust works. A browser either holds an authority's root or it does not; there is no scale in between, and no field in the certificate records what it cost. Most of the encrypted web runs on free issuance. **How hard is it to switch authorities?** Easier than almost any other infrastructure change, because certificates are short-lived and replaced routinely in any case. The names stay the same, the server configuration does not care who signed, and the one thing that genuinely differs is the chain you must serve alongside the new certificate. **What should I check before choosing?** Four things, all answerable before committing: whether issuance can be automated for the challenge your setup requires, how long issuance takes in the worst case, what the route to an urgent revocation looks like, and how easily you could leave again if the answer disappoints. --- https://bridge-ssl.com/acme/clients/ --- # ACME clients: how to choose one by class, not by name Every client implements [the same ACME protocol](/acme/), so the certificate you receive is identical whichever one you use. What differs is where the client runs, what it is able to do after obtaining a certificate, and how it behaves when something goes wrong, and those three differences are what should decide the choice. Choosing by those properties is durable. Choosing by a list of names is not, because the list changes and the properties do not. ## The four classes **Built into the server.** The software that terminates connections obtains certificates itself. Nothing separate runs, nothing needs to deploy anything, and the certificate is in use the moment it exists because the thing that got it is the thing that serves it. [Caddy](https://caddyserver.com/docs/automatic-https) works this way: its documentation describes certificates provisioned and renewed for every site it serves. **A separate program run on a schedule.** The traditional arrangement: a tool runs periodically, renews what needs renewing, writes files, and reloads the server. Flexible, works with anything, and has the most moving parts. [Certbot](https://certbot.eff.org/) and [acme.sh](https://github.com/acmesh-official/acme.sh) are examples. Running Certbot on your own server is one of [the two routes to a Let's Encrypt certificate](/acme/lets-encrypt/). **A library inside your own application.** The application obtains and manages its own certificates. Suited to software distributed to others, or to services that create hostnames dynamically. [lego](https://go-acme.github.io/lego/) is one, published as both an ACME client and an ACME library written in Go. **A platform that does it for you.** Certificates are a property of the hosting or delivery layer rather than something you operate. Nothing runs on your side at all. Those four cover essentially everything, and the differences between individual tools within a class are much smaller than the differences between classes. ## The questions that decide Five questions decide between clients, in the order that eliminates options fastest. **What terminates your connections?** If it is software that can obtain certificates itself, that is usually the answer, because the deployment problem disappears entirely. If termination happens on a platform, the question is already settled. **Can the client deploy the result?** Obtaining a certificate is the easy half. Something must place the files and reload the service, and a client that cannot do that leaves you writing the missing step yourself, which is where most homemade automation breaks. **Which challenge do you need?** Wildcards require DNS validation, so the client must be able to change your DNS, which not all can do for every provider. **What happens when it fails?** Whether failures are visible, whether they are retried, and whether anything reports them. [A client that fails silently](/acme/renewal-automation/) is functionally the same as no client at all until the certificate expires. **Who maintains it?** Anything running unattended for years needs to still be receiving updates. This matters more than feature comparisons, and it is the question most easily checked and most often skipped. ## What the class decides for you Each class has a characteristic failure and a characteristic strength, and knowing them predicts your experience better than any feature table. A client built into the server cannot fail to deploy, because there is nothing to deploy. The cost is coupling: certificate behaviour is whatever that software implements, and changing servers means revisiting it. A separate program works with anything, and pays for it in joints. The schedule, the challenge, the file placement and the reload are four things that can stop working independently, and only the last two are visible from outside. A library keeps certificates with the application wherever it runs. In exchange, certificate management becomes your code's responsibility, including its failures. On a platform none of that applies, which is both the point and the limit. The behaviour is the platform's to define, and where it does something you need differently there is often no lever. ## What not to choose on Three criteria look relevant to choosing a client and are not. **Feature counts.** The protocol is the same. Extra features usually concern integration with specific providers, which matters only if you use that provider. **Popularity.** A widely used client is well tested and is not therefore suited to your termination arrangement, which is the question that decides. **Speed of issuance.** Issuance takes seconds in every case, and renewal happens well before expiry, so a difference measured in seconds affects nothing. ## Where the client should run A question people answer by default rather than deliberately, and the default is often wrong. **On the server that terminates connections** is the obvious choice and the right one when that server is long-lived and managed directly. The certificate is obtained where it will be used, and nothing has to travel. **On the machine that builds or deploys** suits infrastructure rebuilt from images, where anything written onto a running server is lost at the next deployment. Here the certificate belongs in the deployment pipeline, not on the instance. **Somewhere central** suits fleets: one place obtains certificates and distributes them, which avoids every instance holding credentials and avoids rate limits from many machines requesting the same names. In Kubernetes, [cert-manager](https://cert-manager.io/docs/) plays this role inside the cluster. The question that decides is what happens to the server. If it is replaced regularly, a client running on it will be replaced too, and whatever it obtained goes with it. That mismatch is a recurring cause of automation that worked once and then quietly stopped. ## The one thing to verify before committing Whether it can deploy to your setup, end to end, unattended. Obtain a certificate with it and let it complete the whole sequence, including placing files and reloading, then confirm from outside that the new certificate is being served. That single test distinguishes a client that will work for years from one that will need a person every renewal, and it takes one run rather than a comparison. If the sequence needs a script you write to bridge a gap, that script is now part of your certificate infrastructure and deserves the same monitoring as everything else. ## FAQ **Does the choice of client affect the certificate?** No. Every client speaks the same protocol to the same authority, so the certificate that comes back is identical regardless of which one asked. The choice affects how the request is made and what happens afterwards, never the artefact itself. **What is the most important criterion?** Whether the client can install the result into your setup without a person present. Obtaining a certificate is the easy half and every client does it; placing the files, reloading the service, and doing that again in sixty days is where the differences live. **Should I use the client built into my server?** Usually, where one exists and covers your validation method. A server that obtains its own certificates removes deployment as a separate step, and a step that does not exist cannot fail silently, and silent failure is the most common way this breaks. **Do I need a specific client for wildcards?** You need one that can change your DNS records unattended, because wildcards can only be validated that way. That narrows the field to clients with a plugin for your DNS provider, and it makes the provider's interface part of your certificate infrastructure. **How do I compare clients fairly?** By class first, then by the questions above. Feature counts and popularity predict very little, because the thing that decides the outcome is whether the client fits where your connections are terminated and what it is allowed to change there. **What if I have to write a script to make it work?** Then the script is part of your certificate infrastructure and deserves the same treatment as the rest of it: version control, a place where its failures are visible, and someone who knows it exists. Undocumented glue is what turns a renewal into an incident two years later. --- https://bridge-ssl.com/acme/renewal-automation/ --- # ACME certificate renewal automation that does not fail quietly Automated certificate renewal with [the ACME protocol](/acme/) replaces a certificate before it expires with no person involved: a client proves control of the domain, receives the new certificate, installs it and reloads the server. It rarely fails loudly. It stops running or stops completing, the old certificate keeps working, and the outage arrives weeks later when it expires. This page covers how renewal automation breaks, how to test it, and how to monitor it so that a failure shows up while there is still time to act. ## Quick facts | | | |---|---| | When to renew | when about a third of the lifetime remains, or when the authority's ARI says so | | Test it | `certbot renew --dry-run` or your client's equivalent, against the staging environment | | Reload after renewal | a deploy hook, for example `--deploy-hook "systemctl reload nginx"` | | Monitor | the certificate each hostname serves, checked from outside | | Why it matters more now | public certificate lifetimes fall to 200, 100 and then 47 days (SC-081v3) | ## The four steps that can fail Automated renewal is a chain of four steps, and each can stop working without affecting the others. **The schedule.** Something must run the client periodically, usually a systemd timer or a cron job. Timers get disabled during maintenance, containers get rebuilt without them, and servers get replaced by ones where nobody set them up. `systemctl list-timers` shows whether a timer is active and when it last ran. **The challenge.** Validation must still succeed. A redirect added months ago, an application that takes over the `/.well-known/` path, a firewall change, or rotated DNS credentials each break it silently. How the challenge types differ is on [ACME](/acme/). **The deployment.** The new certificate must reach the place that serves it. On a single server the client writes the files; with a load balancer, a container image or several servers, a separate step copies them. Renewal that succeeds while deployment fails looks most like everything working. **The reload.** The server must load the new files. Without a reload, a correctly renewed and correctly deployed certificate is not the one visitors receive. In Certbot, a deploy hook runs only after a successful renewal: ```text $ certbot renew --deploy-hook "systemctl reload nginx" ``` Only the last two are visible from outside, and only once the old certificate is close to expiry. That asymmetry is the whole problem. ## When renewal should happen Renew early enough to survive a few failed attempts. A common rule is to renew when a third of the lifetime remains: about 30 days before expiry for a 90-day certificate. Most clients do this by default and try twice a day, so a temporary failure is retried long before it matters. Authorities can also tell clients when to renew. ACME Renewal Information, ARI, defined in [RFC 9773](https://www.rfc-editor.org/rfc/rfc9773), lets the authority suggest a renewal window for each certificate, and ask for earlier renewal when it has to revoke certificates in bulk. Clients that support ARI follow that window instead of a fixed number of days. [Renewing a Let's Encrypt SSL certificate](/acme/lets-encrypt/) works this way: the authority asks clients to check ARI, renew at random times and retry with backoff. Shorter lifetimes make this more pressing. Under the CA/Browser Forum [ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/), the maximum lifetime falls to 47 days by March 2029. At that point each certificate renews roughly every month, and a renewal that silently stops is an outage within weeks. ## Test the whole cycle before relying on it Waiting to see whether automation renews on its own is a slow way to discover a broken deployment step. Test it on the day you set it up: ```text $ certbot renew --dry-run ``` A dry run performs the full renewal against the authority's staging environment, without replacing your certificate and without counting against production rate limits. Other clients have the same option under a different name. Then force one real renewal and confirm from outside that the new certificate is the one being served, by its dates: ```text $ openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -dates ``` That exercises all four steps in one run. Repeat the test after any change to the server, the routing, the DNS provider or the credentials, since those are what break the challenge and the deployment. ## Monitor the outcome, not the process Monitoring the renewal job tells you whether it thinks it succeeded. Monitoring the certificate tells you what visitors get. They differ in exactly the cases that matter: a job that stopped being scheduled reports nothing, and nothing looks like success. The check that works is external and simple. Ask each hostname which certificate it presents and how many days it has left, from a machine that does not share credentials or hardware with the renewal system: ```text $ openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -checkend 1209600 ``` The command exits with status 1 when the certificate expires within 14 days. Any monitoring system can run it, or an equivalent HTTPS check, on a schedule. ## Alert on the right threshold Alerting the day before expiry is too late. Alerting on every failed renewal attempt is noise, because transient failures are normal and are retried. Set the alert where renewal should already have happened. With 90-day certificates renewed 30 days ahead, a certificate with fewer than about 20 days left means automation has not worked for ten days, and there is still time to fix it calmly. Scale the threshold with the lifetime: with 47-day certificates, alert at about a week left. That one alert catches all four failing steps, because they all end the same way: the served certificate stops being replaced. ## Cover every certificate Monitoring the website's certificate confirms the one most likely to be noticed anyway. The certificates that lapse are the ones nobody watches: mail servers, APIs, load balancers, internal dashboards, devices. Keep a list of every certificate in service, where it terminates and what renews it, and monitor the list rather than one hostname. Where the list is kept by hand it drifts, so derive it from what is deployed where possible. [Certificate Transparency](/glossary/certificate-transparency/) logs also show every public certificate issued for your domains, which helps find ones you forgot. ## Rate limits and retries Authorities limit how often certificates can be requested for the same names. A homemade script stuck in a loop, retrying immediately, can use up that allowance and stay blocked after the original problem is fixed. Use a client that backs off between attempts, which standard clients do by default, and debug issuance against the [staging environment](https://letsencrypt.org/docs/staging-environment/) rather than production. ## What to do when it does fail 1. **Restore service first.** Obtain and install a certificate by whatever works now, as described on [renewal](/certificates/renewal/). 2. **Find which step failed.** The client's log usually tells: no entry at all points at the schedule, a validation error at the challenge, a successful renewal with an unchanged served certificate at deployment or reload. 3. **Ask why nobody noticed.** That is a different question from why it failed. If monitoring existed and did not fire, fix the monitoring. Choosing a client that can deploy and reload on its own removes two of the four steps; see [ACME clients](/acme/clients/). ## FAQ **Why does automated certificate renewal fail silently?** Because nothing changes when it stops. The existing certificate keeps working until it expires, so the failure surfaces weeks later, long after the change that caused it. **How do I test certificate renewal?** Run a dry run against the staging environment, for example certbot renew --dry-run, then force one real renewal and confirm from outside that the served certificate has new dates. **How often does Certbot renew certificates?** Certbot's timer or cron job typically runs twice a day and renews certificates that are within 30 days of expiry, unless the certificate authority's ARI suggests a different time. **How do I reload the web server after renewal?** Use a deploy hook, which runs only after a successful renewal: certbot renew --deploy-hook "systemctl reload nginx". Other clients have an equivalent setting. **What should I monitor?** The certificate each hostname actually serves and how many days it has left, checked from outside the server. Alert when a certificate passes the point where it should already have been renewed. **What is ACME ARI?** ACME Renewal Information, defined in RFC 9773. It lets a certificate authority tell clients when to renew each certificate, including asking for early renewal before a mass revocation. --- https://bridge-ssl.com/acme/lets-encrypt/ --- # Let's Encrypt: what your client runs and what the authority checks Let's Encrypt is a certificate authority that issues [ACME certs](/acme/): software on your side asks for a certificate, proves control of each name and receives the certificate, without a person in the loop [2]. Its SSL/TLS certificates are free, with no fee charged, and it is a project of the nonprofit Internet Security Research Group (ISRG) [1][3]. This page covers how Let's Encrypt runs the protocol: the endpoint your client talks to, how each challenge is checked from the authority's side, and what your network has to let through. - **Operator** — Internet Security Research Group (ISRG), a nonprofit [1] - **Fee** — none for the certificate [3] - **Validation** — domain validation only; no organisation or extended validation [3] - **Protocol** — ACME, [RFC 8555](https://www.rfc-editor.org/rfc/rfc8555); production directory `https://acme-v02.api.letsencrypt.org/directory` [4][8] - **Challenges** — HTTP-01, DNS-01, TLS-ALPN-01 [5] - **Private key** — generated and kept on your side, never on Let's Encrypt's servers [3] ## Two routes to a Let's Encrypt certificate There are two routes: a hosting provider runs an ACME client for you, or you run one yourself [4]. Nothing is issued on the Let's Encrypt website itself; every certificate comes through its ACME API, so the question is who operates the client [4]. - **Your hosting provider or platform runs it.** The provider gets the SSL certificate from Let's Encrypt and renews it for you, either automatically or once you switch on a setting [4]. Let's Encrypt treats whoever holds the private key as the Subscriber, and for a hosting provider that is the provider, not its customer [6]. - **You run it on your own server.** This needs the right to run commands with sufficient privileges [4]. For most people Let's Encrypt recommends Certbot [4]; how to generate a Let's Encrypt certificate with Certbot, command by command, is a walkthrough of its own. Other clients exist for setups Certbot does not fit, so [choose an ACME client by class, not by name](/acme/clients/) before you pick one. The route decides what you maintain. With a provider, the client, the key and the renewal schedule are its problem. On your own server, all three are yours, together with the firewall rules below. ## What your client does, in order A client runs the RFC 8555 sequence against Let's Encrypt in this order. 1. **Reads the directory.** The client is configured with the production URL `https://acme-v02.api.letsencrypt.org/directory` [4], and the directory gives the URL for each ACME operation (RFC 8555 §7.1.1) [9]. 2. **Creates an account key pair.** Let's Encrypt identifies the client by this public key [2]. It is a different key from the one in the certificate, and an account key cannot be reused as a certificate key [6]. 3. **Orders a certificate and receives challenges.** For each name the authority returns one or more sets of challenges, and the client completes one set [2]. 4. **Sends a certificate signing request.** Once authorised, the client submits a PKCS#10 CSR carrying the public key to be certified, and signs the request with the account key [2]. 5. **Downloads the SSL certificate and its chain.** Intermediates are likely to change, so Let's Encrypt asks clients to build the chain from the `Link: rel="up"` header instead of hardcoding an intermediate [6][9]. ## How Let's Encrypt checks each challenge Each challenge is checked by Let's Encrypt's servers, from multiple network perspectives in parallel, which makes subverting validation much harder than fooling a single vantage point [2]. | Challenge | What the client publishes | Where Let's Encrypt looks | Wildcard | |---|---|---|---| | HTTP-01 | a file holding the token and a thumbprint of the account key | `http:///.well-known/acme-challenge/`, on port 80 only; redirects are followed only to ports 80 or 443 | no | | DNS-01 | a TXT record derived from the token and the account key | `_acme-challenge.`; CNAME or NS delegation to another zone is followed | yes | | TLS-ALPN-01 | a validation certificate, offered under the `acme-tls/1` protocol | a TLS connection on port 443 | no | When unsure, Let's Encrypt advises the client's defaults or HTTP-01 [5]. DNS-01 makes sense for automation only where the DNS provider has an API, and full DNS credentials on a web server raise the cost of a breach: narrowly scoped credentials, or validation from a separate server, are the pattern it recommends [5]. TLS-ALPN-01, standardised as [RFC 8737](https://www.rfc-editor.org/rfc/rfc8737), suits TLS-terminating reverse proxies more than ordinary sites [5][10]. A Let's Encrypt wildcard SSL certificate therefore always goes through DNS-01 [3][5]; setting one up, zone access included, is a topic of its own. ### Ports and firewall rules What has to be open depends on the challenge, and some of it applies to every challenge. - **Outbound 443** from the machine running the client, to reach the ACME API [6]. - **Inbound 80** for HTTP-01 [6]. Let's Encrypt recommends keeping plain HTTP open with a redirect to HTTPS rather than refusing port 80 [6]. - **Inbound 443** for TLS-ALPN-01, where the validation connection arrives [10]. - **Inbound 53, TCP and UDP,** to your authoritative DNS servers, for every challenge type [6]. Allow-listing the authority does not work. Let's Encrypt publishes neither the addresses of its ACME service nor the addresses it validates from, and both change without notice [3][6]. ## Test against staging before production Let's Encrypt asks for tests against its staging environment before production [7]. The staging directory is `https://acme-staging-v02.api.letsencrypt.org/directory` [8], and three things differ from production. - **A separate account.** ACME accounts are scoped to each environment, so staging needs its own; Certbot creates it for you [7]. - **Untrusted roots.** Staging certificates chain to roots that are not in browser or client trust stores and carry a "(STAGING)" prefix, so a browser warning on a staging certificate is the expected result [7]. - **A client switch.** In Certbot the switch is `--test-cert` or `--dry-run`; other clients document their own [7]. Do not add a staging root to a trust store you browse with. Let's Encrypt states those roots are not audited or held to the standards of its production roots [7]. ## What happens after issuance After issuance the certificate is public, and your client still owns revocation and renewal. - **The name becomes public.** Let's Encrypt submits each certificate to public Certificate Transparency logs [2]. Crawlers read those logs, find the name and visit it, so new traffic in your server logs right after issuance is expected [3]. - **Revocation is signed like issuance.** The client signs a revocation request with the account key authorised for the name, and Let's Encrypt publishes the revocation in a Certificate Revocation List [2]. - **Renewal should not run on the hour.** Let's Encrypt asks clients to renew at random times, not at midnight UTC or the first second of an hour; when the service is busy, clients are told to try again later [3]. A failed renewal is not fatal: retry with exponential backoff and report the error to an administrator [6]. Renewing a Let's Encrypt SSL certificate repeats the sequence: validation, then a new certificate [2]. Let's Encrypt may skip the validation, though, while an earlier authorization is still valid [3]. Let's Encrypt also suggests a renewal window for each certificate through ACME Renewal Information, defined in [RFC 9773](https://www.rfc-editor.org/rfc/rfc9773), and recommends that clients check it [6][11]. Keeping that loop alive is covered in [ACME certificate renewal automation that does not fail quietly](/acme/renewal-automation/). ## What Let's Encrypt does not issue It issues domain-validated certificates and nothing else [3]. - **No organisation or extended validation.** Let's Encrypt says it cannot automate those checks and has no plans to offer them [3]. - **No email or code signing certificates.** Those need a different type of certificate. The domain-validated certificate itself works for any server with a domain name: web, mail, FTP [3]. - **No direct support.** Help comes from the documentation and the community forums [3]. Where a requirement names organisation or extended validation, the answer is a different authority, not a different setting. ## FAQ ### Is Let's Encrypt free? Yes. Let's Encrypt charges no fee for its certificates; it is a nonprofit and relies on sponsors, grantmakers and individuals to fund the service [3]. ### Do browsers accept a Let's Encrypt certificate? For most browsers and operating systems, yes. Let's Encrypt publishes a compatibility list with the details [3]. ### Does Let's Encrypt keep my private key? No. The private key is generated and managed on your own servers, not by Let's Encrypt [3]. ### Can one Let's Encrypt certificate cover several names? Yes. A certificate can list several names through the Subject Alternative Name mechanism, and a wildcard name needs the DNS-01 challenge [3]. ### Which URL does my ACME client point to? The production directory, `https://acme-v02.api.letsencrypt.org/directory`. For tests, the staging directory is `https://acme-staging-v02.api.letsencrypt.org/directory` [4][8]. ## Sources 1. Let's Encrypt home page and About: a free, automated and open certificate authority; a project of the nonprofit ISRG. 2. Let's Encrypt, How It Works: account key, challenges, network perspectives, CSR, CT logs, CRL, renewal. 3. Let's Encrypt, FAQ: fee, funding, DV only, certificate types, support, private keys, SAN, wildcards, compatibility, CT traffic, validation addresses, renewal times, reuse of an earlier authorization. 4. [Let's Encrypt, Getting Started](https://letsencrypt.org/getting-started/): provider or own client, Certbot, production endpoint. 5. [Let's Encrypt, Challenge Types](https://letsencrypt.org/docs/challenge-types/): HTTP-01, DNS-01, TLS-ALPN-01. 6. [Let's Encrypt, Integration Guide](https://letsencrypt.org/docs/integration-guide/): Subscriber, keys, `Link: rel="up"`, firewall, ARI, retries. 7. Let's Encrypt, Staging Environment: accounts, staging roots, Certbot flags. 8. Let's Encrypt, ACME Protocol Updates: production and staging endpoints. 9. RFC 8555, Automatic Certificate Management Environment (ACME): §7.1.1, §7.4.2. 10. RFC 8737, ACME TLS-ALPN-01 challenge: port 443, `acme-tls/1`. 11. RFC 9773, ACME Renewal Information (ARI) Extension. --- https://bridge-ssl.com/certificates/chain/ --- # Certificate chain: intermediate certificates and the chain of trust [Your certificate is not trusted on its own](/certificates/). It is trusted because something your visitor's browser already trusts vouched for it, possibly through several steps. That sequence is the chain, and understanding it explains the single most common installation fault in this whole subject. ## The three kinds of certificate ```text root certificate in the browser's trust store, trusted outright │ signs intermediate certificate vouched for by the root │ signs leaf certificate yours, for your names ``` **The root** sits in a [trust store](/certificates/root-certificate/) shipped with the browser or the operating system. It is trusted because it is there, not because anything vouched for it, which makes the trust store the actual foundation of the whole system. **The intermediate** is signed by the root and signs certificates for customers. [A certificate authority](/certificates/certificate-authority/) works through intermediates rather than signing directly with its roots, so that a compromised signing key can be replaced without touching what is installed on every device in the world. **The leaf** is yours. It covers your names and is signed by an intermediate. A leaf from a [free certificate authority](/certificates/free-ssl/) is chained the same way as a paid one, which is why browsers trust it equally. The same holds for every [type of SSL certificate](/certificates/types/): a browser follows the chain of a DV, IV, OV or EV leaf up to a trusted root in the same way. ## What the client has to do A browser holds roots and receives your leaf. To connect them it needs every intermediate in between, and it expects the **server** to supply them. That expectation is the crux. Your server must present its own certificate plus the intermediates, as one bundle. If it presents only its own, the browser has a leaf it cannot connect to anything it trusts, and it refuses, reporting the error described on [ERR_CERT_AUTHORITY_INVALID](/errors/err-cert-authority-invalid/). The procedure a client follows to join those links, and the rule that every link must be signed by the next one up, are specified in [`RFC 5280`](https://www.rfc-editor.org/rfc/rfc5280). Configuring the server to serve the full bundle is an installation topic and is covered in the installation material on this site. ## Why a broken chain is the most common installation fault Because it is invisible to the person who caused it. Browsers cache intermediates they have seen. Once your browser has encountered a particular intermediate anywhere, it can complete chains that use it even when the server does not supply it. Some clients go further and fetch a missing intermediate from the address the certificate carries for that purpose, the `caIssuers` entry of the authority information access extension defined in `RFC 5280`. Either way, anyone who has been working with certificates has collected the common intermediates already, so a server with an incomplete chain works perfectly for them. Meanwhile a visitor arriving on a fresh device, or with a browser that does not do this, sees a trust error. The failure is selective, unpredictable, and impossible to reproduce on the machine where the work was done. Non-browser clients make it worse and clearer at once. Libraries used by scripts, mobile applications, and server-to-server calls generally do not collect intermediates and do not go looking for missing ones, so an incomplete chain that visitors barely notice breaks integrations outright. That contrast is a reliable diagnostic: works in a browser, fails from a script, suspect the chain first. ## Chain versus root store The **chain** is what the server sends: a path from your certificate up towards a root. It is data in transit, and you control it. The **root store** is the list of certificates a client trusts outright. It ships with browsers and operating systems, is maintained by their vendors, and you do not control it at all. The distinction matters in two practical ways. A chain can be complete and still fail, if it terminates at a root that a particular client does not have. And a root store differs between clients on the same machine: Firefox maintains its own, which is why some errors, such as SEC_ERROR_UNKNOWN_ISSUER, appear there and nowhere else. So the chain is your responsibility and the root store is your constraint. ## Should you send the root No, and it is a common minor mistake. The client already has the root, or it does not, and receiving a copy changes nothing either way: a root the client does not trust is not made trustworthy by being sent. Including it only adds bytes to every connection. Send your certificate and the intermediates. That is the complete answer. ## When the chain changes without you An intermediate is not permanent, and this catches people who assumed their bundle was set once. Authorities replace intermediates periodically, and they issue new certificates under whichever is current. So a renewal can arrive signed by a different intermediate than the previous one, and a bundle assembled by hand years ago no longer matches the certificate it accompanies. The symptom is a trust error appearing immediately after a routine renewal that otherwise went perfectly. Authorities also occasionally retire intermediates entirely, or a root approaches the end of its own validity and clients migrate to a successor. Those transitions are announced well ahead, and they affect anyone whose bundle is a file that nobody revisits. An intermediate past its end date fails validation the same way an [expired HTTPS certificate](/certificates/expired/) does, because every certificate below the root, yours included, must be within its validity period. Whatever installs the certificate should install the chain that came with it, in the same operation. A bundle maintained separately from the certificate is a pair of things that must be kept in step, and pairs like that drift. ## How to check your chain An external checker reports what the server actually presents, in order, and states whether the chain resolves to a trusted root. That is the verification worth doing after every certificate change, and the only one that reflects what a stranger's browser sees. The check to avoid relying on is your own browser. It will very likely succeed regardless, because it already holds the common intermediates, which makes it the least informative test available to you. For a certificate you hold as a file, a decoder shows its issuer, which tells you which intermediate you need if you are assembling the bundle by hand. One further check is worth running deliberately after any change: fetch the site with something that does not collect intermediates, such as a script rather than a browser. That reproduces what a stranger's fresh device sees, which is the audience the chain exists for in the first place. From a terminal, [OpenSSL lists the certificates](/certificates/openssl-commands/) the server sends, each with its issuer. If the list stops at your own certificate, the intermediates are missing. ```text $ openssl s_client -connect example.com:443 -servername example.com -showcerts **Certificates that renew themselves** — Bridge SSL is the certificate layer of Bridge CDN: issuance and renewal happen as part of serving your site, wildcards included when your DNS is on Bridge DNS. Nothing to install, nothing to schedule. [Get started](https://bridge-cdn.com/) [Fix an error first](/errors/) --- https://bridge-ssl.com/certificates/revocation/ --- # Certificate revocation: when it is required and how Revocation withdraws a certificate [before its expiry date arrives](/certificates/). The authority that issued it publishes the withdrawal, and clients that check learn not to trust it any more. The qualification in that sentence is the whole subject: checking is neither universal nor guaranteed. This page is for the operator deciding whether to revoke and how. If you are a visitor seeing a revoked-certificate error and want it to go away, that is a different situation: ERR_CERT_REVOKED is the site owner's to fix, with a new certificate. ## When revocation is required One case is not optional, and the rest are judgement. **Key compromise.** If the private key has been exposed, or you have reason to believe it may have been, the certificate must be revoked. Anyone holding that key can impersonate your site with a valid certificate, and the only thing that withdraws it is revocation. This obligation is part of the rules authorities operate under, and reporting suspected compromise is expected rather than discretionary. "May have been" covers more than people assume: a key committed to a repository, present in a backup that left your control, held on a server that was compromised, or handled by a contractor whose access ended badly. Certainty is not the threshold. **Improper issuance.** A certificate obtained by someone without authority, or issued with incorrect details, is revoked by the authority once established. **Decommissioning, sometimes.** A certificate for a service that no longer exists is worth revoking if the key's whereabouts are uncertain. If the key was destroyed with the system, letting it expire is reasonable. ## When it is not required Two situations prompt revocation requests that are not needed. **Replacing a certificate normally.** [Renewal issues a new certificate](/certificates/renewal/) and the old one expires on schedule. Revoking it adds nothing unless its key is in question, and it introduces a window where an old certificate still in service somewhere starts failing. **Changing hosting or providers.** The certificate remains valid and its key remains yours. Unless the key travelled somewhere you do not control, this is not a compromise. ## How to request it Through the authority that issued the certificate, using whatever channel it provides, and the request must be authenticated: an authority will not withdraw a certificate on an unverified request, since that would itself be an attack. Revoking a certificate and publishing its status is part of [what a certificate authority does](/certificates/certificate-authority/), alongside issuing it. Have three things ready. The certificate in question, so the authority can identify it precisely. The reason, since reasons are recorded and some are handled with more urgency. And the replacement plan, because revocation takes effect for clients that check and your site needs a valid certificate either way. Where issuance is automated, revocation usually is too, through the same interface that requested the certificate. Confirm that before you need it: discovering the route during an incident costs time you will not have. ## The order that avoids an outage Revocation and replacement are separate actions, and doing them in the wrong order takes the site down. Obtain and install the replacement first, together with its [certificate chain](/certificates/chain/), verify it is being served, and revoke afterwards. The old certificate remains valid during the overlap, which is harmless in the ordinary case. The exception is key compromise, where the overlap is what you are trying to end. There, revoke immediately and accept the disruption, because a valid certificate in an attacker's hands is worse than an interruption you control. Generate a **new key** and a new [certificate signing request](/certificates/csr/) for the replacement, since reissuing on the compromised key restores the exposure while removing the symptom. ## CRL and OCSP: how clients check revocation A client can learn that a certificate was revoked in two standard ways, and both addresses are written into the certificate itself. **Certificate revocation list (CRL).** The authority publishes a signed list of the serial numbers it has revoked, with the date and reason for each, and replaces it on a schedule. The certificate's CRL Distribution Points extension says where the list is. CRLs are defined in [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280). **Online Certificate Status Protocol (OCSP).** The client asks the authority's responder about one certificate and receives a signed answer: good, revoked or unknown. The responder's address is in the certificate's Authority Information Access extension. OCSP is defined in [RFC 6960](https://www.rfc-editor.org/rfc/rfc6960). The balance between the two has shifted. Since 2024 the CA/Browser Forum rules require publicly trusted authorities to publish CRLs and make OCSP optional, and Let's Encrypt ended its OCSP service in 2025. Browsers mostly do not fetch either for each site; they download revocation data compiled from CRLs by their vendor, such as Chrome's CRLSets and Firefox's CRLite. To see where a certificate publishes its status: ```text $ openssl x509 -in cert.pem -noout -ext crlDistributionPoints $ openssl x509 -in cert.pem -noout -ocsp_uri ``` A downloaded CRL is read with `openssl crl -in list.crl -inform DER -noout -text`. More commands are on [OpenSSL commands](/certificates/openssl-commands/). ## Why revocation works less well than it sounds The mechanism exists and its reliability is limited, which changes what you should expect from it. Clients learn about revocation by one of two routes. They ask the authority about a specific certificate at the moment they meet it, using the online certificate status protocol specified in [`RFC 6960`](https://www.rfc-editor.org/rfc/rfc6960), or they consult a certificate revocation list, the periodically published catalogue of withdrawn serial numbers defined in [`RFC 5280`](https://www.rfc-editor.org/rfc/rfc5280). Browsers have also supplemented both with lists compiled by their own vendors and shipped with the software. Consulting costs a round trip on every connection, so clients handle the trade differently, and some skip the check rather than delay the page when an answer is slow to arrive. The consequence is that a revoked certificate may keep working for a share of visitors. Revocation is a real measure and not a switch that takes effect everywhere at once. That limitation is also the reason certificate lifetimes have shortened over the years: bounded validity achieves by expiry what revocation is supposed to achieve by announcement, without requiring any client to check anything. There is one arrangement that removes the round trip rather than the check, in which the server obtains the signed status itself and hands it over during the handshake, a mechanism named `OCSP stapling`. ## What to do besides revoking Revocation addresses the certificate. A compromised key usually means something else went wrong, and treating the certificate as the whole incident leaves the cause in place. **Establish how the key was exposed.** A key in a repository points at a process problem; a key from a compromised server points at that server. The replacement certificate is safe only if the new key does not travel the same route. **Check what else used that key.** Keys are reused more often than people remember, across environments, across services, and sometimes across certificates. Every certificate on the exposed key needs the same treatment. **Look at what the certificate could have been used for.** Someone able to present a valid certificate for your name could intercept traffic to it during the exposure window. Whether that matters depends on what moved over those connections. **Write down the window.** When the key was exposed and when the replacement went live bounds every subsequent question, in the same way the window matters after a domain hijack. None of this is certificate work, which is precisely why it gets skipped: the visible task ends when the new certificate is serving. ## FAQ **When must a certificate be revoked?** When the private key is compromised, or when you cannot rule out that it was. That case is an obligation rather than a judgement call, because a certificate whose key is in someone else's hands lets them present themselves as you for the rest of its validity period. **Do I need to revoke when I replace a certificate?** No. Ordinary replacement leaves the previous certificate to expire on its own schedule, and nothing is gained by revoking it. Reserve revocation for the case it exists to handle, which is a key that may be held by someone other than you. **How do I revoke a certificate?** Through the authority that issued it, with a request it can authenticate as coming from you or from someone holding the key. Where issuance is automated, revocation generally is too, which matters because the moment you need it is rarely a calm one. **Should I revoke before or after installing the replacement?** After, whenever there is a choice, so the service is never without a working certificate. A compromised key removes that choice: revoke first and accept the interruption, because every minute the certificate remains valid is a minute someone else can use it. **Can I reuse the key for the replacement?** Not after a compromise. The key is the material that was exposed, and the certificate is only a statement about it, so issuing a new certificate against the same key leaves the attacker holding exactly what they held before. Generate a new pair. **Does revocation take effect immediately?** Not uniformly. Clients differ in how, and whether, they check revocation status, and some proceed when the check cannot be completed rather than refusing. A revoked certificate can therefore keep working for part of the audience, which is why replacing the key matters more than the revocation. **What is a certificate revocation list?** A CRL is a list, signed and published by a certificate authority, of the serial numbers of certificates it has revoked before their expiry. Each certificate names where its authority's list is published. --- https://bridge-ssl.com/certificates/san/ --- # SAN certificates: how one certificate covers many names Every [HTTPS certificate](/certificates/) in service today lists its names in a field called the subject alternative name, or SAN, and browsers read only that field. One certificate can therefore cover several unrelated hostnames, several domains, or a mixture of specific names and wildcards. The term "SAN certificate" usually means one covering multiple names, but the field itself is universal: even a certificate for a single name uses it. - **Defined in** — the subjectAltName extension, [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280) §4.2.1.6; one certificate may carry many names [1] - **Required in** — every publicly trusted server certificate: at least one dNSName or IP address entry, each validated by the authority (Baseline Requirements §7.1.2.7.12) [2] - **Common name** — not recommended; if present, it must repeat one entry of the SAN list (Baseline Requirements §7.1.4.3) [2] - **Browsers** — Chrome stopped matching the common name in Chrome 58 [3]; [RFC 9525](https://www.rfc-editor.org/rfc/rfc9525) says it must not identify a service [4] - **Names per certificate** — capped by the authority and its certificate profile, not by the standard; the figure is in the authority's own documentation [5] ## The field that replaced the common name Certificates once carried their primary hostname in a field called the common name, and that is where clients looked. That field was never designed to hold a hostname. It is a general-purpose label, and using it for names was a convention that outlived its usefulness once certificates needed to cover more than one. The subject alternative name field was introduced for this, and clients moved to reading it. [RFC 2818](https://www.rfc-editor.org/rfc/rfc2818), which defined HTTP over TLS, already called the common name deprecated and told clients to use the DNS names in the SAN whenever they are present [6]. The practical position today is unambiguous: browsers use the alternative name list and **ignore the common name entirely**. A hostname present only in the common name is not covered, no matter how correct the certificate looks in a viewer that displays that field prominently. This catches people inspecting an old certificate, or generating a signing request that fills the common name and omits the name list. The result is a certificate that appears to name your site and does not cover it, producing a name mismatch error, ERR_CERT_COMMON_NAME_INVALID in Chrome [7]. ## What a multi-name certificate can hold Several hostnames on one domain, several separate domains, and wildcard entries alongside specific names can all appear in the same certificate, which makes the list more flexible than most people use. Nothing requires the names to be related, and a client accepts the certificate when any one listed name matches the hostname it asked for [6]. Two constraints apply in practice. Each [SSL certification authority](/certificates/certificate-authority/) sets a maximum number of names per certificate, and all names in one certificate are validated together, so adding a name means demonstrating control of it before the certificate can be issued or reissued. That second point has an operational consequence: one certificate covering names across several teams or systems means every reissue requires all of them to be validatable at that moment. ### Name limits per authority The standard sets no number. Each certification authority sets its own maximum for the SAN list, sometimes a different one for each certificate profile it offers, and it can change that figure. Read the current limit in your authority's documentation before planning a long list; Let's Encrypt, for example, states it per profile [5]. The same documentation shows a second difference: some profiles issue certificates with no common name at all [5]. A script or monitor that still reads that field then finds an empty value. ## SAN versus wildcard A SAN certificate and a wildcard certificate both cover multiple names. They differ in what happens when the set changes, which is the criterion that decides most cases. | Criterion | Explicit name list | Wildcard | |---|---|---| | **New name appears** | reissue required | already covered | | **Names across several domains** | supported | not possible | | **Names at different depths** | supported | one level each | | **Key exposure** | one key for the listed names | one key for every name at that level | | **Visibility of names** | all listed names are public | individual names not disclosed | | **Revocation blast radius** | the listed names | everything at that level | Read the table as two questions rather than six. - **Does the set of names change without warning?** If yes, a wildcard removes issuance from the path of creating a subdomain, which is its whole value. If no, an explicit list costs nothing extra and keeps control finer. - **Do the names sit at different depths or on different domains?** If yes, a wildcard cannot do it and the list is the only option, possibly combined with wildcards as entries. Every name in an explicit list is published in the certificate and is therefore public, and certificates are widely logged and searchable. A wildcard discloses only that the level exists. Where internal-sounding hostnames should not be advertised, that difference is real, though weak on its own. What a wildcard costs in return is on [wildcard certificates](/certificates/wildcard/). ## Combining both One certificate can list `example.com`, `www.example.com`, and `*.example.com` together in its subject alternative name. The bare domain and the `www` form are covered explicitly, every one-level subdomain is covered by the wildcard, and deeper names are added as explicit entries when they appear. That combination handles the `www` and apex problem, the unpredictable subdomain problem, and the occasional deep name, in one certificate. It is the default worth asking for unless a reason exists to split. ## The reissue problem Adding a name means reissuing the whole certificate. That reissue is a new certificate covering the extended list, and it has to be installed everywhere the old one was, together with the intermediate [chain certificates](/certificates/chain/) issued with it. On one server that is a minor task; across several servers, a load balancer, and a set of application instances, it is a coordinated change for the sake of one new hostname. Two habits reduce the friction. - **Group names by how often they change rather than by who owns them.** A certificate covering stable public names and a separate arrangement for volatile ones means the frequent changes touch only the volatile certificate. - **Decide the boundary before it hurts.** A certificate accumulating names from several teams eventually requires all of those teams to be available whenever any of them needs a change, which is a coordination cost nobody chose deliberately. Neither habit is about certificates specifically. They are about not letting one artefact become a shared dependency for parties who have no reason to be coupled. ## What to put in the request The signing request declares the names, and the rule follows from everything above: put every name in the alternative name list, including the one you also place in the common name. Tools differ in whether they do this automatically. Where a request is generated by hand, the omission is silent and the consequence appears only after issuance. Details are on [certificate signing requests](/certificates/csr/). Check the request's name list before submitting: a name left out is found only after issuance, and correcting it means going through issuance again. Once the certificate arrives, two OpenSSL options answer the same question from the other side [8]. The first prints the SAN list; the second says whether one particular name is covered. ```shell openssl x509 -in cert.pem -noout -ext subjectAltName openssl x509 -in cert.pem -noout -checkhost www.example.com ``` On a live site the same list sits in the browser's certificate viewer; the steps are on [checking certificates in Chrome](/certificates/check/). ## FAQ ### What is a SAN SSL certificate? A certificate whose subject alternative name field lists more than one hostname, so a single certificate and key serve all of them. The term describes ordinary practice rather than a product tier: the field is where covered names live in every certificate issued today. ### Is the common name still used? Not for deciding what a certificate covers. Browsers read the alternative name list and disregard the common name entirely, which means a hostname present only in the common name is not covered at all, however correct the certificate looks when you inspect it. Some certificates no longer carry one. [5] ### Can one certificate cover different domains? Yes. Nothing requires the listed names to share a domain, so unrelated sites can be covered by one certificate, subject to whatever limit the authority places on the count. Whether that is wise is a separate question from whether it is possible. ### Should I use a SAN list or a wildcard? A list when the set of names is known and stable, or spans several domains and depths, since each name is then explicit and replaceable. A wildcard when subdomains appear without warning at one level, which is the situation a list cannot keep up with. ### Can I mix wildcards and specific names? Yes, and for most sites the mixture is the right answer: the bare domain and the `www` form listed explicitly, plus a wildcard covering the level below. That single certificate then handles both the names you know about and the ones nobody has created yet. ### Do the names in my certificate become public? Yes. Issued certificates are [published to public logs](/glossary/certificate-transparency/) that anyone can search, so every explicitly listed hostname becomes discoverable, including internal-sounding ones. A wildcard is the exception in this respect, since it reveals the level rather than the individual names. ## Sources 1. RFC 5280, Internet X.509 PKI Certificate and CRL Profile, §4.2.1.6 Subject Alternative Name. 2. [CA/Browser Forum Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/documents/), version 2.3.1, §7.1.2.7.12 and §7.1.4.3. 3. [Deprecations and Removals in Chrome 58](https://developer.chrome.com/blog/chrome-58-deprecations), Chrome for Developers: removal of commonName matching. 4. RFC 9525, Service Identity in TLS, §2; obsoletes [RFC 6125](https://www.rfc-editor.org/rfc/rfc6125). 5. [Let's Encrypt: Profiles](https://letsencrypt.org/docs/profiles/): names per certificate and common name, per profile. 6. RFC 2818, HTTP Over TLS, §3.1 Server Identity. 7. Chromium source, net/base/net_error_list.h: CERT_COMMON_NAME_INVALID, error -200. 8. OpenSSL 3.0 manual, openssl-x509: options -ext and -checkhost. **Continue in this section** - [What is an SSL certificate? Contents and lifecycle](/certificates/) — A certificate is a signed statement about who controls a name. What it contains, what an authority checks, and the four stages of its life. - [Wildcard SSL certificates cover one level only, and why](/certificates/wildcard/) — A wildcard SSL certificate covers one level of subdomains, not all of them. *.example.com matches shop.example.com and not eu.shop.example.com. - [DV, OV and EV certificates: what validation actually buys](/certificates/types/) — DV, OV and EV differ in what the authority checks, not in encryption. The four types of SSL certificate, and why browsers moved the EV badge. - [CSR explained: how to generate a signing request safely](/certificates/csr/) — A CSR holds your names and public key, signed by a private key that never leaves you. Generate one with OpenSSL, then decode it to check. --- https://bridge-ssl.com/certificates/types/ --- # DV, OV and EV certificates: what validation actually buys The types of SSL certificate differ in [what the authority checked before signing](/certificates/), and in what it may then write into the certificate. Encryption does not change with the type. The CA/Browser Forum's [Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/documents/) define four types and state that all of them give the same assurance about the domain name [1]. For a website, the question is whether anything outside the browser asks for a named organisation; browsers no longer show visitors the difference. - **Types** — Domain Validated (DV), Individual Validated (IV), Organization Validated (OV), Extended Validation (EV) [1] - **Type marker** — policy identifier 2.23.140.1.2.1 DV, 2.23.140.1.2.3 IV, 2.23.140.1.2.2 OV, 2.23.140.1.1 EV (§7.1.6.1) [1] - **Wildcard names** — in DV, IV and OV; in EV only for .onion names (EV Guidelines §7.1.2.1) [2] - **Address bar** — no EV badge since Chrome 77 and Firefox 70 [3][5] ## The four types of SSL certificate Every publicly trusted SSL certificate belongs to one of four types, and the type decides which subject fields the certificate may carry. | Type | What the authority verifies | What the subject field holds | Policy identifier | |---|---|---|---| | **Domain Validated (DV)** | control of each name (§3.2.2.4) | at most a country, and a common name copied from the certificate's names; no person or organisation | 2.23.140.1.2.1 | | **Individual Validated (IV)** | control of the names, plus a person's name and address (§3.2.3) | the person's given name and surname, country, and state or locality | 2.23.140.1.2.3 | | **Organization Validated (OV)** | control of the names, plus the organisation's identity and address (§3.2.2.1) | the organisation's name, country, and state or locality | 2.23.140.1.2.2 | | **Extended Validation (EV)** | the checks of the EV Guidelines, below | legal name, business category, jurisdiction, registration number, business address | 2.23.140.1.1 | Subject fields and identifiers of each type: §7.1.2.7.2 to §7.1.2.7.5 [1]; the EV subject: EV Guidelines §7.1.4.2 [2]. ### What each check involves - **Domain validation** asks one question: can the applicant show control of this name? Placing a file where the name serves it, or publishing a record in its DNS, answers it (§3.2.2.4). These are the checks behind automatically issued certificates. If a DV certificate carries a country, the authority verifies it from the IP address range, the ccTLD, the registrar's data or an organisation check (§3.2.2.3) [1]. - **Individual validation** is the fourth type of SSL certificate, for a person rather than an organisation. The authority checks the person's name against a government-issued photo ID, checks their address, and names that person in the certificate (§3.2.3, §7.1.2.7.3) [1]. - **Organisation validation** adds checks about the entity behind the request. The authority verifies its identity and address through a government agency, a reliable third-party database, a site visit or an attestation letter (§3.2.2.1) [1]. The organisation's name appears in the certificate. ### What the EV Guidelines add Extended validation is the one type with its own CA/Browser Forum document, the [EV Guidelines](https://cabforum.org/working-groups/server/extended-validation/documents/), version 2.0.4. Before issuing an EV SSL certificate, the authority verifies: 1. the applicant's legal existence and identity; 2. its physical existence, at a business address that is not a mail drop or P.O. box; 3. its operational existence, meaning business activity; 4. its control of each domain name, by a method of the Baseline Requirements; 5. a reliable means of communication with it; 6. the name, title and authority of the people who sign and approve the request. That is §3.2.2.1.1, with the address rule in §3.2.2.4.1. Four kinds of applicant qualify: private organisations, government entities, business entities and non-commercial entities (§4.1.1). The certificate then names the subject's full legal name, its business category, its jurisdiction of incorporation, its registration number and the address of its place of business (§7.1.4.2) [2]. ## What browsers show Browsers used to mark extended validation certificates in the address bar, with the organisation's name beside the URL. Chrome moved that badge into Page Info, the panel behind the icon left of the address, in Chrome 77; Chrome's note records that Safari had made a similar change with iOS 12 and macOS 10.14 [3]. Firefox moved it into the identity popup behind the lock icon in Firefox 70 [5]. Chrome's security team gave its reason: in its own research and in earlier academic work, users did not appear to make secure choices, such as not entering a password or card details, when the EV badge was changed or removed [3]. Chrome's team then announced, for Chrome 117, that the lock icon itself would give way to a neutral "tune" icon, because people read the lock as a sign that a site is trustworthy [4]. The address bar now looks the same for DV, OV and EV certificates. The organisation details remain inside the certificate, one click away in Page Info or the identity popup, and in the subject fields shown further down this page. ## Does validation level affect security? Not the security of the connection. The Baseline Requirements say so directly: the types vary in subject information, yet all of them "provide the same level of assurance of the device identity", meaning the domain name or IP address (§7.1.2.7.1) [1]. The same section gives all four types a common profile with three exceptions: the subject name fields, how those fields are validated, and the contents of the certificatePolicies extension. - **Connection security** is identical across all of them. A browser accepts a certificate of any type the same way, by following its [certificate chain](/certificates/chain/) up to a trusted root. - **Identity assurance** does differ. Organisation validation and extended validation put an organisation the authority verified into the certificate; domain validation puts none. Where that assurance matters, a process reads it rather than a visitor: a compliance framework, a customer's procurement process, an internal policy, a contract that names a validation level. Those are real reasons to pick a type, and none of them is about encryption. ## When each is worth it - **Domain validation** for public websites, APIs, services on public names and anything issued automatically. It is the default and the right default. - **Organisation validation** when something outside the browser requires it by name. Choosing it in the hope that visitors will notice is choosing it for a reason that stopped applying. - **Individual validation** on the same terms, when the requirement is a named person rather than a company. - **Extended validation** where a requirement names it specifically. Its extra checks are real; its extra visibility in the browser is gone. Bridge SSL, the certificate layer of Bridge CDN, issues domain-validated certificates. Organisation and extended validation are not part of it, and a certificate you already hold cannot be uploaded [8]. If a requirement names OV or EV, the SSL certificate comes from an authority that offers that type and goes on a server you manage; the steps for nginx, Apache and IIS are under [installing a certificate](/install/). ### Validation and coverage are separate choices Coverage is the second axis: how many names one certificate serves. A single name, an explicit list of names described on [SAN certificates](/certificates/san/), or one level of subdomains described on [wildcard certificates](/certificates/wildcard/). Every certificate has a position on both axes, so "a wildcard or an OV certificate?" is two questions with separate answers. The axes cross in one place. An EV certificate cannot hold a wildcard name unless it is a .onion name (EV Guidelines §7.1.2.1) [2]. DV, IV and OV share the Baseline Requirements profile, which allows a wildcard name once the authority has run its wildcard checks (§3.2.2.6, §7.1.2.7.12) [1]. A wildcard certificate that names an organisation cannot be EV. ## How to tell which type a certificate is Read its policy identifier. The Baseline Requirements make each certificate type carry its own identifier in the certificatePolicies extension, exactly one of them per certificate (§7.1.2.7.2 to §7.1.2.7.5, §7.1.2.7.9) [1]. [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280) defines that extension as a list of policy OIDs; in a server certificate they indicate the policy under which it was issued (§4.2.1.4) [6]. To read them from a live site's SSL certificate: ``` openssl s_client -connect example.com:443 -servername example.com /dev/null \ | openssl x509 -noout -subject -ext certificatePolicies ``` The output below comes from three lab certificates signed by our own test root, each with the subject fields and the policy identifier of one type, read with OpenSSL 3.0 [9]: ``` $ openssl x509 -in dv.pem -noout -subject -ext certificatePolicies subject= X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 $ openssl x509 -in ov.pem -noout -subject -ext certificatePolicies subject=C = GB, L = London, O = Example Ltd X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 $ openssl x509 -in ev.pem -noout -subject -ext certificatePolicies subject=businessCategory = Private Organization, jurisdictionC = GB, serialNumber = 00000000, C = GB, L = London, O = Example Ltd X509v3 Certificate Policies: Policy: 2.23.140.1.1 ``` ### Reading the output An empty `subject=` with 2.23.140.1.2.1 under Certificate Policies is a DV certificate: it names no person or organisation. With an empty subject the Subject Alternative Name extension must be marked critical (§7.1.2.7.12), and `openssl x509 -in dv.pem -noout -ext subjectAltName` on the lab certificate prints `X509v3 Subject Alternative Name: critical`. An `O =` entry names the organisation; `businessCategory`, `jurisdictionC` and `serialNumber` belong to the subject of an extended validation certificate. An authority may add identifiers of its own to its certificates, documented in its policy, next to the CA/Browser Forum one (§7.1.2.7.9) [1]. The CA/Browser Forum identifier is the one that names the type. ## Why the industry moved to domain validation The shift was not a lowering of standards. Organisation checks run on documents, registries and people who sign, and that kept them out of automated issuance. Let's Encrypt states that it offers only DV certificates, and not OV or EV, primarily because it cannot automate issuance for those types [7]. Once encryption became the baseline for every site, paperwork per certificate could not follow it to every personal site, internal tool and short-lived environment. Automated domain validation removed that constraint, and a [free certification authority](/certificates/free-ssl/) works on exactly that model. The trade was deliberate: less assurance about who is behind a site, in exchange for encryption on all of them. The assurance sat in a badge that, by Chrome's research, did not change what users did [3], and unencrypted connections were the more concrete harm. ## What none of them verify The levels invite an assumption they do not support. The EV Guidelines spell it out for the strictest type. An extended validation certificate is not intended to assure that the subject is actively doing business, complies with the law, is trustworthy, honest or reputable, or that it is safe to do business with (§1.4.2). Certificates of the other types check less and promise no more. An organisation can be thoroughly verified and still run something you would not want to use. Nor does any level protect against a certificate obtained by someone who took control of the domain improperly. Even under the EV Guidelines, the authority confirms control of each name at the time of issue (§3.2.2.7.1) [2], a statement about that moment and not a continuing guarantee. ## FAQ ### What is the difference between DV, OV and EV certificates? What the authority checked before signing, and what it may then write into the certificate. Domain validation confirms control of the name. Organisation validation adds a check that the organisation exists and matches the request. Extended validation applies the stricter checks of the EV Guidelines. The cryptography and the browser's treatment are the same for all three. ### What is an EV SSL certificate? An SSL certificate issued under the CA/Browser Forum's EV Guidelines. The authority verifies the organisation's legal, physical and operational existence and the people who approved the request, and the certificate carries the policy identifier 2.23.140.1.1. ### What is an OV certificate? An SSL certificate whose subject names an organisation the authority verified through a government agency, a reliable database, a site visit or an attestation letter. Its type shows in the policy identifier 2.23.140.1.2.2. ### Does validation level affect search rankings? Google's announcement of HTTPS as a ranking signal describes the signal as whether a site uses secure, encrypted connections. Its certificate advice is to decide between a single, multi-domain or wildcard certificate, and it names no validation level. ### Can a DV certificate be issued for a domain I do not control? Only to someone who does control it, which is what validation tests. That makes certificate security a consequence of naming security: if an attacker can change your DNS or reach your registrar account, they can pass validation legitimately, and the SSL certificate they receive is entirely valid. ## Sources 1. CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1: §3.2.2.1, §3.2.2.3, §3.2.2.4, §3.2.2.6, §3.2.3, §7.1.2.7.1 to §7.1.2.7.5, §7.1.2.7.9, §7.1.2.7.12, §7.1.6.1. 2. CA/Browser Forum, Guidelines for the Issuance and Management of Extended Validation Certificates, version 2.0.4: §1.4.2, §3.2.2.1.1, §3.2.2.4.1, §3.2.2.7.1, §4.1.1, §7.1.2.1, §7.1.4.2. 3. Chromium, EV UI Moving to Page Info (docs/security/ev-to-page-info.md). 4. Chromium Blog, An Update on the Lock Icon. 5. Mozilla, Firefox 70.0 release notes: Improved privacy and security indicators. 6. IETF, RFC 5280, X.509 certificate and CRL profile: §4.2.1.4. 7. Let's Encrypt, FAQ: What services does Let's Encrypt offer? 8. Bridge SSL, home page (What it costs; What this deliberately does not do) and llms.txt (What is not included). 9. Our runs: OpenSSL 3.0.13 on Linux, three lab certificates issued by a local test root. 10. Google Search Central Blog, HTTPS as a ranking signal. ## Continue in this section - [What is an SSL certificate? Contents and lifecycle](/certificates/) — A certificate is a signed statement about who controls a name. What it contains, what an authority checks, and the four stages of its life. - [Wildcard SSL certificates cover one level only, and why](/certificates/wildcard/) — A wildcard SSL certificate covers one level of subdomains, not all of them. *.example.com matches shop.example.com and not eu.shop.example.com. - [SAN certificates: how one certificate covers many names](/certificates/san/) — Every modern certificate uses the SAN field, and the old common name is ignored. A list of names suits a stable set; a wildcard suits names that change. - [CSR explained: how to generate a signing request safely](/certificates/csr/) — A CSR holds your names and public key, signed by a private key that never leaves you. Generate one with OpenSSL, then decode it to check. > **Certificates that renew themselves** — Bridge SSL is the certificate layer of Bridge CDN: issuance and renewal happen as part of serving your site, wildcards included when your DNS is on Bridge DNS. Nothing to install, nothing to schedule. [Get started](https://bridge-cdn.com/) [Fix an error first](/errors/) --- https://bridge-ssl.com/certificates/wildcard/ --- # Wildcard SSL certificates cover one level only, and why A wildcard [SSL certificate](/certificates/) for `*.example.com` covers `shop.example.com` and `api.example.com`. It does not cover `eu.shop.example.com`, which sits one level deeper, and it does not cover `example.com` itself unless that name is listed separately in the same certificate. The belief that a wildcard covers everything below a domain is the most common misunderstanding in this subject, and it produces a specific, avoidable outage. The reason it is wrong is mechanical rather than a matter of policy. ## The mechanism behind the limit Name matching compares labels, not strings. A hostname is a sequence of labels separated by dots. The wildcard character stands for exactly one label in exactly one position, the leftmost, and matching proceeds label by label. ```text certificate: * . example. com │ candidate: shop. example. com ✅ one label in the wildcard position candidate: eu.shop. example. com ❌ two labels where one is allowed candidate: example. com ❌ nothing in the wildcard position ``` So `*.example.com` matches names with exactly one additional label. A name with two extra labels has no way to be matched by a single wildcard, and a name with none does not either, because the wildcard position must be filled by something. That is the whole rule. It is defined in the specification governing how clients verify names in certificates, and every browser implements it the same way, which is why there is no client-side setting or server configuration that changes the outcome. ## What this means in practice The one-level rule has three practical consequences. **The bare domain needs listing separately.** A certificate for `*.example.com` does not secure `example.com`. A [certificate authority](/certificates/certificate-authority/) routinely includes both when asked, and if it was not asked for, the shorter name fails while every subdomain works. Both names belong in the list when you [generate the CSR](/certificates/csr/), since adding one after issuance means a new certificate. **Deeper names need their own coverage.** If you use two-level subdomains, each level needs a wildcard of its own, or the names need listing explicitly. A wildcard at the level that needs it, such as `*.shop.example.com`, covers that level and no further. **Multiple wildcards do not nest.** Holding `*.example.com` does not extend to anything below the names it matches. Coverage is per level, always. The symptom of getting this wrong is a name mismatch error (ERR_CERT_COMMON_NAME_INVALID in Chrome) appearing on precisely the names you assumed were covered. ## SSL for a subdomain A subdomain needs a certificate covering that exact name, and there are three ways to get one. Issue a certificate for the single name, which is the simplest option for one or two subdomains. Include the name in a certificate covering several names explicitly, described on [SAN certificates](/certificates/san/). Or use a wildcard, which covers every name at that one level without listing them. Which is right depends on how many names there are and how often the set changes, discussed below. Nothing about a subdomain requires special treatment beyond making sure the name is covered. ## Issuing a wildcard One practical constraint distinguishes wildcards from ordinary certificates: proving control of a wildcard requires the DNS-based validation method (the ACME DNS-01 challenge, when issuance is automated) rather than the file-based one (HTTP-01). You cannot place a verification file at every possible name a wildcard would cover, because the set is unbounded. Publishing a DNS record for the domain demonstrates control of the whole level at once, which is what the wildcard claims. The practical implication is that automated issuance of wildcards requires your DNS to be updatable by the issuing process, which is a different integration from ordinary automated issuance. Once issued, a wildcard is installed like any other certificate, intermediates included: a server that omits them breaks the [HTTPS certificate chain](/certificates/chain/) for fresh visitors. ## Wildcard versus listing names The comparison that decides the choice, and it is about change rather than count. **A wildcard suits** an environment where subdomains are created regularly and unpredictably: per-customer names, per-environment names, anything generated. Coverage exists before the name does, which removes issuance from the path of creating a subdomain. **An explicit list suits** a stable set of names, particularly when they span different levels or different domains, which a wildcard cannot do at all. It also limits exposure, discussed next. **The cost of a wildcard** is concentration. One private key covers every name at that level, so a compromise of that key affects all of them, and replacing it means replacing coverage for everything at once. A list of names issued separately can be replaced piecemeal. For most organisations the convenience wins, because subdomain proliferation is a real operational problem while key compromise is a rare one. ## Where the myth comes from The belief is reasonable rather than careless. The wildcard character means "anything" in most contexts a technical person meets: file matching, search patterns, and configuration syntax generally treat it as matching any amount of anything. Certificates are the unusual case, where it matches exactly one component of a structured name. The DNS side reinforces the confusion, because a wildcard record behaves differently from a wildcard certificate, and the two are frequently configured in the same afternoon. Their rules are not the same, and assuming that what holds for one holds for the other is where most of this starts. The record side belongs to the DNS layer. And the failure is quiet at first. A wildcard does cover the names people test with, so the setup appears correct until someone reaches a deeper name, which may be weeks later and in a part of the system nobody associated with certificates. The defence is a habit rather than knowledge: list the names that actually resolve, and check each one against what the certificate covers. Reasoning about what the wildcard ought to include is where the mistake lives; the list does not have opinions. ## FAQ **Does a wildcard certificate cover all subdomains?** No, and this is the assumption that causes most wildcard failures. It covers exactly one level of naming. `*.example.com` matches `shop.example.com` and does not match `eu.shop.example.com`, because the second has one more label than the wildcard replaces. **Does `*.example.com` cover `example.com`?** No. The wildcard stands in for a label that must be present, and the bare domain has no label there to match. It has to be listed as a name of its own, which authorities include on request, and forgetting it is a common way to break the main address. **How do I cover two-level subdomains?** Either with a wildcard placed at that level, such as `*.shop.example.com`, or by listing the names explicitly. Wildcards do not nest and cannot be combined to reach deeper, so covering several depths means several wildcards in the same certificate. **Why can't I use file-based validation for a wildcard?** Because the set of names a wildcard covers is unbounded, and placing a file on one host proves control of that host alone. Validation through DNS proves control of the zone the whole level lives in, which is the claim the certificate actually makes. **Is a wildcard less secure than separate certificates?** A wildcard concentrates risk rather than weakening anything. One key stands behind every name at that level, so a key taken from the least protected host is usable for the most important one. Whether that matters depends on how much those hosts differ in exposure. **When should I use a list of names instead?** When the set of names is stable, when it spans several levels or domains that one wildcard cannot reach, or when you want each name replaceable on its own. An explicit list lets you withdraw or reissue coverage for a single host without disturbing anything else. --- https://bridge-ssl.com/certificates/formats/ --- # Certificate formats: PEM, DER, PFX and when to convert Certificate formats such as PEM, DER and PFX are different ways of storing the same [certificate](/certificates/) on disk. The certificate itself is a fixed structure, identical whatever file it arrives in; what varies is how it is encoded and what else is bundled with it, and those two variations account for every format name you will meet. Understanding them as encoding plus contents, rather than as unrelated file types, makes conversion obvious instead of arbitrary. ## Two questions, not a list **How is it encoded?** Either as raw binary, or as that same binary encoded into text with header and footer lines around it. The text form exists so that certificates can be pasted into configuration files, emails and control panels. **What is in the file?** Just a certificate, a certificate with its chain, a certificate with its private key, or a request or key alone. Every format is a combination of those answers. The confusion comes from tools naming the combination rather than the parts. ## The formats you will meet | Name | Encoding | Typically contains | |---|---|---| | PEM | text | certificate, chain, key or request — one or several | | DER | binary | a single certificate or key | | PKCS#12 (PFX, P12) | binary | certificate, chain and key together, password-protected | | PKCS#7 (P7B) | text or binary | certificates and chain, never a private key | PEM is the common currency. It is text, it is what most Unix-derived software expects, and several items can sit in one file one after another, which is how a certificate and its chain are usually supplied. Its text encoding is described in [RFC 7468](https://www.rfc-editor.org/rfc/rfc7468). DER is the same content without the text wrapper; some platforms and devices expect it. PKCS#12 bundles everything needed to serve a site, including the private key, into one password-protected file, which is what platforms with a single import field usually want. PKCS#7 carries certificates without any key, so it is used for delivering a chain. File extensions are not reliable. A file ending in `.cer` or `.crt` may hold either PEM or DER, because extensions are conventions and tools disagree about them. ## Telling them apart Open the file in a text editor. That single step answers most questions. Readable lines beginning with dashes mean the text form, and the label says what follows: `-----BEGIN CERTIFICATE-----` for a certificate, `-----BEGIN PRIVATE KEY-----` for a key, `-----BEGIN CERTIFICATE REQUEST-----` for a signing request. Binary noise means one of the binary forms. Counting the labelled blocks tells you how many items are in the file, which is how you check whether a chain is included without decoding anything. To read what a certificate says, decode it: ```text $ openssl x509 -in cert.pem -noout -text $ openssl x509 -in cert.der -inform der -noout -text ``` ## What conversion actually does Conversion re-encodes, and nothing else. The certificate inside is unchanged: the same names, the same dates, the same signature. Converting cannot fix an expired certificate, cannot add a name, and cannot repair a mismatched key. That matters because conversion is often attempted as a remedy. If a certificate is rejected for its contents, no format change will help; if it is rejected because the software cannot read the file, conversion is exactly the answer. The one thing conversion can change is what is bundled: extracting a certificate from a combined file, or assembling a certificate and key into one, alters the contents even though each item stays the same. ## Converting with OpenSSL The common conversions are one command each: ```text $ openssl x509 -in cert.pem -outform der -out cert.der $ openssl x509 -in cert.der -inform der -out cert.pem $ openssl pkcs12 -in bundle.pfx -out bundle.pem -noenc $ openssl pkcs12 -export -in cert.pem -inkey key.pem -certfile chain.pem -out bundle.pfx $ openssl pkcs7 -print_certs -in chain.p7b -out chain.pem ``` In order: PEM to DER, DER to PEM, PFX to PEM, PEM to PFX with the chain, and P7B to PEM. Two of them deserve a warning. Extracting a PFX with `-noenc` writes the private key to disk unencrypted, so the output needs the same protection as the key itself. And a `.cer` file has to be checked first: if it is already PEM, there is nothing to convert. ## Mistakes that produce broken installations Four mistakes account for most format-related incidents. **Assembling a bundle in the wrong order.** Where a file holds a certificate and its chain, your certificate goes first, then each intermediate towards the root. Software that reads such a file positionally presents the wrong certificate if the order is reversed, which produces a trust error described on [ERR_CERT_AUTHORITY_INVALID](/errors/err-cert-authority-invalid/). **Including the root.** Unnecessary in every case, as covered on [certificate chains](/certificates/chain/). Some software objects to it, so leaving it out avoids a class of confusion. **Pasting with damage.** Copying text through an editor that reflows lines, or through a chat client, can break the encoding invisibly. If a file that looks correct is rejected as unreadable, this is the likely cause, and the answer is to transfer it as a file rather than as text. **Converting a bundle and losing the chain.** Extracting a single certificate from a combined file drops the intermediates. The result works in a browser that has them cached and fails elsewhere. ## Why so many formats exist The binary encoding came first, as part of a general standard for structured data that predates the web. The text form was added because binary files are awkward in the places certificates actually travel: configuration files, emails, support tickets and web forms. Text survives being pasted; binary does not. The bundle formats solve a different problem. A working installation needs a certificate, its chain and a private key, and moving three files in step is error-prone. A single password-protected container solves that, at the cost of being opaque without tooling. Nothing about a format is a quality judgement. A file is not better for being one form or another; it is readable by the software you are handing it to, or not. ## Which format do you need The software that reads the file decides. Most Unix-derived server software expects PEM, with the certificate and chain in one file and the key in another. Platforms offering a single import field usually expect PKCS#12. Devices and appliances vary, and their documentation is the authority. Where [a certification authority](/certificates/certificate-authority/) or provider gives you several files without explaining them, opening each in a text editor and reading the labels tells you what you have in under a minute. ## FAQ **What is a PEM file?** A PEM file is a certificate, key or request stored as text, with a header line such as -----BEGIN CERTIFICATE----- and a matching footer. It is the format most web servers expect, and one file can hold several items, such as a certificate followed by its chain. **What is the difference between PEM and DER?** Encoding, and nothing else. PEM is the text form with labelled header and footer lines; DER is the same certificate as raw binary. Converting between them changes how the bytes are written, never what the certificate says. **What is a PFX file?** A PFX (PKCS#12) file is a password-protected bundle that holds the certificate, its chain and the private key together. Because the key travels inside, it deserves the same handling as the key itself: not something to email or leave in shared storage. **How do I open a PEM file?** In any text editor, to see which blocks it contains. To read the certificate's names and dates, decode it with openssl x509 -in file.pem -noout -text. **How do I convert a CER file to PEM?** Open it in a text editor first. If it begins with -----BEGIN CERTIFICATE----- it is already PEM and only needs renaming. If it is binary, it is DER: convert it with openssl x509 -in file.cer -inform der -out file.pem. **Does converting a certificate change it?** No. Conversion re-encodes identical content, so the names, the validity period and the signature survive untouched. An expired certificate stays expired and a key that does not match still does not match. **Should the root certificate be in the bundle?** No. The client either trusts that root already or it does not, and a copy from your server changes neither case. Some software treats the extra certificate as a configuration error rather than ignoring it. --- https://bridge-ssl.com/certificates/self-signed/ --- # Self-signed certificates: what they are and how to create one A self-signed certificate is a [certificate](/certificates/) signed by its own key instead of by a certificate authority. The encryption it provides is the same as any other certificate's; what it lacks is anyone independent confirming that the holder is who it claims to be. That is why browsers refuse it on public sites, and why it is still the right tool for development and internal systems. ## What makes a certificate self-signed Certificates normally work through delegation of trust. An authority your browser already trusts signs a certificate, and by doing so states that it verified control of the name; see [certificate authorities](/certificates/certificate-authority/). A self-signed certificate skips that step. Its issuer and subject are the same, and the signature is made with its own private key. It is technically valid and cryptographically sound, and means nothing to anyone who does not already know the site: an assertion without a witness. That is also why browsers refuse rather than warn. An attacker impersonating a site can produce a self-signed certificate just as easily as the real site can, so accepting them would remove the point of certificate verification while leaving the padlock in place. ## How to create a self-signed certificate With OpenSSL, one command creates the private key and the certificate together: ```text $ openssl req -x509 -newkey rsa:2048 -noenc -keyout key.pem -out cert.pem \ -days 365 -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost" ``` The subjectAltName extension is not optional in practice: browsers read names only from it, so a certificate with a common name and no subjectAltName is rejected for a name mismatch even when trusted. List every name the server will answer for. The -noenc option leaves the key unencrypted, which suits a development server and nothing else. To [check the new certificate with OpenSSL](/certificates/openssl-commands/): ```text $ openssl x509 -in cert.pem -noout -subject -issuer -dates -ext subjectAltName ``` Subject and issuer are identical, which is what self-signed means. ## When self-signed is the right choice **Local development and testing.** A laptop, a build server or a staging system reachable only by the people who set it up. Nobody is asked to trust an unfamiliar site. **Internal services between known machines.** Where both ends are configured by the same team and can pin or explicitly trust the certificate. **Device management interfaces.** Network equipment and appliances commonly ship with one. Where the device lets you install your own certificate, do; where it does not, restrict who can reach the interface. The common feature is that the people connecting can verify what they are connecting to by other means. Where that is not true, a self-signed certificate is the wrong tool, however small the audience seems. ## When it is not Any site a stranger might visit: public websites, customer-facing applications, anything reachable from the internet by someone who cannot verify it independently. The historical reasons for self-signing a public site, cost and effort, are gone: certificates from trusted authorities are free and can be issued and renewed automatically through [ACME](/acme/). The two ways to obtain one are covered in [how to get a free SSL certificate](/certificates/free-ssl/). Buying from a paid authority is the third route; all three are compared in [how to make an SSL certificate browsers accept](/certificates/how-to-get/). A self-signed certificate installed "for now" during a launch is one of the more durable temporary measures in infrastructure, and it teaches every visitor that security warnings on your site are normal. ## What the browser shows Chrome and Edge report `NET::ERR_CERT_AUTHORITY_INVALID`; Firefox reports `SEC_ERROR_UNKNOWN_ISSUER` or, more specifically, `MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT`. The Firefox code is useful when diagnosing: it says the certificate is self-signed, rather than issued by an authority the browser does not know, which usually means an incomplete chain and a different fix. That case is covered on [ERR_CERT_AUTHORITY_INVALID](/errors/err-cert-authority-invalid/). Command-line tools fail the same way, with messages such as self signed certificate or self-signed certificate in certificate chain. ## Trusting it on your own machine, or running your own authority For one developer, adding the certificate to the operating system's trust store, and to Firefox, which keeps its own, removes the warning on that machine only. For a team, a private certificate authority scales better. You create one root, install it on the devices you manage, and issue certificates from it; every service then works without warnings on those devices and on nothing else, which is exactly the intent. Tools such as [mkcert](https://github.com/FiloSottile/mkcert) automate this for local development. Clicking through the warning is the option to avoid. On a network you control it is almost certainly the intended server; on a shared network it is precisely the situation where it might not be, and the warning page cannot tell the two apart. Every internal system that shows the warning trains its users to dismiss it, and the habit does not stay inside the office. ## FAQ **What is a self-signed certificate?** A self-signed certificate is signed with its own private key instead of by a certificate authority. Anyone can create one in seconds; the encryption is ordinary, but nobody independent has confirmed who holds it. **How do I create a self-signed certificate?** With OpenSSL: openssl req -x509 -newkey rsa:2048 -noenc -keyout key.pem -out cert.pem -days 365 -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost". Include every hostname in subjectAltName, because browsers ignore the common name. **Is a self-signed certificate secure?** The encryption is no weaker than with any other certificate. What is missing is verification: a visitor cannot tell the real site from an impersonator presenting its own self-signed certificate, which is what the browser refuses. **When should I use a self-signed certificate?** For local development, testing and internal services where the people or machines connecting already know what they are connecting to. Never for a public site. **How do I get rid of the self-signed certificate warning?** On a public site, replace it with a certificate from a trusted authority and automate renewal. On your own machine, add the certificate to the trust store. For a team, issue certificates from a private authority installed on managed devices. **Why does Firefox still warn after I trusted the certificate in my operating system?** Firefox keeps its own trust store by default. Import the certificate or your private authority in Firefox's certificate settings as well. --- https://bridge-ssl.com/certificates/certificate-authority/ --- # What is a certificate authority? What CAs do and why browsers trust them A certificate authority (CA, also certification authority) is an organisation that verifies who controls a name and then signs an [HTTPS certificate](/certificates/) saying so. Browsers accept a site's certificate because they trust the authority that signed it, which makes CAs the part of the system that turns an encryption key into a verified identity. Anyone can sign a certificate. A trusted certificate authority is one that follows public rules, passes independent audits and has its root in browsers' root stores. - **Checks before signing** — control of every name in the request (Baseline Requirements §3.2.2.4) and the domain's CAA records [1][2] - **Never does** — generate a subscriber's key pair for a TLS server certificate (§6.1.1.3) [1] - **Rules and audits** — CA/Browser Forum Baseline Requirements, version 2.3.1; WebTrust or ETSI EN 319 411-1 audits, each covering at most one year (§8.1, §8.4) [1] - **Trusted because** — its root is in the root store of browsers and operating systems, under Mozilla Root Store Policy 3.1, Chrome Root Program Policy 1.8, Apple Root Program Policy 2.0 [3][4][5] ## What a certificate authority does - **It checks the request.** Before signing, the authority verifies that the requester controls the name, and for some certificate types that the organisation exists. How much it checks is what separates DV, OV and EV; see [certificate types](/certificates/types/). - **It signs the certificate.** The signature binds the name to the requester's public key. Anyone holding the authority's public key can confirm the certificate came from it and was not altered. - **It publishes certificate status.** If a certificate must stop being trusted before it expires, the authority revokes it and publishes that through revocation lists or OCSP; see [certificate revocation](/certificates/revocation/). - **It logs what it issues.** Publicly trusted certificates are recorded in public logs, which is how unexpected issuance for a domain becomes visible; see [certificate transparency](/glossary/certificate-transparency/). Chrome refuses a certificate that does not come with proof of logging under its CT policy [6]. An authority does not generate or hold your private key. The key is created on your side, and only the public half goes into the request. For TLS server certificates the Baseline Requirements turn this into a rule: the CA shall not generate the key pair for a subscriber, and shall not accept a request that uses a key it generated earlier [1]. ## What a certificate authority checks before it signs Every publicly trusted certificate goes through domain validation. The Baseline Requirements list the permitted methods in §3.2.2.4, and the certificate authority picks one of them for each name [1]. Among them are: - a DNS change (§3.2.2.4.7); - an agreed-upon change to the website through ACME (§3.2.2.4.19); - a TLS response using ALPN (§3.2.2.4.20). Root programmes can add conditions: the Apple Root Program Policy requires a CA to support at least one of the methods it lists [5]. Two further checks guard against a forged answer. The CA repeats the domain and CAA checks from several network perspectives, which helps protect against a BGP hijack of a single route (§3.2.2.9) [1]. It also reads the domain's CAA records ([RFC 8659](https://www.rfc-editor.org/rfc/rfc8659)): if they exist and do not authorise it, it must not issue (§4.2.2.1) [1][2]. A certificate authority can reuse a completed check for a limited time only. For certificates issued since 15 March 2026 a domain validation may be up to 200 days old; the limit falls to 100 days from 15 March 2027 and to 10 days from 15 March 2029 (§4.2.1) [1]. ### Wildcards and several names The method matters for wildcards. A certificate authority can validate a name like `*.example.com` only by a domain validation method the requirements mark for wildcard names, such as the DNS change; the ACME website method and TLS with ALPN are not among them [1]. Every name is validated separately, so a certificate for multiple domains needs proof of control for each one before it is issued. ## Root and intermediate authorities Authorities are layered. [A root authority's certificate](/certificates/root-certificate/) sits in the trust stores shipped with browsers and operating systems. The root signs intermediates, and the intermediates sign the certificates sites use: the Baseline Requirements forbid signing with a root key except for the root itself, subordinate CAs, OCSP response verification and internal infrastructure [1]. Root CA systems must sit on networks physically separate from the rest of the CA's infrastructure [7]. If an intermediate key is compromised, it can be replaced without touching the root on every device in the world. An authority that signs from an intermediate is an intermediate certificate authority, and a browser trusts it only through the root above it. That layering is why a server has to send the intermediate along with its own certificate. A browser holds the roots, receives the site's certificate, and needs the intermediates to connect the two; see [certificate chains](/certificates/chain/). ## Why browsers trust some authorities and not others Trust is a list. Each browser and operating system ships a root store, and an authority is trusted exactly when its root is in it. Root programmes decide who gets in, and the [CA/Browser Forum](https://cabforum.org/) sets the baseline requirements publicly trusted authorities must follow: how they validate requests, how long certificates may live, and how they must be audited. Each programme adds its own policy on top: the [Mozilla Root Store Policy](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) (version 3.1), the [Chrome Root Program Policy](https://googlechrome.github.io/chromerootprogram/crp/policy/) (version 1.8) and the Apple Root Program Policy (version 2.0) [3][4][5]. All three require the Baseline Requirements and audits by independent auditors; Mozilla and Apple ask for a new audit at least once a year [3][5]. An authority that breaks those rules can be removed. Mozilla's policy says it may disable or remove a certificate at any time and for any reason, and Chrome's says it includes or removes certificates at its sole discretion [3][4]. When a root is removed, certificates that chain to it stop being accepted, and every site holding one has to replace it on the browsers' timeline rather than its own. ## Public and private certificate authorities Public authorities are the ones in browser root stores, and their certificates are accepted anywhere. They are the only option for a public website. A private authority is one an organisation runs itself, for internal services, devices and client certificates. Its certificates are trusted only by machines where its root has been installed, which is exactly what makes it suitable for internal use and unsuitable for anything public. A [self-signed certificate](/certificates/self-signed/) is the smallest case of the same idea: an issuer nobody else has agreed to trust. | | Public certificate authority | Private certificate authority | |---|---|---| | **Trusted by** | browsers and operating systems out of the box | only devices where its root was installed | | **Rules** | Baseline Requirements and root programme policies | its owner's own policy | | **Audits** | required by the root programmes | not required by browsers | | **Domain validation** | required for every name | up to the owner | | **Fits** | public websites | internal services, devices, client certificates | Running a private authority also means taking on certificate lifecycle management: issuing, renewing and revoking, and getting the root onto every device that has to trust it. ## Free and paid authorities The encryption does not depend on who signed the certificate or what it cost. [Free authorities](/certificates/free-ssl/) issue domain-validated certificates automatically through [ACME](/acme/); paid authorities add organisation and extended validation, support agreements and other services. Both validate domains under the same Baseline Requirements [1]. How to choose between them is covered on [choosing a certificate authority](/vs/). ## How to see which authority issued a certificate In a browser, open the padlock or site information and view the certificate: the issuer field names the [intermediate certificate authority that signed it](/certificates/intermediate-certificate/), and the chain view shows the root. From a terminal: ```shell $ openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -dates -ext subjectAltName ``` For a mail server that switches to TLS after connecting, add `-starttls smtp`, for example on the submission port 587 defined in [RFC 6409](https://www.rfc-editor.org/rfc/rfc6409) [5]; `-starttls` also takes `pop3`, `imap`, `ftp` and other protocols [1]. ### Show the chain a server sends ``` $ openssl s_client -connect example.com:443 -servername example.com -showcerts at depth lookup: `; `openssl s_client` ends with `Verify return code: ()`. The numbers and texts come from OpenSSL's list of verification errors [2]; each row was reproduced on the test setup. | Code | Text | What it means | |---|---|---| | 0 | `ok` | the certificate chains to a trusted root | | 9 | `certificate is not yet valid` | its `notBefore` date is after the current time | | 10 | `certificate has expired` | a certificate in the chain is past its `notAfter` date; see [certificate renewal](/certificates/renewal/) | | 18 | `self-signed certificate` | the certificate signed itself and is not in the trust store; see [self-signed certificates](/certificates/self-signed/) | | 19 | `self-signed certificate in certificate chain` | the chain was built, but its root is not in the trust store | | 20 | `unable to get local issuer certificate` | an issuer was not found: at depth 0 the intermediate is missing, at a higher depth the root is not trusted | | 21 | `unable to verify the first certificate` | only one certificate was available, not self-signed, with no issuer to check it | | 62 | `hostname mismatch` | the certificate does not cover the name checked with `-verify_hostname` | ### When `s_client` keeps going `s_client` completes the connection even when the code is not 0 [1], so read the code: a printed certificate does not mean a valid one. `-verify_return_error` makes it stop at the failure instead; against a server that sent no intermediate, it then exited with status 1 rather than 0. ## FAQ **How do I check a certificate's expiry date with OpenSSL?** For a file, run `openssl x509 -in cert.pem -noout -enddate`. For a live site, pipe `openssl s_client -connect example.com:443 -servername example.com` into `openssl x509 -noout -dates`. **How do I verify a certificate chain with OpenSSL?** Run `openssl verify -CAfile root.pem -untrusted intermediate.pem cert.pem`. It prints OK, or an error code, depth and text when the chain does not reach the root. **How do I see the certificate a website is serving?** Run `openssl s_client -connect example.com:443 -servername example.com -showcerts`. It prints each certificate the server sends, then the verification result. **What does "Verify return code: 21 (unable to verify the first certificate)" mean?** The server sent its certificate without the intermediate that signed it, so no path to a trusted root could be built. Install the full chain. **Why do I need `-servername` with `s_client`?** It sets the hostname sent in the handshake, which a server with several sites uses to pick the certificate. Since 1.1.1 OpenSSL sends the `-connect` name itself, so `-servername` matters for IP addresses and older versions. **How do I check a certificate in DER format?** Run `openssl x509 -in cert.der -inform DER -noout -text`. OpenSSL 3 detects DER without the option; 1.1.1 assumes PEM. ## Sources 1. OpenSSL 3.0 [manual pages](https://docs.openssl.org/3.0/man1/): openssl-x509, openssl-s_client, openssl-verify, openssl-req, openssl-pkey, openssl-pkcs12, openssl-pkcs7, openssl-version, openssl-format-options, openssl-verification-options, and openssl (TLS version options). 2. OpenSSL 3.0, [X509_STORE_CTX_get_error](https://docs.openssl.org/3.0/man3/X509_STORE_CTX_get_error/) manual page — texts of the verification errors; include/openssl/x509_vfy.h.in — their numbers. 3. OpenSSL 1.1.1, [x509](https://docs.openssl.org/1.1.1/man1/x509/), req and pkcs12 manual pages — the default input format is PEM; `-nodes` leaves the private key unencrypted. 4. IETF, RFC 7468, Textual Encodings of PKIX, PKCS, and CMS Structures. 5. IETF, RFC 6409, Message Submission for Mail. 6. OpenSSL 3.0, SSL_CTX_load_verify_locations manual page — the default CA file `cert.pem` and directory `certs`. 7. Chrome for Developers, Deprecations and Removals in Chrome 58 — commonName matching in certificates removed. ## Continue in this section - [Certificate chain: intermediate certificates and the chain of trust](/certificates/chain/) — Trust reaches your certificate through a chain. A server that omits the intermediates works in your browser and fails for fresh visitors and scripts. - [Certificate formats: PEM, DER, PFX and when to convert](/certificates/formats/) — PEM, DER, PFX and P7B hold the same certificate encoded differently. How to tell them apart, convert with OpenSSL, and avoid breaking an installation. - [How to check that a certificate and key belong together](/tools/certificate-key-matcher/) — A certificate and a private key either belong together or the service will not serve. Check the pair before restarting, and see what a mismatch looks like. - [Unable to get local issuer certificate: what it means and how to fix it](/errors/unable-to-get-local-issuer-certificate/) — Curl, Git, npm or Python cannot link a certificate to a trusted root. Find whether the server or the client is at fault, and fix it without disabling checks. > **Certificates that renew themselves** — Bridge SSL is the certificate layer of Bridge CDN: issuance and renewal happen as part of serving your site, wildcards included when your DNS is on Bridge DNS. Nothing to install, nothing to schedule. [Get started](https://bridge-cdn.com/) [Fix an error first](/errors/) --- https://bridge-ssl.com/certificates/free-ssl/ --- # Free SSL certificates: who issues them and what you give up A free SSL certificate from a publicly [trusted certificate authority](/certificates/certificate-authority/) is not a lesser certificate. The encryption is the same, browsers trust it the same way, and no visitor can tell what an [SSL certificate](/certificates/) cost. Free certificates are domain-validated only and come without a support contract, so the real requirement they bring is automated renewal. This page covers who issues them, how they differ from paid certificates, and when a free one is enough. - **Issued by** — Let's Encrypt, a nonprofit certificate authority [1], and commercial authorities that run a free tier next to paid plans - **Issued through** — ACME, the issuance protocol of [RFC 8555](https://www.rfc-editor.org/rfc/rfc8555) [2] - **Validation** — domain validation only; the certificate carries policy identifier 2.23.140.1.2.1 [3] - **Assurance of the name** — the same as a paid certificate: the Baseline Requirements say every certificate type provides "the same level of assurance of the device identity" [3] - **Maximum lifetime** — the same cap as paid certificates, 200 days for certificates issued from March 2026 [3] - **Not included** — organisation or extended validation, a support contract, warranty terms ## Who issues free certificates Free SSL/TLS certificates come from publicly trusted authorities that issue them through [ACME](/acme/), the standard protocol for automated issuance. Two kinds of certificate authority do it: - **[Let's Encrypt](https://letsencrypt.org/)**, a nonprofit authority run by the Internet Security Research Group (ISRG). It charges no fee for its certificates and issues domain-validated certificates only; it has no plans for organisation or extended validation, because it cannot automate those checks. Wildcards are available through the DNS-01 challenge. - **Commercial authorities with a free tier.** Some CAs that sell certificates also issue domain-validated ones through ACME at no charge, next to their paid plans; [ZeroSSL](/vs/zerossl/) is one example. What the free tier includes is set by each authority, so read its terms before you depend on it. When something other than Let's Encrypt is warranted is on [Let's Encrypt alternatives](/vs/lets-encrypt/). Hosting providers, control panels and CDNs can also obtain certificates for the sites they serve, without a separate step from you. Let's Encrypt notes that such integrators sometimes charge a nominal fee for providing its certificates, so a free certificate authority does not always mean a free certificate on your bill. Check what your platform does before installing anything. ## How to get one There are two routes, and the choice depends on where TLS ends for your site. 1. **Your host or CDN issues it.** If a platform terminates HTTPS for you, it can obtain and renew the certificate itself. You add the domain, point DNS at the platform, and the certificate follows. Nothing runs on your server. 2. **An ACME client on your server.** A program on the server proves control of the domain, receives the certificate, installs it and renews it before it expires. Choosing a client is a separate decision; installing the result is on [installing a certificate](/install/). For a wildcard such as `*.example.com`, control has to be proved through DNS. Among the ACME validation methods, the Baseline Requirements allow only the DNS-based ones for wildcard names (§3.2.2.4), so the client needs permission to create records in your zone. See [wildcard certificates](/certificates/wildcard/). The steps to [generate an SSL certificate](/certificates/how-to-get/), from key to installed file, are a separate subject from whether to pay for one. ## Free and paid certificates compared ### What you get - **A publicly trusted certificate.** It chains to a root present in browser trust stores, so it produces no warnings and nothing a visitor could see as different. - **Domain validation.** The authority checks that you control the name, the same check behind paid domain-validated certificates. OV and EV add information about the organisation, not a stronger proof of the domain. - **Several names in one certificate.** A free certificate can list several names through the Subject Alternative Name mechanism, and Let's Encrypt issues wildcards with DNS validation. For a site that needs encryption and nothing about the organisation behind it, that is the whole requirement. ### What you do not get None of the differences is about security. - **Organisation or extended validation.** A free certificate rests on domain validation: it proves control of the name and says nothing about who you are. To put an organisation into a certificate, the CA must verify the identity and address of that organisation (BR §3.2.2.1), and a free certificate authority skips that step. Where a compliance framework, a customer or a partner requires organisation details inside the certificate, a free certificate does not provide them. - **A support relationship.** There is documentation and a community forum, but no one under contract to answer when something goes wrong. - **Warranty terms.** A commercial CA can attach a warranty to a paid SSL certificate under its own terms. Whether it would ever pay out is a separate question; its absence is a real difference in what you hold. ### Side by side | | Free certificate | Paid certificate | |---|---|---| | Validation levels | domain validation (DV) | DV, Organization Validation (OV) or Extended Validation (EV) | | Policy identifier | 2.23.140.1.2.1 | 2.23.140.1.2.1 (DV), 2.23.140.1.2.2 (OV), 2.23.140.1.1 (EV) | | Maximum validity period | the Baseline Requirements cap | the same cap | | Renewal | automated through ACME | through ACME where the CA supports it, otherwise by hand | | Help when it breaks | documentation and community forums | support under contract, on the CA's terms | ## Lifetime and renewal Every publicly trusted certificate, paid or free, has the same ceiling. The CA/Browser Forum [ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/) limits every publicly trusted certificate to 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029 (BR §6.3.2). An authority may issue for less; its documentation gives the term it uses. Renewed by hand, a certificate needs attention more than once a year for every name, and the result of forgetting is a full-page browser warning for every visitor. That is why free issuance and automated renewal arrived together: in practice, a free certificate means automation. Paid certificates are moving the same way. Buying a certificate no longer buys a long lifetime, and manual renewal becomes impractical whatever the price. How to renew and what to do when a certificate has expired is on [renewal](/certificates/renewal/). ## Why it costs nothing A certificate is a signature over a small file, and producing it costs an authority very little. Paid certificates used to pay for the parts done by people: checking documents, calling the organisation, handling support, and selling. Automated domain validation removed people from the common case, because software can confirm control of a name directly. What remains is infrastructure, which is cheap per certificate at scale. Let's Encrypt is funded by sponsors, grantmakers and individual donors, so the free certificate is the whole service, not a trial of a paid one. Commercial authorities run their free tier alongside paid plans, the more familiar commercial model. Neither changes the certificate itself. ## When paying is the right call A free SSL certificate is enough when the site needs HTTPS for its names and nothing about the organisation behind it. A paid certificate makes sense in three cases: - **A requirement names organisation validation.** A compliance framework, a customer's procurement process, or an internal policy. The requirement is the reason; the certificate is how you meet it. - **You need someone answerable.** Where certificate problems must be escalated to a party under contract, that relationship is bought. You are paying for a response obligation, not a better certificate. - **A device cannot be automated.** Appliances that accept certificates only through a manual interface are easier to run with the longest lifetime available. With lifetimes shrinking for everyone, plan how such devices will be updated, because paying no longer avoids frequent replacement. Outside those cases, arguments for paying that rest on security or trust describe something that does not differ. ## How to tell what you have A certificate records who issued it, what was checked and when it ends, and one command reads all three from a live site [4]: ```shell openssl s_client -connect example.com:443 -servername example.com /dev/null \ | openssl x509 -noout -issuer -dates -ext certificatePolicies ``` - `issuer` names the authority, free or not. - `notAfter` is the expiry date; the gap from `notBefore` is the lifetime the authority chose. - `Policy: 2.23.140.1.2.1` marks a domain-validated certificate; `2.23.140.1.2.2` is organisation validation and `2.23.140.1.1` extended validation [3]. The price appears nowhere. ## What to check either way The questions that matter are the same at any price. Does the certificate cover every name you serve, including the bare domain and `www`? Does renewal run automatically, and does something independent of the renewal check expiry from outside? Is the full chain served, intermediate CA certificates included, as described on [certificate chains](/certificates/chain/)? A free certificate that is automated and monitored is better placed than a paid one renewed by hand whenever someone remembers. ## FAQ ### Are free SSL certificates safe? Yes. The encryption is negotiated by the same protocols whatever the certificate cost, and browsers either trust an authority or do not. Free and paid certificates from trusted authorities are accepted identically. ### Which certificate authorities issue free SSL certificates? Let's Encrypt, a nonprofit, issues publicly trusted certificates through the ACME protocol at no charge, and some commercial authorities run a free ACME tier next to their paid plans. ### How long does a free SSL certificate last? No longer than a paid one: the cap is 200 days for certificates issued from March 2026, 100 days from March 2027 and 47 days from March 2029. An authority may choose a shorter term; the `-dates` check above shows yours. Renewal is expected to be automated. ### Do browsers treat free certificates differently? No. A certificate has no field that records what it cost, and browsers show the same padlock and the same details for free and paid domain-validated certificates. ### Can I get a free wildcard certificate? Yes. Let's Encrypt issues free wildcard certificates through ACME. Control must be proved through DNS, so the ACME client needs access to your DNS zone. ### Can I get a free OV or EV certificate? No. Organisation and extended validation require checks of the organisation by people, and the free authorities issue domain-validated certificates only. ## Sources 1. Let's Encrypt, About Let's Encrypt and FAQ: cost, validation types, wildcard issuance, support, integrator fees. 2. IETF, RFC 8555, Automatic Certificate Management Environment (ACME). 3. CA/Browser Forum, Baseline Requirements for TLS server certificates: §3.2.2.1, §3.2.2.4, §6.3.2, §7.1.2.7, §7.1.6.1; ballot SC-081v3. 4. OpenSSL, openssl-x509 manual page, options -issuer, -dates and -ext. **Continue in this section** - [What is a certificate authority? What CAs do and why browsers trust them](/certificates/certificate-authority/) — A certificate authority verifies who controls a name and signs certificates saying so. What CAs do, root and intermediate CAs, and why browsers trust them. - [Let's Encrypt alternative: when you actually need one](/vs/lets-encrypt/) — For domain-validated certificates Let's Encrypt is the default and usually the right one. An alternative is warranted in four specific situations. - [DV, OV and EV certificates: what validation actually buys](/certificates/types/) — DV, OV and EV differ in what the authority checks, not in encryption. The four types of SSL certificate, and why browsers moved the EV badge. - [ACME clients: how to choose one by class, not by name](/acme/clients/) — Clients differ in where they run and what they can deploy, not in the protocol. Choose by class: built into the server, scheduled, a library or a platform. --- https://bridge-ssl.com/certificates/root-certificate/ --- # What is a root certificate? Root CAs and the trust store A root certificate is the certificate of a root certificate authority (root CA): a self-signed certificate at the top of a chain of trust. Browsers and operating systems trust it because it is built into their trust store, and every publicly trusted [HTTPS certificate](/certificates/) leads back to one through a [certificate chain](/certificates/chain/). - **Also called** — root CA certificate, trust anchor [2] - **Issuer and subject** — the same name, byte for byte; the root is signed with its own key ([Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/documents/) §7.1.2.1) [1][2] - **CA flag** — basic constraints extension, marked critical, with cA set to TRUE (§7.1.2.1.4) [1] - **Validity of a new root** — 2922 to 9132 days, about 8 to 25 years (§7.1.2.1.1) [1] - **Trusted for websites** — until its key is more than 15 years old, in the Chrome and Mozilla root stores, under their transition rules [4][5] - **Sent by servers** — not needed: TLS 1.3 lets servers omit a trust anchor's certificate ([RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) §4.4.2) [3] ## How a root certificate works A website's certificate is signed by an [intermediate certificate authority](/certificates/intermediate-certificate/), and the intermediate is signed by a root. To trust the site, a client checks each signature up to a certificate it already trusts: the root, which shipped with the browser or the operating system. A root is self-signed: its issuer and subject are the same, and its signature verifies with the public key it carries ([RFC 5280](https://www.rfc-editor.org/rfc/rfc5280) §3.2) [2]. Any certificate can be self-signed, as on [self-signed certificates](/certificates/self-signed/), so a root is trusted not for its signature but because a trust store includes it, after its authority passed that store's checks. Under the Baseline Requirements a root CA signs a certificate only when an authorised person deliberately issues a direct command for that signature (§4.3.1.1), and like every CA key it sits in a cryptographic module validated to at least FIPS 140-2 or FIPS 140-3 level 3, or to a Common Criteria evaluation at EAL 4 or higher (§6.2.7) [1]. Day-to-day issuance uses intermediate keys, so a compromised intermediate can be replaced without touching the root in trust stores. What a root key may sign, and how root systems must be separated from the rest of the network, is on [certificate authorities](/certificates/certificate-authority/). ## What a root certificate looks like On this Linux Mint machine, an Ubuntu derivative, the root files in `/etc/ssl/certs/` are links into the Mozilla set that the `ca-certificates` package installs under `/usr/share/ca-certificates/mozilla/` [6][13]. The output below is from the lab root used later: ``` $ openssl x509 -in root2.pem -noout -subject -issuer subject=O = Example Lab, CN = Example Root CA 2 issuer=O = Example Lab, CN = Example Root CA 2 $ openssl x509 -in root2.pem -noout -ext basicConstraints,keyUsage X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign ``` `CA:TRUE` says the key may sign certificates, and Certificate Sign with CRL Sign are the two key usages the Baseline Requirements require of every CA certificate (§7.1.2.10.7) [1]. A self-signed certificate also verifies against itself: ``` $ openssl verify -CAfile root2.pem root2.pem root2.pem: OK ``` A website certificate shows its issuing CA as issuer and `CA:FALSE`; the Baseline Requirements allow it to omit basic constraints, but never to set cA to TRUE (§7.1.2.7.8) [1][13]. ## Root, intermediate and leaf | | Root certificate | Intermediate certificate | Leaf certificate | |---|---|---|---| | Signed by | itself | a root, or another intermediate | an intermediate | | Signs | intermediates | leaf certificates | nothing | | Where it lives | in the client's trust store | sent by the server with the leaf | sent by the server | | Maximum validity in the Baseline Requirements | 9132 days, about 25 years | not specified | 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027 | The validity row comes from §7.1.2.1.1, §7.1.2.10.1 and §6.3.2 [1]. A server that omits its intermediate breaks the chain for clients that lack it; in curl, Git or Python the symptom is [unable to get local issuer certificate](/errors/unable-to-get-local-issuer-certificate/). ## Trust stores: who decides which roots are trusted A trust store, also called a root store, is the list of root certificates a client trusts. Each root program below runs a store used on the web: - **Mozilla** maintains the store built into Firefox, also used in other companies' products [6]. Debian's `ca-certificates` package, also used by Ubuntu, ships it [13]. - **Apple** maintains one root store for all its operating systems, macOS and iOS included [7]. - **Microsoft** maintains the Windows store, called Trusted Root Certification Authorities [8]. - **Google** maintains the Chrome Root Store, which Chrome uses on Windows, macOS, ChromeOS, Linux and Android instead of the operating system's list. Apple's policies keep it out of Chrome for iOS [9]. Before a root goes in, its authority must pass independent audits and follow the CA/Browser Forum Baseline Requirements and the program's own policy. ### How roots lose trust Roots do not stay trusted for their whole validity. Chrome removes a root whose key material was generated more than 15 years ago ([Chrome Root Program Policy](https://googlechrome.github.io/chromerootprogram/crp/policy/) 1.8, §1.3.1.2), and Mozilla removes the websites trust bit at the same age ([Mozilla Root Store Policy](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) 3.1, §7.4); older roots follow transition schedules [4][5]. A 25-year root can therefore lose website trust long before it expires; Chrome allows temporary extensions case by case [5]. Programs also remove a root, or stop trusting its new certificates, when an authority breaks the rules. Chrome 70 fully removed trust in Symantec's old infrastructure and the certificates chaining to its roots, with a small set of exceptions. Chrome 131 and later do not trust by default new certificates that chain to a set of Entrust roots, while certificates logged before the cut-off keep working [10]. Clients on the same machine can hold different stores: - Firefox carries Mozilla's roots in its own library [6]; - Java uses its own `cacerts` keystore [11]; - Python's requests uses the certifi package [11]. ## How to see the trusted roots on a device - **Windows.** Run `certlm.msc` for the machine's certificates and open **Trusted Root Certification Authorities**, **Certificates**. `certmgr.msc` shows the current user's store [8]. - **macOS.** `security dump-trust-settings -s` shows the trusted system certificates; `-d` shows those an administrator added [11]. - **iPhone and iPad.** The roots Apple ships are listed on Apple's support site [7]. Roots installed with a profile appear under **Settings**, **General**, **About**, **Certificate Trust Settings** [11]. - **Linux.** Debian and Ubuntu keep the system bundle in `/etc/ssl/certs/ca-certificates.crt`; Fedora and RHEL keep theirs under `/etc/pki/ca-trust/` [11]. - **Firefox.** It keeps its own store; the `Certificates` enterprise policy can make it trust roots added to the operating system store on Windows and macOS (`ImportEnterpriseRoots`) [11]. To check whether a root is in the Linux bundle, print every certificate's subject and search for the name; no output means it is not there, as for the lab root here [13]: ``` $ awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i 'Example Root CA' ``` ### Which root a website chains to The `depth=` lines are the path your client built, top first; the numbered `s:` and `i:` lines are what the server sent. A lab server sends a leaf, its intermediate and Example Root CA 2 cross-signed by Example Root CA; the client trusts only Example Root CA 2: ``` $ openssl s_client -connect localhost:8443 -servername www.example.test -CAfile root2.pem -showcerts &1 | grep -E '^depth=|^ [0-9] s:|^ i:' depth=2 O = Example Lab, CN = Example Root CA 2 depth=1 O = Example Lab, CN = Example Issuing CA depth=0 CN = www.example.test 0 s:CN = www.example.test i:O = Example Lab, CN = Example Issuing CA 1 s:O = Example Lab, CN = Example Issuing CA i:O = Example Lab, CN = Example Root CA 2 2 s:O = Example Lab, CN = Example Root CA 2 i:O = Example Lab, CN = Example Root CA ``` The path ends at depth 2 with the self-signed Example Root CA 2 from the client's store, though the last certificate sent names Example Root CA as issuer. That is a cross-certificate: its issuer and subject are different CAs [2]. A client trusting only the old root follows it to `depth=3`, Example Root CA [13]. More commands are on [OpenSSL commands](/certificates/openssl-commands/). ## How to add a private root certificate Organisations run private certificate authorities for internal sites, devices and [mutual TLS](/glossary/mtls/). Their certificates are trusted only where the private root is installed. **Warning.** A root in your trust store can vouch for any website. Add only roots your organisation controls, obtained through a trusted channel, never one a website or an email asks you to install. Remove roots you no longer need. **Windows**, as administrator [11]: ``` certutil -addstore -f Root company-root.cer ``` **macOS**, adding it to the admin trust settings [11]: ``` $ sudo security add-trusted-cert -d -r trustRoot company-root.cer ``` **Debian and Ubuntu** (PEM, file name ending in `.crt`) [11]: ``` $ sudo cp company-root.crt /usr/local/share/ca-certificates/ $ sudo update-ca-certificates ``` **Fedora and RHEL** [11]: ``` $ sudo cp company-root.crt /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust ``` **iPhone and iPad.** Install the profile containing the root, then turn on full trust for it under **Settings**, **General**, **About**, **Certificate Trust Settings** [11]. Applications with their own store need the root added to it: Firefox through the `Certificates` → `Install` enterprise policy [11], Java with `keytool -importcert -cacerts`, and Node.js, curl, Git or Python as described on [unable to get local issuer certificate](/errors/unable-to-get-local-issuer-certificate/). ## When a root expires or is replaced Roots expire too, and the transition can break old devices. Authorities prepare ahead: the old root cross-signs a new one, so clients without the new root still reach a root they trust [12]. Mozilla asks operators to apply with the successor at least two years before the old root's distrust date [4]. Take Let's Encrypt, a [free SSL certification authority](/certificates/free-ssl/) run by the nonprofit Internet Security Research Group [12]. Its older chain led to the root DST Root CA X3 through a cross-sign. When that cross-sign expired, devices with the newer ISRG Root X1 in their store were unaffected; some old devices without trust store updates started rejecting sites [12]. For site owners: serve the chain your authority currently provides, and keep your clients and devices receiving trust store updates. A chain that ends at an expired root gives the same error as any untrusted issuer, described on [ERR_CERT_AUTHORITY_INVALID](/errors/err-cert-authority-invalid/). ## FAQ **What is a root certificate?** The self-signed certificate of a root certificate authority, at the top of a chain of trust. Browsers and operating systems keep trusted roots in their trust stores and trust every certificate that chains up to one. **What is a CA certificate?** A certificate whose key may sign other certificates: its basic constraints extension sets cA to TRUE (RFC 5280 §4.2.1.9). The Baseline Requirements treat any such certificate as either a root or a subordinate CA certificate (§8.1). The root CA certificate is the self-signed one; Debian and Ubuntu bundle every trusted CA cert in `ca-certificates.crt`. **What is the difference between a root certificate and an intermediate certificate?** A root is self-signed and stored on the client. An intermediate is signed by a root, signs the site's certificate and is sent by the server with it. **What is a trusted root certification authority?** An authority whose root is in a trust store. In Windows, Trusted Root Certification Authorities is also the name of the root store. **Why is a root certificate self-signed?** Because nothing sits above it to sign it. Its trust comes from being in a trust store, not from the signature. ## Sources 1. CA/Browser Forum, Baseline Requirements (TLS), version 2.3.1: §4.3.1.1, §6.2.7, §6.3.2, §7.1.2.1, §7.1.2.7.8, §7.1.2.10.1, §7.1.2.10.7, §8.1. 2. IETF, RFC 5280, X.509 certificate and CRL profile: §3.2, §4.2.1.9, §6.1. 3. IETF, RFC 8446, TLS 1.3: §4.4.2. 4. Mozilla Root Store Policy, version 3.1: §7.4 Root CA Lifecycles. 5. Chrome Root Program Policy, version 1.8: §1.3.1.2 Root CA Term-Limit. 6. Mozilla wiki, CA and CA/FAQ: the NSS root store. 7. Apple, Available root certificates for Apple operating systems. 8. Microsoft Learn, Trusted Root Certification Authorities Certificate Store; How to view certificates with the MMC snap-in. 9. Chromium, Chrome Root Store FAQ. 10. Google Online Security Blog, Chrome's Plan to Distrust Symantec Certificates; Entrust Certificate Distrust. 11. Platform manuals: certutil (Microsoft), security(1) (Apple), update-ca-certificates(8), update-ca-trust(8), keytool (Oracle), Requests CA Certificates, Firefox enterprise policies (Mozilla), Apple certificate trust settings for iOS. 12. Let's Encrypt, DST Root CA X3 Expiration; About Let's Encrypt. 13. Our runs: OpenSSL 3.0.13 on Linux Mint 22.1, against the local `ca-certificates` package and a lab chain with test roots. ## Continue in this section - [Certificate chain: intermediate certificates and the chain of trust](/certificates/chain/) — Trust reaches your certificate through a chain. A server that omits the intermediates works in your browser and fails for fresh visitors and scripts. - [What is a certificate authority? What CAs do and why browsers trust them](/certificates/certificate-authority/) — A certificate authority verifies who controls a name and signs certificates saying so. What CAs do, root and intermediate CAs, and why browsers trust them. - [Self-signed certificates: what they are and how to create one](/certificates/self-signed/) — A self-signed certificate is signed by its own key, not a CA. How to create one with OpenSSL, when it is the right choice, and why browsers refuse it. - [Unable to get local issuer certificate: what it means and how to fix it](/errors/unable-to-get-local-issuer-certificate/) — Curl, Git, npm or Python cannot link a certificate to a trusted root. Find whether the server or the client is at fault, and fix it without disabling checks. > **Certificates that renew themselves** — Bridge SSL is the certificate layer of Bridge CDN: issuance and renewal happen as part of serving your site, wildcards included when your DNS is on Bridge DNS. Nothing to install, nothing to schedule. [Get started](https://bridge-cdn.com/) [Fix an error first](/errors/) --- https://bridge-ssl.com/certificates/check/ --- # How to check an SSL certificate: browser, command line and online To check an SSL certificate is to confirm that the certificate a site serves is valid for its name, is within its dates, and chains to a trusted root. You can do it in a browser for a quick look, from the command line for an exact answer, or with an online test that also grades the server's TLS settings. This page shows all three, what to look for, and how to find the certificate on your own server. It is part of the [certificates](/certificates/) section. ## Quick facts | | | |---|---| | Fastest | the browser's certificate viewer | | Most precise | `openssl s_client` from a machine other than the server | | Most complete | an online server test, which also checks protocols and the chain | | What to confirm | dates, names, chain, issuer | | Do it | after every installation or renewal, and on a schedule | ## What to check Whatever tool you use, four things decide whether visitors connect without a warning: 1. **Dates.** The current date is between the certificate's start and end dates. A certificate close to its end date needs renewal now; see [renewal](/certificates/renewal/). 2. **Names.** Every hostname visitors use, including the bare domain and `www`, is listed in the Subject Alternative Name. See [Subject Alternative Names](/certificates/san/). 3. **Chain.** The server sends its own certificate and the intermediates, and the chain ends at a root clients trust. See [certificate chains](/certificates/chain/). 4. **Issuer.** The certificate comes from the [SSL certificate authority](/certificates/certificate-authority/) you expect. An unexpected issuer can mean a proxy is intercepting the connection, or that someone else obtained a certificate for your name. The protocol versions the server accepts matter too, but they are a property of the server, not the certificate; see [TLS versions](/tls/versions/). ## Check a certificate in the browser **Chrome and Edge.** Click the icon to the left of the address, choose **Connection is secure**, then **Certificate is valid**. The viewer shows the names, the issuer, the dates and, under the details tab, every field and the chain. **Firefox.** Click the padlock, choose **Connection secure**, then **More information**, and **View Certificate**. Firefox shows each certificate in the chain on its own tab. **Safari on a Mac.** Click the padlock in the address bar and choose **Show Certificate**. **Safari on iPhone and iPad.** There is no certificate viewer. Check from a computer, or use an online test. A browser check has one blind spot: browsers fill in missing intermediates from their cache, so a chain that works in your browser can still fail for other visitors and for apps. Confirm the chain with one of the methods below. ## Check from the command line From any machine with OpenSSL, against the hostname visitors use: ```text $ openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName ``` That prints the names, issuer and dates of the certificate the server actually sends. To check the chain, run `s_client` with `-showcerts` and read the result at the end of the output: `Verify return code: 0 (ok)` means the chain is complete and trusted. Other codes, and what each one means, are explained alongside the [OpenSSL commands to verify a certificate](/certificates/openssl-commands/). `curl` gives a quick yes or no, with the certificate details in its verbose output: ```text $ curl -vI https://example.com/ ``` A certificate problem makes curl stop with an error such as `SSL certificate problem: unable to get local issuer certificate`; see [unable to get local issuer certificate](/errors/unable-to-get-local-issuer-certificate/). ## Check with an online test An online server test connects from outside your network, so it sees what visitors see. It reports the certificate, the chain the server sends, the protocol versions and ciphers it accepts, and known configuration problems. The [Qualys SSL Labs Server Test](https://www.ssllabs.com/ssltest/) is a widely used free example, and it grades the result. Use an online test after the first installation and after configuration changes. For a quick check after each renewal, the command line is faster. ## Find the certificate on your server Sometimes the question is not whether the certificate is valid, but which file the server uses. - **nginx.** The `ssl_certificate` directive in the site's `server` block names the file. See [installing on nginx](/install/nginx/). - **Apache.** `SSLCertificateFile` in the virtual host on port 443. See [installing on Apache](/install/apache/). - **IIS.** Certificates are in the Windows store, not in files; the site's https binding shows which one is used. See [installing on IIS](/install/iis/). - **Certbot.** `certbot certificates` lists every certificate it manages, with names, expiry dates and file paths, usually under `/etc/letsencrypt/live/`. Then compare the file with what the server sends. If they differ, the server has not been reloaded, or something in front of it, such as a load balancer or CDN, serves its own certificate. ## Check expiry automatically A one-off check finds today's problem. Expiry is a dated problem, and certificates are now replaced every few months, so the check belongs on a schedule. The OpenSSL option `-checkend` turns it into a yes-or-no answer for scripts: ```text $ openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -checkend 1209600 ``` The command exits with status 1 if the certificate expires within 14 days. Run it from outside the server, separately from whatever renews the certificate, so that a failed renewal is caught before visitors see it. ## FAQ **How do I check if an SSL certificate is valid?** Open the site in a browser and view the certificate from the icon next to the address, or run openssl s_client -connect example.com:443 -servername example.com and look for Verify return code: 0 (ok). Confirm the dates, the names and the issuer. **How do I check when an SSL certificate expires?** In the browser's certificate viewer, read the Valid to or Expires date. From the command line, pipe openssl s_client into openssl x509 -noout -enddate. **How do I check an SSL certificate chain?** Run openssl s_client with -showcerts. It lists every certificate the server sends; the site's own certificate should be followed by at least one intermediate, and the result should be Verify return code: 0 (ok). **How do I find which SSL certificate my server uses?** Read the server's configuration: ssl_certificate in nginx, SSLCertificateFile in Apache, or the https binding in IIS. certbot certificates lists the certificates Certbot manages and their paths. **Can I check an SSL certificate on iPhone?** Safari on iPhone and iPad has no certificate viewer. Use an online server test or check from a computer. **Why does the certificate look fine in my browser but fail elsewhere?** Your browser may have cached the intermediate certificate the server fails to send. Check with openssl s_client -showcerts or an online test, which see the chain as a new visitor does. --- https://bridge-ssl.com/certificates/how-to-get/ --- # How to get an SSL certificate: three routes, one process Getting an [SSL certificate](/certificates/) follows the same process whoever runs it: ask an authority to certify some names, prove you control them, send a signing request built from your key, install what comes back. Knowing how to create an SSL certificate is mostly knowing your route, since the route decides who performs each step: your host or CDN, an ACME client on your server, or you, with a paid authority. - **Steps** — four after account setup: order the names, prove control, finalize with a CSR, download the certificate ([RFC 8555](https://www.rfc-editor.org/rfc/rfc8555) §4) [1] - **Signing request** — a CSR carries a name, your public key and optional attributes, signed by the requester ([RFC 2986](https://www.rfc-editor.org/rfc/rfc2986)) [2] - **Who checks** — a publicly trusted certificate authority, which must validate control of every name (Baseline Requirements §3.2.2.4) [3] - **CAA records** — where published, only an authority they permit may issue ([RFC 8659](https://www.rfc-editor.org/rfc/rfc8659) §3) [4] - **Maximum lifetime** — 200 days for certificates issued since 15 March 2026 (Baseline Requirements §6.3.2) [3] ## Three routes compared The protocol does not change between routes. What changes is who holds the key, who proves control, and who repeats the work at renewal. | | Your host or CDN | ACME client on your server | Paid authority, by hand | |---|---|---|---| | Key and CSR created by | the platform | the client, automatically | you, with OpenSSL or a generator | | Control proved by | the platform | the client: a file or a DNS record | you: a DNS record, a file, or an email to the domain contact | | Validation | domain validation when issued through ACME | domain validation | DV, OV or EV | | Renewal | the platform | the client, on a schedule | a new order each time | | Fits when | the platform already terminates HTTPS for the site | you run the server and can schedule a job | a requirement names organisation validation, or a device cannot be automated | ## Route 1: your host or CDN issues it If a platform terminates HTTPS for your site, it can get the SSL certificate itself, and the private key stays with it. Let's Encrypt, a free certificate authority, puts this question first in its getting-started guide: will your hosting provider get and manage certificates for you, or do you need to run an ACME client yourself [5]? A provider that does it is running that client on your behalf. Your part: 1. Add the domain and every hostname you serve to the platform. 2. Point DNS at the platform, or let it publish the validation record if it manages your zone. 3. Once it is live, check the names, issuer and expiry date from outside. Confirm two things before relying on it. Are both the bare domain and `www` covered? And how is expiry watched, by something independent of the platform? A check run by the renewing system reports success until that system is the part that fails. Bridge SSL is the certificate layer of [Bridge CDN](https://bridge-cdn.com/) and works this way: issuance and renewal happen as part of serving your site, and no certificate file sits on your server. It works only for hostnames Bridge CDN serves, and it has no import path for a certificate bought elsewhere. If a paid certificate is required, use route 3. ## Route 2: an ACME client on your server An ACME client is the program that does the work when you generate an SSL certificate on your own server. It runs the whole exchange against a [free certification authority](/certificates/free-ssl/), or any authority that speaks the [ACME protocol](/acme/). It suits a server where you can install software and schedule a job. 1. Install a client, register an account. The account has its own key pair, separate from the key in the certificate [1]. 2. Order the names. List every hostname, the bare domain and `www` included. 3. Prove control. For HTTP-01 the authority fetches a token from `/.well-known/acme-challenge/` over TCP port 80; for DNS-01 the client publishes a TXT record at `_acme-challenge.` [1]. A wildcard such as `*.example.com` needs a DNS method: the Baseline Requirements do not allow the website-file methods for wildcard names [3]. 4. Finalize. The client generates a private key and a certificate signing request, and submits the request [1]. 5. Download the certificate with its chain, install it, and reload the server. 6. Schedule renewal. Renewal repeats the same exchange, and most clients generate a new key each time. The client also has to keep running. Automation that was set up once and then stopped fails in silence, which is why the expiry check from route 1 applies here too. ## Route 3: a paid certificate authority Buying an SSL certificate from a paid authority is the same process done by hand, and it is the only route to organisation or extended validation. 1. Generate a private key and a [certificate signing request](/certificates/csr/) on the server that will use the key. Put every name in the subject alternative name field; browsers ignore a name that appears only in the common name. 2. Choose the validation level, place the order and paste in the CSR. 3. Prove control of each name with a method the authority offers: a DNS record, a file on the website, or an email to a domain contact [3]. 4. For OV, wait while the authority verifies the organisation and its address, through a government agency, a reliable third-party database, a site visit or an attestation letter [3]. EV applies a stricter version of the same check. 5. Receive the certificate and its intermediate certificates, install them with the key, and reload. 6. For renewal, place a new order before expiry with a fresh key and CSR. Reusing an old request reuses the old key. Paying is the only way to the organisation check, and it adds a support contract and often warranty terms. The encryption is the same as on the free routes. ## Making a self-signed certificate is not getting one You can [use OpenSSL to create a certificate](/certificates/self-signed/) in one command, with no authority involved. That certificate is signed by its own key, so nobody independent vouches for it, and browsers refuse it on public sites. It is the right tool for development and for internal systems where the people connecting can verify the server by other means. For anything a stranger might visit, take one of the three routes above. ## Before you request: three checks These apply on every route, before you create or order an SSL certificate. **Every name is listed.** Put every hostname in the certificate signing request. Browsers read only the subject alternative names, and adding a forgotten name later means a reissue. Include the bare domain and `www`. **CAA allows your certificate authority.** Look up the domain's CAA records before ordering: ```text $ dig +short CAA example.com 0 issue "ca1.example.net" ``` If `issue` records come back and none of them names your authority, it must refuse [4]. For a wildcard, any `issuewild` record takes precedence over `issue`. Add a record for your authority, or order from one that is listed. **The key has a home.** Decide where the private key will live before you generate it: on the machine that terminates TLS, readable only by the account that needs it. On route 1 the platform holds it. On routes 2 and 3 it is a file you are responsible for, replaced at each renewal if you generate a fresh one, and it never goes to the authority. ## After issuance: install, check, renew A new SSL certificate is useful only once it is served with its chain. Install the certificate, the intermediate certificates and the private key together, reload the service, and then check how the hostname presents it from outside your network: ```text $ openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -enddate notAfter=Jul 21 00:00:00 2025 GMT ``` The `-enddate` option prints notAfter [4]. If that date is in the past, the certificate expired. To have a script decide instead of a person, `-checkend` takes a number of seconds and exits non-zero if the certificate expires within them [4]; `0` means "has it already expired": ```text $ openssl x509 -in expired.pem -noout -checkend 0 Certificate will expire $ echo $? 1 ``` Then look one level up. In the `openssl s_client` output, error 10 under `depth=0` means the server's own certificate expired; under `depth=1`, the intermediate above it did, and the fix is a current [certificate chain](/certificates/chain/), not a new leaf. If the dates bracket today and a single device still complains, the problem is that device's clock, a case covered with the [browser SSL errors](/errors/). ## What to do now 1. **Find every place the certificate is served.** The origin, a load balancer, a CDN, a mail server: each holds its own copy. 2. **Compare the file with what is served.** Run `openssl x509 -in -noout -enddate` on the file the server is configured with [4]. A future date there and a past one in the served output mean the renewal happened and never reached visitors: install and reload, do not request another. 3. **Otherwise, get a replacement.** An expired certificate cannot be extended; its dates are part of what the authority signed. If renewal is automated, start it by hand and read what it prints: it has already failed once unseen. The procedure is on [certificate renewal](/certificates/renewal/). 4. **Keep the same type of SSL certificate unless you have a reason to change.** OV and EV add a check of the organisation's identity and address [2], which a domain-validated replacement skips; see [type of SSL certificates](/certificates/types/). 5. **Install it with the intermediate that came with it,** not one saved from an earlier certificate. 6. **Serve it and check from outside.** Rerun the command above or follow [how to check an SSL certificate](/certificates/check/). The new notAfter should appear, without error 10. For a domain-validated certificate with no tie to its issuer, a [free certificate authority](/certificates/free-ssl/) issues one over ACME. ## After service is back Restoring the certificate ends the outage, not necessarily the incident. - **Resend what failed.** Ask each webhook sender for the deliveries that failed during the window, and check that mail queued by senders has arrived. - **Tell people plainly.** Say that a certificate expired and has been replaced. Do not tell visitors to click through the warning, now or next time. - **Find out why.** Nobody owned the certificate, automation stopped without anyone noticing, a renewal was obtained and never served, or the monitored certificate was not the one that lapsed. Each cause has a different fix. ## Catch the next expiry before it happens Check what each hostname serves, from outside, on a schedule that does not depend on whatever renews the certificate. A renewal job that stops running reports no error, and a check built on the same job sees nothing wrong. The `-checkend` test turns the earlier command into that monitor. Here it runs against a lab certificate with months left and a 30-day window: ```text $ openssl x509 -in valid.pem -noout -checkend $((30*86400)) Certificate will not expire $ echo $? 0 ``` A non-zero exit is the alert. Point it at every hostname and port the certificate serves, mail included. The interval between expiries is shrinking. The [SSL certification authority](/certificates/certificate-authority/) that issued your certificate chose its end date within a ceiling set by the CA/Browser Forum: up to 398 days for certificates issued before 15 March 2026, 200 days since then, 100 days from 15 March 2027 and 47 days from 15 March 2029 [2]. Each step down means more renewals a year, and each renewal is another chance for an expired certificate. ## FAQ ### What does it mean when a website's security certificate has expired? The end date written into the certificate has passed, so browsers no longer accept it as proof that the site is the one it claims to be. They stop before any page loads. The site may be fine otherwise; it needs a new certificate. ### Can you use an expired certificate? Only by switching off the check that makes it useful. curl's `--insecure` option skips verification altogether, which also skips confirming that the server is the one named in the URL. Browsers on a site that uses HSTS must not offer the visitor a way past the error ([RFC 6797](https://www.rfc-editor.org/rfc/rfc6797), §8.4, §12.1). Replace the certificate instead. ### How do I update an expired SSL certificate? You replace it: obtain a new certificate for the same names, install it with its chain wherever TLS ends, reload, and check from outside that the new end date is served. ## Sources 1. IETF, [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280), Internet X.509 Public Key Infrastructure Certificate and CRL Profile — §4.1.2.5 validity; §6.1.3 basic certificate processing. 2. CA/Browser Forum, [Baseline Requirements for TLS Server Certificates](https://cabforum.org/working-groups/server/baseline-requirements/documents/) (version 2.3.1) — §6.3.2 maximum validity period; §3.2.2.1 authentication of organization identity. 3. IETF, [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446), The Transport Layer Security (TLS) Protocol Version 1.3 — §6.2 error alerts, `certificate_expired`. 4. OpenSSL 3.0, [openssl-x509 manual page](https://docs.openssl.org/3.0/man1/openssl-x509/) — options -enddate and -checkend; X509_STORE_CTX_get_error manual page — X509_V_ERR_CERT_HAS_EXPIRED; openssl-s_client manual page. 5. curl, [manual page](https://curl.se/docs/manpage.html) — option -k, --insecure; exit code 60. 6. Python documentation, ssl module — `SSLCertVerificationError`, `verify_code`, `verify_message`. 7. IETF, RFC 8461, SMTP MTA Strict Transport Security (MTA-STS) — §5 policy application. 8. IETF, RFC 6797, HTTP Strict Transport Security (HSTS) — §8.4 errors in secure transport establishment; §12.1 no user recourse. **Continue in this section** - [What is an SSL certificate? Contents and lifecycle](/certificates/) — A certificate is a signed statement about who controls a name. What it contains, what an authority checks, and the four stages of its life. - [SSL certificate renewal: renew before it expires](/certificates/renewal/) — Renewal issues a new certificate with new dates; nothing is extended. What carries over, when to renew, and how to check the renewal is served. - [How to check an SSL certificate: browser, command line and online](/certificates/check/) — Check an SSL certificate's dates, names and chain in Chrome, Firefox or Safari, with OpenSSL and curl, or with an online test, and find it on your server. - [Certificate chain: intermediate certificates and the chain of trust](/certificates/chain/) — Trust reaches your certificate through a chain. A server that omits the intermediates works in your browser and fails for fresh visitors and scripts. --- https://bridge-ssl.com/errors/err-cert-authority-invalid/ --- # ERR_CERT_AUTHORITY_INVALID: what it means and how to fix it Your browser received a certificate it cannot trace back to an authority it trusts. Either the certificate genuinely came from an untrusted source, or it came from a trusted one and the server failed to send the intermediate certificates that prove it. The second is far more common. [Firefox shows the same fault](/errors/) as SEC_ERROR_UNKNOWN_ISSUER. ## Quick facts | | | |---|---| | **Browsers** | Chrome, Edge, and other Chromium browsers | | **Exact text** | `Your connection is not private` with `NET::ERR_CERT_AUTHORITY_INVALID` | | **Layer** | certificate trust chain | | **Who fixes it** | usually the site owner; occasionally the visitor | ## What this error means Trust in a certificate is not a property of the certificate itself. [It comes from a chain](/certificates/chain/): your browser trusts [a small set of root authorities](/certificates/root-certificate/), those roots vouch for intermediate authorities, and intermediates issue the certificate a site presents. The browser must be able to follow that chain from the certificate it received up to a root it already trusts. This error means it could not; a failure earlier in setup, before any certificate is checked, appears in Chrome as [ERR_SSL_PROTOCOL_ERROR](/errors/err-ssl-protocol-error/) instead. Three situations produce that outcome, and they need different responses. ## Fixes by cause ### The server is not sending its intermediate certificates A missing intermediate is the most frequent cause by a wide margin, and the most counterintuitive, because the certificate is entirely valid. A server must present its own certificate **and** the intermediates connecting it to a root. If it sends only its own, browsers that have previously cached the intermediate connect without complaint, and browsers that have not show this error. That is why the site appears to work for some visitors and not others, and why "it works on my machine" proves nothing here. **Owner fix.** Reconfigure the server to serve the full chain. Certificate authorities supply a bundle for this purpose, and most server software has a specific setting or file for it. After changing it, verify from a machine that has never visited the site. **Visitor workaround.** None. This is entirely the site's to fix. ### The certificate is self-signed A certificate issued by nobody in particular. Common on internal systems, development environments, and appliances that ship with one. **Owner fix.** For anything public, obtain a certificate from a recognised authority. Self-signed certificates are appropriate for internal use where you can distribute the certificate deliberately, and they are never appropriate for a public site. **Visitor action.** If this is a device on your own network, the error is expected. If it is a public site, treat the warning as accurate. ### A proxy or antivirus is intercepting the connection Corporate networks and some security software intercept encrypted traffic by presenting their own certificate. This is a deliberate arrangement in managed environments and is supposed to be accompanied by installing the intercepting authority on the device. When that installation has not happened, or when consumer antivirus does it uninvited, every site shows this error. The distinguishing symptom is breadth: one site failing points elsewhere, but many unrelated sites failing at once points here. **Visitor fix.** On a corporate device, this is for your administrators. On a personal device, look at whether security software has an HTTPS scanning feature enabled, and consider whether you want it. ## Browser variants Firefox reports the same underlying failure as `SEC_ERROR_UNKNOWN_ISSUER`, with wording about the issuer not being recognised. Safari describes it in words rather than with a code, usually mentioning that the certificate is not trusted. The diagnosis and fixes are identical in all three. ## How to diagnose The question to answer first is whether the chain is incomplete or the issuer is genuinely untrusted, because the fixes are different. Test from a device that has never visited the site, ideally on a different network. If it fails there and works on your usual machine, the chain is incomplete and your browser had the intermediate cached. Then check how many sites are affected. One site is a server configuration problem; many unrelated sites at once is interception on your device or network. ## Why an incomplete chain is so hard to notice An incomplete chain deserves its own explanation, because its invisibility is the reason the fault survives in production for months. When a browser encounters an intermediate certificate it has not seen, it stores it. Every subsequent connection to any site using that intermediate then succeeds, whether or not that site sends it. So the person who installed the certificate, tested it immediately, and saw it work has proven only that their own browser had already collected the missing piece. Whose browsers lack it varies: new devices, cleared profiles, less common browsers, and anything that does not fetch missing intermediates automatically. Some clients do go and fetch them; others refuse. Which means the affected share is not stable and not measurable from where you are standing. Reports like "a few customers say the site is broken" and "our monitoring shows everything fine" are what an incomplete chain looks like, and dismissing them as user error is the standard way this goes unfixed. Non-browser clients deserve particular attention here. Command-line tools, mobile applications, payment callbacks, and server-to-server requests generally do not accumulate intermediates the way browsers do, so an incomplete chain that visitors barely notice can break integrations outright. In curl, Git and other tools that use OpenSSL or similar libraries, the same missing intermediate is reported as [unable to get local issuer certificate](/errors/unable-to-get-local-issuer-certificate/). An OpenSSL-based client then ends the TLS handshake with an `unknown_ca` alert, which the server records in its log; how to read that alert from both ends is covered in [SSL handshake failed: causes and fixes](/errors/handshake-failed/). ## How to prevent it Serve the full chain from the start, and verify it after every certificate change rather than after complaints. Renewal is the moment this breaks most often: a new certificate is installed correctly and its intermediate is forgotten, and the failure is invisible to whoever did the work because their browser still has the old intermediate cached. A renewal that does not happen at all fails differently: once the old certificate expires, Chromium browsers show [NET::ERR_CERT_DATE_INVALID](/errors/err-cert-date-invalid/). Automating issuance and installation removes the step where this is forgotten, which is the practical reason it is worth doing beyond convenience. ### Fix this with Bridge SSL Bridge SSL issues certificates and serves the complete chain automatically, so the most common cause on this page cannot occur through oversight. Renewal installs the current chain along with the certificate rather than leaving it as a separate manual step. See what the platform offers at [Bridge CDN](https://bridge-cdn.com/). ## FAQ **What does ERR_CERT_AUTHORITY_INVALID mean?** ERR_CERT_AUTHORITY_INVALID means the browser could not trace the certificate back to any authority in its trust store. The usual reason is an incomplete chain: the server sent its own certificate but not the intermediates that connect it to a root. Less often the certificate is self-signed or issued by an authority the device does not trust. **Why does the site work for some people and not others?** Because browsers keep intermediates they have seen before. A visitor whose browser already holds the missing link completes the chain from memory and notices nothing, while a first-time visitor on a clean device gets the warning. The split is not random: it tracks who has browsed where. **Can I fix it as a visitor?** Only when the cause sits on your side, which means a proxy or security product intercepting connections without its own authority installed on the device. An incomplete chain, a self-signed certificate, or an untrusted issuer all belong to the site, and nothing you change locally will resolve them safely. **Is it safe to continue anyway?** Not on a public site, and least of all on one where you sign in. The warning says the identity behind the connection could not be established, which is the exact condition an interceptor needs. Continuing turns a detected problem into an undetected one. **Why do I see it on every site suddenly?** Because something began intercepting all of your traffic: a corporate proxy whose authority was never installed on your device, or security software that started scanning HTTPS after an update. A fault at one site cannot produce warnings everywhere, so breadth is the diagnostic. **How do I check my chain is complete?** Test from a device that has never visited the site, ideally on another network, or use an external chain checker. Your own browser is the worst available witness, because it is the one most likely to be holding the intermediate whose absence you are trying to prove. --- https://bridge-ssl.com/errors/err-cert-date-invalid/ --- # ERR_CERT_DATE_INVALID: what it means and how to fix it Your browser found a certificate outside its validity window. Either the certificate expired, or it is not valid yet, or the clock on the checking device is wrong. Which of the three decides whether the fix is yours or the visitor's, and finding out takes about a minute. [Firefox shows the same fault](/errors/) as SEC_ERROR_EXPIRED_CERTIFICATE. ## Quick facts | | | |---|---| | **Browsers** | Chrome, Edge, and other Chromium browsers | | **Exact text** | `Your connection is not private` with `NET::ERR_CERT_DATE_INVALID` | | **Layer** | certificate validity window | | **Who fixes it** | the site owner, unless the visitor's clock is wrong | | **Warning first** | none — the change is instant and total | ## What this error means Every certificate carries two fields that bound its life: `notBefore` and `notAfter`. A browser reads them, compares both against its own idea of the current time, and rejects the certificate if the answer falls outside. There is no tolerance window and no degraded mode. A certificate that was fine one second ago is refused the next, for every visitor at once. The comparison has two sides, and that is what makes this error ambiguous. The certificate can be wrong, or the clock can be wrong. A device whose date is set months into the future will reject a perfectly valid certificate, and a device set into the past will reject one that has not started yet. Either way the connection got as far as checking a certificate, which separates this error from [ERR_SSL_PROTOCOL_ERROR](/errors/err-ssl-protocol-error/), where setup fails before that point. ## Fixes by cause **The certificate expired.** The common case, and the one the site owner owns. `notAfter` has passed. Nothing about the certificate can be repaired: a new one has to be issued and put into service. [Renewal issues a replacement](/certificates/renewal/); the original is never extended, whatever the documentation's wording suggests. **The certificate is not valid yet.** `notBefore` is in the future. This appears after a certificate is issued and deployed faster than the authority's own timestamp, or on a server whose clock runs behind. Wait, or correct the server clock, and it resolves itself. **The clock on the visitor's device is wrong.** Nothing is wrong with the site. A phone or laptop with a badly wrong date rejects the certificate, and only that device sees it. Ask the visitor what date their device thinks it is; if it is not today, that is the whole answer. **The intermediate expired, not the leaf.** Rarer, and easy to misread. The certificate your server presents can be well inside its window while a certificate above it in the chain is not. A checker that reports the chain rather than only the leaf will show which one. A chain that is incomplete rather than out of date produces a different error, [ERR_CERT_AUTHORITY_INVALID](/errors/err-cert-authority-invalid/). ## Browser variants Chromium browsers show `NET::ERR_CERT_DATE_INVALID` under the heading `Your connection is not private`. Firefox reports the same underlying fault as `SEC_ERROR_EXPIRED_CERTIFICATE` under `Warning: Potential Security Risk Ahead`. Safari does not print a code and says the connection is not private. The fault is identical in all three; only the wording differs. ## How to diagnose Ask the certificate what it thinks, from outside, on a machine whose clock you trust. An independent check matters here more than in most errors, because the failure mode you are testing for is a disagreement about time, and a check running on the affected machine inherits its clock. Read `notBefore` and `notAfter` from what the hostname actually presents. If both bracket the current time, the certificate is fine and the problem is the clock on whatever machine reported the error. If `notAfter` has passed, renewal did not happen or did not reach this hostname. If `notBefore` is ahead of the current time, the certificate is early rather than expired, and the same two suspects apply: the authority's timestamp or the server clock. From a terminal on a machine whose clock you trust, OpenSSL reads both dates from the certificate the hostname presents: ```text $ openssl s_client -connect example.com:443 -servername example.com >>` marks what the client sent, `<<<` what it received, and the alert keeps its RFC name [7]. To test versions, add `-tls1_2` or `-tls1_3` to the first command. To test SNI, run it once with `-noservername` in place of `-servername`: if it fails only then, the server depends on the hostname and the failing client is not sending one. Then narrow it down with three questions, in order. Does every client fail, or only some? Total failure points at the server's configuration or its certificate and key. Does a browser succeed where a script fails? That points at the chain or the client's trust store. Does the failure follow the network? Then something in between is terminating connections. When you have access to both ends, read both logs. The alert name alone does not always settle it: in our test, `handshake_failure` reached the client both for a missing shared cipher suite and for a missing client certificate under TLS 1.2, and only the server log, `no shared cipher` or `peer did not return a certificate`, told them apart [7]. ### TLS handshake timeout A timeout is a different failure: the handshake never finished because messages stopped arriving. Go's HTTP client reports it as `net/http: TLS handshake timeout` [6]. In our test, a listener that accepted TCP connections and never answered gave `curl: (28) SSL connection timeout` and, in Python, `The handshake operation timed out` [7]. Look at the network path, a firewall or a proxy before TLS settings. ## How to prevent it Test from outside after every certificate, server or proxy change, and include a non-browser client such as `openssl s_client` or curl. Endpoints used by other systems need this test most, because their clients are libraries. Keep protocol versions and ciphers current, and check them again after either side's TLS library is upgraded. A handshake works only where the two lists overlap, and an upgrade on either side can change its list. ## FAQ ### What does "SSL handshake failed" mean? The client and server could not complete the exchange that sets up an encrypted connection. They found no common protocol version or cipher, one side rejected the other's certificate, or something between them interrupted the exchange. ### How do I fix "SSL handshake failed"? Find where it stops with `openssl s_client -msg` or `curl -v`, read the alert, and read the server's log. Then fix the matching cause: enable TLS 1.2 and 1.3, adjust the cipher list, serve the full certificate chain, configure the hostname, or supply a client certificate if the server requires one. ### What does "sslv3 alert handshake failure" mean? It is OpenSSL's message for the `handshake_failure` alert, number 40. The `sslv3` prefix is part of the message name and does not mean SSL 3.0 was used. The alert says the sender could not agree on parameters. In our test both a missing shared cipher and, under TLS 1.2, a missing client certificate produced it, and only the server log told which. ### Why does it work in the browser but fail from my script? Check the two things the script depends on: the chain the server sends and the CA file the script trusts. Run `openssl s_client -showcerts` against the site to see the chain as the server sends it. The page on unable to get local issuer certificate covers the browser-versus-script case in full. ### Can a client certificate cause a handshake failure? Yes. If the server requires mutual TLS, a client that connects without an accepted certificate fails the handshake. In TLS 1.3 the alert is `certificate_required`; under TLS 1.2 the server may send `handshake_failure` instead. ### What causes a TLS handshake timeout? Messages stopped arriving before the TLS handshake finished. Check the network path before the TLS settings, looking for a firewall, proxy or load balancer that accepts the connection and passes nothing back. In our test, a listener that accepted the TCP connection and never answered produced it. ## Sources 1. IETF, RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3, sections 2, 4.4.2.4 and 6 (alerts). 2. IETF, RFC 5246, The TLS Protocol Version 1.2, section 7.4.6. 3. IETF, RFC 6066, TLS Extensions, section 3 (server_name). 4. OpenSSL 3.0, ssl/ssl_err.c and crypto/err/openssl.txt (error messages); openssl-s_client manual page (-servername, -noservername, -msg, -showcerts). 5. Chromium, net/base/net_error_list.h; Mozilla NSS, lib/ssl/SSLerrs.h. 6. OpenJDK, sun/security/ssl/Alert.java; Go, crypto/tls/alert.go and net/http/transport.go. 7. Our test setup: OpenSSL 3.0 servers and clients, curl, Python, Chrome and Firefox, with certificates from a test authority of our own. 8. curl, libcurl error codes: CURLE_SSL_CONNECT_ERROR (35), CURLE_RECV_ERROR (56). --- https://bridge-ssl.com/errors/err-ssl-version-or-cipher-mismatch/ --- # SSL_ERROR_NO_CYPHER_OVERLAP and ERR_SSL_VERSION_OR_CIPHER_MISMATCH SSL_ERROR_NO_CYPHER_OVERLAP in Firefox and ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome mean the same thing: the browser and the server found no protocol version or [cipher suite they both accept](/tls/cipher-suites/), so no encrypted connection could start. The cause is almost always the server's configuration, typically one that still offers only old versions or ciphers that browsers have since dropped. The fix is to enable TLS 1.2 and TLS 1.3 with a current cipher list, not to make the browser accept less. ## Quick facts | | | |---|---| | Firefox | `Secure Connection Failed`, `Cannot communicate securely with peer: no common encryption algorithm(s)`, code `SSL_ERROR_NO_CYPHER_OVERLAP` | | Chrome and Edge | `This site can't provide a secure connection`, `uses an unsupported protocol`, code `ERR_SSL_VERSION_OR_CIPHER_MISMATCH` | | What failed | negotiation of the protocol version or cipher suite, before any certificate was sent | | Who fixes it | the site owner, in nearly every case | | Related | [ERR_SSL_PROTOCOL_ERROR](/errors/err-ssl-protocol-error/), [SSL handshake failed](/errors/handshake-failed/) | ## What the error means Every HTTPS connection begins with a [TLS handshake](/tls/handshake/). The browser sends the protocol versions and the cipher suites it supports; the server picks one of each from its own list. When the two lists have nothing in common, the server ends the handshake with an alert and the browser shows this error. The failure comes before the server presents its certificate, so it is unrelated to certificate trust errors such as [ERR_CERT_AUTHORITY_INVALID](/errors/err-cert-authority-invalid/), where the issuer cannot be verified. Firefox splits the failure in two. `SSL_ERROR_NO_CYPHER_OVERLAP` means no shared cipher suite, and `SSL_ERROR_UNSUPPORTED_VERSION` means no shared protocol version. Chrome reports both with one code, which is why its name contains "version or cipher". The diagnosis below tells the two apart. The usual story is that nothing changed on the server. Browsers remove old versions and ciphers on their own schedule: Chrome no longer supports TLS 1.0 or TLS 1.1, and Firefox turns both off by default. A server configured years ago keeps offering what it always offered, and one browser update later its list no longer overlaps with theirs. ## If you are a visitor The server decides what can be negotiated, so a visitor can rarely fix this. Three checks are worth a minute: 1. **Update the browser and the operating system.** A very old browser or device may lack the versions a current server requires. 2. **Undo changed TLS settings in Firefox.** If you or an extension changed preferences starting with `security.tls` or `security.ssl3` on `about:config`, reset them to their default values. Changed values are shown in bold. 3. **Try another network.** Antivirus HTTPS scanning, a corporate proxy or a filtering appliance can negotiate on your behalf with its own, older list. If the site works on mobile data, the interference is on the first network. Do not lower the minimum TLS version in the browser to get past the error. It makes every site you visit accept protocols that were removed for being unsafe, and it leaves the actual problem, the server's configuration, where it was. If the site fails on another device and another network, only its owner can fix it. ## Causes on the server ### Only old protocol versions are enabled The most common cause. The server accepts TLS 1.0 or 1.1 and nothing newer, often because the configuration predates TLS 1.2 becoming the norm, or because the operating system or TLS library is too old to offer it. Firefox reports this as `SSL_ERROR_UNSUPPORTED_VERSION` and the handshake ends with the `protocol_version` alert. Enable TLS 1.2 and TLS 1.3. In nginx: ```text ssl_protocols TLSv1.2 TLSv1.3; ``` In Apache: ```text SSLProtocol -all +TLSv1.2 +TLSv1.3 ``` Where the library cannot offer TLS 1.2 at all, the fix is upgrading it or the operating system, not a configuration line. Details are on [TLS versions](/tls/versions/). ### The cipher list contains nothing a browser accepts The versions match, but every cipher suite the server allows has been removed from browsers: RC4, 3DES, export-grade ciphers and others. This is `SSL_ERROR_NO_CYPHER_OVERLAP` in its exact sense. Replace the cipher list with a current one rather than adding to the old one. The [Mozilla SSL Configuration Generator](https://ssl-config.mozilla.org/) produces maintained lists for nginx, Apache, HAProxy and other servers, with a choice of how far back client support should reach. ### The cipher list does not match the certificate's key In TLS 1.2, each cipher suite names the kind of key the server must authenticate with. Suites marked `ECDSA` need a certificate with an ECDSA key, and suites marked `RSA` need an RSA key. A server whose list contains only ECDSA suites while its certificate has an RSA key has nothing it can actually use, and the handshake fails with no shared cipher even though the list looks modern. Check the key type with `openssl x509 -in cert.pem -noout -text` and keep suites for that type in the list. ### A typo empties the cipher list Cipher strings are combined with `:`, `+` and `!`, and one mistake can exclude everything. OpenSSL shows what a string actually expands to: ```text $ openssl ciphers -v 'ECDHE+AESGCM:!aNULL' ``` An empty result or `no cipher match` means the server is offering nothing. TLS 1.3 suites are configured separately from this list, so a server with a broken list can still work over TLS 1.3 and fail for every client limited to TLS 1.2. ### Something in front of the server When a load balancer, proxy or CDN terminates connections, its configuration is the one visitors negotiate with. A correct server behind an old front end still produces this error, so check the layer that answers on port 443. On Windows Server, protocol versions and cipher suites are set for the whole machine in the operating system's TLS component, Schannel, rather than per site in IIS. Changes there need a restart to apply. ## How to diagnose Test from outside, against the hostname visitors use. Offer one version at a time: ```text $ openssl s_client -connect example.com:443 -servername example.com -tls1_2 `; the policy has to be a response header [1]. - **Testing on a host the browser does not trust.** A header that arrives over a connection with certificate errors is not stored [1], so a test host with an untrusted certificate never gets a policy, even after the warning is clicked through. - **Preloading as a first step.** The safe order is the reverse: ramp max-age up in stages, and submit to the preload list last. ## What HSTS does not do HSTS controls how the browser reaches a site, not whether the site is trustworthy. RFC 6797 lists phishing on a fake site under another domain, and malicious code on the user's own system, among the threats it does not address [1]. It does nothing on the first visit from a browser that has never received the policy, for a name that is not on a preload list. What it removes is one specific path: a plain request, or the redirect that answers it, intercepted by someone on the network. Nor does it restrict which certificates a browser accepts for the name; that was the job of HPKP, the browser form of [certificate pinning](/glossary/certificate-pinning/), which Chrome has removed and MDN lists as obsolete [5]. Which certificate authorities may issue for a domain is set by a CAA record in its DNS, not by an HTTP header. ## FAQ **What is HSTS?** HSTS is a response header that tells browsers to use only HTTPS for a site and to remember that for the period set in max-age. Once a browser has it, plain requests to that name are upgraded inside the browser before anything is sent. **How do I turn HSTS off?** On the site, send the header with max-age=0; browsers that come back and receive it delete the policy. For testing, chrome://net-internals/#hsts in Chrome deletes a policy learned from a header, but not a preloaded entry: that one has to come off the preload list, which takes months to reach users. **What does "HSTS missing from HTTPS server" mean?** It means the site's HTTPS responses do not include a Strict-Transport-Security header. Scanners report it as a hardening finding; visitors see no error, but their first plain request can still be intercepted. **Should I submit my site to the HSTS preload list?** hstspreload.org does not recommend preloading. Submit only once every subdomain works over HTTPS for the long term: the list requires includeSubDomains and a max-age of at least one year, and removal takes months. **Does HSTS replace the redirect from HTTP to HTTPS?** No. The redirect is still needed for the first visit and for clients without the policy, and the preload list requires it on a site that listens on port 80. HSTS makes the redirect unnecessary only for browsers that already hold the policy and whose max-age has not run out. ## Related terms The connection itself is covered under [TLS](/tls/), certificates under [certificates](/certificates/), and the warnings a browser shows when something is wrong under [errors](/errors/). The rest of the vocabulary is in [this glossary](/glossary/). ## Sources 1. IETF, RFC 6797, HTTP Strict Transport Security: §2.3.2 (threats not addressed), §6.1–6.2 (header, max-age, includeSubDomains), §8.1 (processing, IP addresses), §8.3 (URI loading and port mapping), §8.4 (errors in secure transport establishment), §8.5 (meta element), §12.1 (no user recourse), §12.3 and §14.6 (pre-loaded list, bootstrap MITM vulnerability). 2. hstspreload.org, HSTS Preload List Submission: benefits of HSTS, deployment recommendations, preloading, submission requirements, removal. 3. Chromium source, chrome/browser/resources/net_internals/index.html: Query HSTS domain; Delete domain security policies. 4. Tenable, Nessus plugin 84502, HSTS Missing From HTTPS Server. 5. Chrome Platform Status, Remove HTTP-Based Public Key Pinning; MDN Web Docs, Glossary: HPKP. --- https://bridge-ssl.com/glossary/mtls/ --- # What is mTLS? Mutual TLS and how it differs from TLS Mutual TLS (mTLS) is a TLS connection in which both sides present certificates: the server proves who it is, and the client does too. It is defined in the [SSL and TLS glossary](/glossary/) next to the ordinary, one-way TLS that every HTTPS site uses. ## One-way TLS versus mutual TLS In ordinary TLS only the server is authenticated. The browser checks the server's certificate against the name it asked for; the server learns nothing about the client at that stage, and identifies a person later with a password, a cookie or a token. Mutual TLS moves client identity into the connection itself. The server asks for a certificate, the client presents one and proves it holds the matching private key, and the server checks it against the authorities it accepts. If that check fails, the connection ends before any request reaches the application. ## What happens in the handshake The difference is one extra exchange. In TLS 1.3 ([RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)) the server sends a CertificateRequest message, listing the kind of certificate it will accept. The client answers with its own Certificate and a CertificateVerify message, a signature made with the client's private key over the handshake so far. That signature is the point. The client never sends a reusable secret: it demonstrates possession of a key, so a recording of the exchange cannot be replayed to impersonate it. This is the same property that makes server authentication work, applied in the other direction. If the client sends no certificate, or one the server does not trust, the server ends the handshake with an alert. Tools report this as a handshake failure, and the server's log usually says which check failed. ## Where mTLS is used - **Service-to-service traffic.** Systems that call each other's APIs inside a company or between partners, where every client is a machine you issued a certificate to. - **Zero-trust networks.** Where being inside a network grants nothing, and every connection has to prove which workload it comes from. - **Administrative interfaces and devices.** Panels and devices that should accept connections only from known machines. It fits poorly with the general public. Every visitor would need a certificate issued, installed and replaced, which is the work ordinary sign-in exists to avoid. Browsers can present client certificates, but the experience of choosing one from a prompt is why consumer sites do not ask for it. ## How to test a mutual TLS endpoint Both OpenSSL and curl can present a client certificate: ```text $ openssl s_client -connect api.example.com:443 -cert client.crt -key client.key $ curl --cert client.crt --key client.key https://api.example.com/ ``` Run the same command without the certificate. If the endpoint really requires mTLS, the second attempt should fail at the handshake rather than return a page. ## What the server has to be configured with Turning mutual TLS on is a short list of decisions, and each one is a place where a setup goes quietly wrong. - **Which authorities to trust for clients.** A separate list from the one browsers use for servers. Trusting a public authority here would accept any certificate anyone can obtain for any domain. - **Whether a certificate is required or optional.** Optional lets the application decide per route; required rejects anything without one at the handshake. - **Which part of the certificate identifies the client.** Usually a name in the subject or the subject alternative names. That value is what the application authorises, so it has to be one you control when issuing. - **Where identity is handed to the application.** When a proxy terminates TLS, it passes the verified identity on, typically in a request header. The application must accept that header only from the proxy, or anyone can set it. ## Why mutual TLS fails - **The server never asks.** Client certificate verification is off or optional, so a client without one gets through and the problem shows up later as an authorisation error. - **The certificate is not for client authentication.** Certificates carry an extended key usage; one issued only for server authentication can be refused when presented as a client certificate. - **The chain is incomplete.** The client sends its own certificate without the intermediate that links it to the authority the server trusts. - **It expired.** Client certificates are issued and forgotten more often than server ones, and nothing in a browser warns anyone first. ## What it costs to run The certainty comes with a certificate lifecycle for every client, and that is the part people underestimate. - **Issuing.** Usually from a private authority you operate, not a public one, so that only clients you approved can obtain a certificate your server accepts. - **Distribution.** Each client needs its certificate and private key placed where its software can read them, and nowhere else. Encoding is not protection: anyone who can read an unencrypted key in [the base64 text of a PEM-format file](/glossary/pem/) has it. - **Renewal.** Client certificates expire like server certificates. An expired client certificate looks, from the outside, like a sudden outage of one integration. - **Revocation.** When a client should stop being trusted, the server has to learn that, which is harder than it sounds; see [certificate revocation](/certificates/revocation/). ## What mTLS does not give you It proves which certificate the client holds, not what the client is allowed to do. Authorisation, rate limits and auditing still belong to the application. It also proves nothing about a stolen key: a client certificate copied with its private key works for whoever has it, until it is revoked or expires. ## FAQ **What is mTLS?** mTLS, or mutual TLS, is a TLS connection where the client also presents a certificate and proves it holds the matching private key, so both sides are authenticated before any data is exchanged. **How is mTLS different from TLS?** Ordinary TLS authenticates only the server. mTLS adds a client certificate to the same handshake, so the server can reject an unknown client before the application sees a request. **Do browsers support client certificates?** Yes. A browser can present a client certificate when a site asks for one, usually by showing a prompt to choose it. That prompt is the reason mTLS is used for machines and known users rather than public websites. **Who issues client certificates for mTLS?** Usually a private certificate authority run by the organisation, so that only approved clients can get a certificate the server accepts. A public authority would let anyone with a domain obtain one. **Is mTLS the same as an API key?** No. An API key is a secret sent with each request and can be replayed if captured. mTLS proves possession of a private key during the handshake without sending it. Many systems use both: mTLS to identify the client, a key or token for what it may do. ## Related terms The connection is covered under [TLS](/tls/), certificates and their lifecycle under [certificates](/certificates/). A stricter check in the other direction is [certificate or key pinning](/glossary/certificate-pinning/), in which an app accepts only specific server certificates or public keys. The rest of the vocabulary is in [this glossary](/glossary/). --- https://bridge-ssl.com/glossary/sni/ --- # What is SNI? Server Name Indication in TLS SNI (Server Name Indication) is the field in which a client tells a server which hostname it wants, at the very start of a TLS connection. It is part of the [SSL and TLS glossary](/glossary/) because it explains why many HTTPS sites can share one IP address, and why the wrong certificate sometimes appears. - **Defined in** — the server_name extension, [RFC 6066](https://www.rfc-editor.org/rfc/rfc6066) §3 (2011); first specified in [RFC 3546](https://www.rfc-editor.org/rfc/rfc3546) (2003) [1] - **Carries** — one DNS hostname in ASCII, without a trailing dot; a literal IPv4 or IPv6 address is not permitted [1] - **Sent in** — the ClientHello, the first message of the handshake, before anything is encrypted - **In TLS 1.3** — every implementation must support it, and a server may refuse a ClientHello without it [2] - **Hidden only by** — Encrypted Client Hello (ECH), [RFC 9849](https://www.rfc-editor.org/rfc/rfc9849) [3] ## The problem SNI solves A server presents its certificate before any HTTP request arrives. When one address serves many sites, the server has to choose which certificate to present before the browser has said which site it wants, and without more information it cannot choose correctly. SNI moves the name forward. The client states the hostname in its first message, the server reads it, picks the certificate that covers that name, and the handshake continues. This is what makes it ordinary to host many HTTPS sites on one IP address, each with its own certificate. The term is often searched as SSL SNI, but it is a TLS extension: RFC 3546 added it to TLS 1.0, RFC 6066 restated it for TLS 1.2, and [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) lists it for TLS 1.3 [1][2]. ## Where the name travels The name is carried in the server_name extension of the ClientHello, the first message of the handshake, defined in RFC 6066 §3. TLS 1.3 makes it mandatory to implement: RFC 8446 §9.2 requires every implementation to support server_name for applications that can use it, and allows a server to end a handshake that arrives without it [2]. Because a certificate has to be chosen before the connection is encrypted, the name travels before encryption too. Someone watching the network can see which site is being requested, though not the pages or data exchanged afterwards. TLS 1.3 encrypts every handshake message after the ServerHello, the server's certificate included [2][3]; the ClientHello is not among them. RFC 9849 calls the plaintext SNI perhaps the most sensitive information left unencrypted in TLS 1.3 [3]. ## What happens without SNI If a client sends no name, or something on the path strips it, the server falls back to its default certificate. The browser then receives a certificate for a different name and reports a name mismatch, not anything mentioning SNI, which is why this failure is diagnosed slowly. The browser compares the name it asked for with the subject alternative name list in the certificate, not with the certificate CN. The same symptom appears when the server has a certificate for the name but the virtual host matching the name is configured wrongly. In both cases the question is the same: which certificate does the server present when asked for this exact hostname. For an app that [pins certificates or keys](/glossary/certificate-pinning/), that certificate also has to match the pin the app carries, or the connection is refused. ## SNI on servers and proxies On a web server, each virtual host or server block declares the names it answers for, and the name in SNI selects the block and its certificate. One block is the default: it answers any name nobody else claimed, and any client that sends no name at all. Load balancers and CDNs use the same field before they decrypt anything. They can route a connection to the right backend, or hand it through unopened, by reading the name in the ClientHello. That is why an edge that terminates TLS for many customers needs SNI to choose the certificate it presents for each of them. Wildcard and multi-name certificates do not remove the need for SNI; they reduce how many certificates the server has to choose between. A wildcard for *.example.com still leaves the server choosing between that certificate and every other one it holds. A single certificate covering every hosted name is the only arrangement that works without it. ## How to test it OpenSSL sends a name when you give it one, and can be told not to: ```text $ openssl s_client -connect example.com:443 -servername www.example.com $ openssl s_client -connect example.com:443 -noservername ``` Since OpenSSL 1.1.1, s_client fills in the SNI from the -connect host whenever that host looks like a DNS name, so -servername matters when the hostname you test differs from the host you dial [4]. Point -connect at an IP address and no name is sent unless you add one. Compare the certificate subject and names in the two outputs. If the first shows the right certificate and the second shows the default certificate, the server relies on SNI, which is normal. If both show the wrong one, the problem is the server's configuration, not the client. ## Common SNI failures - **Connecting by IP address.** SNI carries host names only; RFC 6066 does not allow a literal IP address in it. A client that connects to an address directly sends no name and receives the default certificate. - **Old tools and libraries.** Scripts and embedded clients that predate SNI, or that set it only when told to, get the default certificate and report a mismatch. - **A server that requires a name.** A TLS 1.3 server may require server_name, and should then close a connection that lacks it with a missing_extension alert [2]. The client then sees a handshake failure, not a wrong certificate. - **A name not configured on the server.** The client sends the right name, but no virtual host claims it, so the default block answers with its own certificate. - **Different names in SNI and in the Host header.** The TLS name and the HTTP name are separate fields. A server can answer 421 Misdirected Request when a request names a host the connection was not set up for ([RFC 9110](https://www.rfc-editor.org/rfc/rfc9110) §15.5.20) [5], so a client that sets them independently can fail after a successful handshake. ## SNI and privacy The visible hostname in the ClientHello is a known trade-off of the ordering, not a flaw in an implementation. Hiding it in transit also leaves the site on record elsewhere: [certificate transparency logs](/glossary/certificate-transparency/) publicly record TLS server certificates as they are issued ([RFC 9162](https://www.rfc-editor.org/rfc/rfc9162)) [6], and Chrome does not validate certificates that lack the log proofs its policy requires [6]. ### Encrypted Client Hello (ECH) ECH, published by the IETF as RFC 9849, encrypts the ClientHello itself [3]. The client puts the real hello, with the true SNI, inside an outer ClientHello whose SNI carries the public_name of the client-facing server. It encrypts with a key the site publishes in advance, in an HTTPS or SVCB record in DNS ([RFC 9848](https://www.rfc-editor.org/rfc/rfc9848)) or preconfigured [3]. A server that cannot decrypt the inner hello completes the handshake with the outer one; RFC 9849 calls that rejecting ECH. Earlier iterations of the extension were called ESNI, Encrypted Server Name Indication [7]. Chrome Platform Status lists ECH as enabled by default from Chrome 117, and the Firefox 119 release notes announce ECH as available to Firefox users [7]. ECH applies only to sites that publish an ECH configuration [3]. ## FAQ **What is SNI?** A TLS extension, defined in RFC 6066, in which the client sends the hostname it wants in its first message, so the server can present the certificate for that name. It lets one IP address serve many HTTPS sites. **Why does my server show the wrong certificate?** Usually because the server did not match the requested name to a virtual host and presented its default certificate, or because the client sent no name. Test with openssl s_client and -servername set to the exact hostname. **What is the difference between SNI and SAN?** SNI is the name the client asks for; the subject alternative name (SAN) list is the set of names a certificate covers. The server picks a certificate by SNI, and the client checks its name against the SAN list. **Is SNI encrypted?** Not in ordinary TLS, TLS 1.3 included: the name travels before encryption begins, in view of the network. Encrypted Client Hello (ECH) encrypts it where both sides support it. **Do all browsers support SNI?** Every TLS 1.3 implementation is required to support it (RFC 8446 §9.2), so any browser that speaks TLS 1.3 does. No name arrives from old libraries and scripts, or from connections made to a bare IP address. **What is ECH?** Encrypted Client Hello, RFC 9849, is the IETF standard that encrypts the ClientHello, hostname included, under a key the server publishes in advance. Observers see only the public name of the server in front. ## Related terms The connection is covered under [TLS](/tls/); certificates that list several names are under [SAN certificates](/certificates/san/), and what any TLS certificate contains is under [SSL certificates](/certificates/). The rest of the vocabulary is in [this glossary](/glossary/). ## Sources 1. IETF, RFC 6066, Transport Layer Security (TLS) Extensions: Extension Definitions, §3 Server Name Indication; RFC 3546, Transport Layer Security (TLS) Extensions. 2. IETF, RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3, §1.2 and §9.2. 3. IETF, RFC 9849, TLS Encrypted Client Hello; RFC 9848, Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings. 4. OpenSSL, openssl-s_client manual page, options -servername and -noservername. 5. IETF, RFC 9110, HTTP Semantics, §15.5.20 421 Misdirected Request. 6. IETF, RFC 9162, Certificate Transparency Version 2.0; Chrome Certificate Transparency Policy. 7. Chrome Platform Status, TLS Encrypted Client Hello (ECH); Mozilla, Firefox 119.0 release notes. --- https://bridge-ssl.com/glossary/ssl-vs-tls/ --- # SSL vs TLS: what the difference actually is SSL is the original name of the protocol that secures connections; TLS is the name it has carried since its revision as an open standard. In the [SSL and TLS glossary](/glossary/) they share one entry, because in everyday use they mean the same thing, and only TLS is actually in use. ## The short answer TLS replaced SSL. Every version called SSL is deprecated and refused by current browsers, so any HTTPS connection you make today runs TLS. The words are still used interchangeably, which is why certificates are sold as SSL certificates and settings are labelled SSL/TLS. ## How SSL became TLS SSL 2.0 and SSL 3.0 came first; SSL 3.0 is documented as historical in [RFC 6101](https://www.rfc-editor.org/rfc/rfc6101). The standard then moved to the IETF and was renamed TLS: TLS 1.0, 1.1 and 1.2 were revisions of the same line, and TLS 1.3 ([RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)) redesigned the handshake. The old versions were retired as weaknesses were found. SSL 2.0 was prohibited, SSL 3.0 was deprecated in [RFC 7568](https://www.rfc-editor.org/rfc/rfc7568), and TLS 1.0 and 1.1 were deprecated in [RFC 8996](https://www.rfc-editor.org/rfc/rfc8996). What remains in use is TLS 1.2 and TLS 1.3. ## SSL and TLS versions by year | Version | Published | Status | |---|---|---| | SSL 2.0 | 1995, Netscape | prohibited in 2011 ([RFC 6176](https://www.rfc-editor.org/rfc/rfc6176)) | | SSL 3.0 | 1996, Netscape | deprecated in 2015 ([RFC 7568](https://www.rfc-editor.org/rfc/rfc7568)) | | TLS 1.0 | 1999, [RFC 2246](https://www.rfc-editor.org/rfc/rfc2246) | deprecated in 2021 ([RFC 8996](https://www.rfc-editor.org/rfc/rfc8996)) | | TLS 1.1 | 2006, [RFC 4346](https://www.rfc-editor.org/rfc/rfc4346) | deprecated in 2021 ([RFC 8996](https://www.rfc-editor.org/rfc/rfc8996)) | | TLS 1.2 | 2008, [RFC 5246](https://www.rfc-editor.org/rfc/rfc5246) | current | | TLS 1.3 | 2018, [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) | current | What each current version changed is on [TLS versions](/tls/versions/). ## Why everyone still says "SSL certificate" The name outlived the protocol. Certificates are sold as SSL certificates, libraries keep the word in their names, and configuration directives keep it for compatibility. None of that means the technology is outdated. A certificate also has no protocol version. It binds a name to a key, and the same certificate works with whichever TLS version the two sides agree on. Asking for an "SSL certificate" and a "TLS certificate" gets you the same thing; see [what a certificate contains](/certificates/). An app that [pins a certificate](/glossary/certificate-pinning/) checks the certificate's key, or the certificate itself, against a copy it carries. ## What changed between TLS 1.2 and TLS 1.3 TLS 1.3 removed the options that caused most of the trouble in earlier versions, shortened the handshake to one round trip and encrypts more of it. What changed, whether TLS 1.2 is still safe and how to set the versions a server accepts are covered on [TLS versions](/tls/versions/). ## Where "SSL" still appears, and what it means there The word stays in names that are too widely used to change. OpenSSL, LibreSSL and BoringSSL are TLS libraries. Server configuration keeps it in directive names: nginx writes the accepted versions as `ssl_protocols TLSv1.2 TLSv1.3;`, Apache as `SSLProtocol -all +TLSv1.2 +TLSv1.3`. In both, the directive name says SSL and the values say which TLS versions are allowed, and only the values matter. Tools reporting an "SSL error" are reporting a TLS failure. The exact code tells you which check failed; see [SSL errors](/errors/). ## What SSL/TLS means in mail settings Mail clients often offer a choice labelled SSL/TLS or STARTTLS. Neither is about the protocol version. SSL/TLS means the connection is encrypted from the first byte on a dedicated port, such as 465 for submission or 993 for IMAP; STARTTLS means the client connects in plain text on the usual port and then upgrades. [RFC 8314](https://www.rfc-editor.org/rfc/rfc8314) recommends the first for mail submission and access. ## Which versions a server should accept TLS 1.2 and TLS 1.3, and nothing older. Turning on an old version because its label looks familiar is how a weak protocol stays reachable, so read version settings as the exact identifiers they are. Check what a host actually agrees to rather than what its configuration file appears to say: ```text $ openssl s_client -connect example.com:443 -tls1_3 $ openssl s_client -connect example.com:443 -tls1_1 ``` The first should complete; the second should be refused. How the protocol works step by step is on [TLS](/tls/). ## FAQ **Is SSL the same as TLS?** In everyday use, yes: both words refer to the protocol that secures HTTPS. Technically TLS is the successor to SSL, and every SSL version is deprecated, so connections today use TLS. **Is SSL still used?** No. SSL 2.0 and 3.0 are deprecated and current browsers refuse them. The name survives in product names and settings, but the protocol in use is TLS 1.2 or TLS 1.3. **Is an SSL certificate a TLS certificate?** Yes. A certificate does not carry a protocol version; it identifies a name and its key, and the same certificate works with any TLS version the two sides negotiate. **Which TLS version should a server support?** TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 are deprecated in RFC 8996, and SSL 3.0 in RFC 7568. **What does SSL/TLS mean in email settings?** It means the connection is encrypted from the start on a dedicated port, as opposed to STARTTLS, which upgrades a plain connection. It does not choose between SSL and TLS versions. **When did TLS replace SSL?** TLS 1.0 was published in 1999 as the successor to SSL 3.0. SSL 3.0 was deprecated in 2015, and TLS 1.0 and 1.1 followed in 2021, leaving TLS 1.2 and TLS 1.3 in use. ## Related terms The protocol is covered under [TLS](/tls/) and [forward secrecy](/tls/forward-secrecy/); certificates under [certificates](/certificates/), and the public record of their issuance under [certificate transparency logs](/glossary/certificate-transparency/). The rest of the vocabulary is in [this glossary](/glossary/). --- https://bridge-ssl.com/glossary/port-443/ --- # Port 443: what the HTTPS port is for Port 443 is the standard network port for HTTPS: when an address starts with https:// and names no port, the browser connects to port 443. It sits in the [SSL and TLS glossary](/glossary/) because what runs on port 443 is TLS. - **Registered to** — the https service, on TCP and on UDP, in the IANA port registry [1] - **Default for** — https:// addresses that name no port; plain http:// defaults to port 80 [2] - **Carries** — HTTP/1.1 and HTTP/2 over TCP, HTTP/3 over QUIC on UDP [3][4] - **Encrypts** — nothing by itself: TLS does the encrypting, whatever the port number ## What port 443 is A port number tells a server which service a connection is for. The [IANA port registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) assigns 443 to https on both TCP and UDP [1], and the https scheme in [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110) §4.2.2 makes TCP port 443 the default when an address gives no port [2]. The same default was set out earlier in [RFC 2818](https://www.rfc-editor.org/rfc/rfc2818), HTTP Over TLS, which RFC 9110 obsoletes [2]. So the answer to what port HTTPS uses is 443, and the default HTTPS port is the reason a browser never has to be told it. The number does not do the encrypting. HTTPS, HTTP sent inside a TLS connection, is the protocol; 443 is only where it is expected. A server could run TLS on any port or run something unencrypted on 443. Port 22, registered to SSH [1], belongs to a separate protocol with its own encryption; how the two differ is on [SSL vs SSH](/glossary/ssl-vs-ssh/). ### HTTPS on another port HTTPS works on any port; 443 is only the default. Another port has to be written into every address, as in `https://example.com:8443/`, and a network that lets only ports 80 and 443 out will block it. ## Port 443 and port 80 Port 80 is the default for http:// addresses, port 443 for https:// [2]. A site that serves HTTPS keeps port 80 open to redirect visitors to the same address on 443, so that an old link or a typed address without https:// still ends up encrypted. Closing port 80 entirely breaks those first visits; leaving it open without a redirect serves the site unencrypted. Both ports open, with port 80 doing nothing but redirecting, covers both cases. [HSTS](/glossary/hsts/) then removes port 80 from later visits: a browser holding the site's policy rewrites http:// to https:// and an explicit port 80 to 443 before it sends anything ([RFC 6797](https://www.rfc-editor.org/rfc/rfc6797) §8.3) [7]. ## HTTPS port 443 over TCP and UDP - **HTTP/1.1 and HTTP/2.** Both run over TLS on TCP port 443. HTTP/2 keeps the https scheme and its default port, and the two sides agree on it inside the TLS handshake through ALPN, under the token h2 ([RFC 9113](https://www.rfc-editor.org/rfc/rfc9113) §3) [3]. - **HTTP/3.** Runs over QUIC, whose packets travel in UDP datagrams ([RFC 9000](https://www.rfc-editor.org/rfc/rfc9000)) [4]. A client can open QUIC to the port in the https:// address, 443 when none is given, or to a UDP port the server advertises in an Alt-Svc header with the h3 token ([RFC 9114](https://www.rfc-editor.org/rfc/rfc9114) §3.1) [4]. - **When UDP is blocked.** RFC 9114 tells clients to try HTTP over TCP when a QUIC connection cannot be set up [4]. A firewall that allows only TCP 443 still lets the site load, over HTTP/2 or HTTP/1.1. - **APIs and tunnels.** An API at an https:// address uses 443 for the same reason a browser does: it is the scheme's default. A VPN or tunnel on TCP 443 passes a firewall rule that allows TCP 443 out, and looks like HTTPS to anything that reads only port numbers. ## TLS ports for mail and other protocols If you are after the TLS or SSL port of a protocol other than HTTPS, it has its own. Mail, LDAP and FTP have two ways of starting encryption: implicit TLS, where the connection is encrypted from the first byte on a dedicated port, and an upgrade, where the client connects in plain text on the usual port and then switches to TLS. [RFC 8314](https://www.rfc-editor.org/rfc/rfc8314) recommends implicit TLS for mail submission and access [5]. | Protocol | Implicit TLS port | Upgrade on the plain port | |---|---|---| | HTTPS | 443 | none | | SMTP submission | 465 | 587, STARTTLS | | SMTP relay | none | 25, STARTTLS | | IMAP | 993 | 143, STARTTLS | | POP3 | 995 | 110, STARTTLS | | LDAP | 636 | 389, StartTLS | | DNS over TLS | 853 | none | | FTP | 990 | 21, AUTH TLS | Port numbers are from the IANA registry [1]; the upgrade commands, and port 853 for DNS over TLS, from the protocol standards [5][6]. ### Mail submission, relay and testing Submission is how a mail client sends; relay is how mail servers pass messages to each other, always on port 25, because MX records have no way to name another port [5]. RFC 8314 finds no significant security difference between STARTTLS on 587 and implicit TLS on 465, provided the implementations are correct and both client and server require TLS before any mail is sent [5]. When a mail client offers SSL/TLS and STARTTLS, the first is implicit TLS and the second is the upgrade; what those labels mean is on [SSL vs TLS](/glossary/ssl-vs-tls/). To test, connect directly for implicit TLS, the same way as to port 443, or add `-starttls` with the protocol [8]: ``` $ openssl s_client -connect mail.example.com:465 -servername mail.example.com $ openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com ``` More commands are on [OpenSSL commands](/certificates/openssl-commands/). ## Port 443 behind a CDN or load balancer When a site sits behind a CDN or a load balancer, visitors connect to port 443 on the edge, not on the origin server. The edge presents the certificate and terminates TLS there. The connection from the edge to the origin is a separate one, which may use 443 with its own certificate or another port entirely, depending on how the two are set up. That is why a site can work for visitors over HTTPS while the origin's port 443 is closed, and why opening 443 in the origin's firewall changes nothing a visitor sees when all traffic arrives through the edge. It is also why, for an app that [pins the server's certificate](/glossary/certificate-pinning/), the pin has to match what the edge presents, not the origin's certificate. ## How to check whether port 443 is open From another machine, test the connection and the TLS handshake separately: ``` $ nc -vz example.com 443 $ openssl s_client -connect example.com:443 -servername example.com $ curl -vI https://example.com/ ``` 1. **Connection refused or timed out.** Nothing is listening on 443, or a firewall drops the traffic before it reaches the server. 2. **Connects, but the handshake fails.** The port is open, and the problem is TLS: no certificate configured, or the server speaks plain HTTP on 443. 3. **Handshake succeeds, browser still warns.** The port is fine; the certificate is the problem. Start from the exact code on [SSL errors](/errors/). On the server itself, opening the port means two separate things: a firewall rule that allows TCP 443 (and UDP 443 for HTTP/3), and a web server configured to listen there with a certificate. ## Common port 443 mistakes - **Plain HTTP on port 443.** The server answers on 443 without TLS. In our test against a plain HTTP server, `openssl s_client` (OpenSSL 3.0) stopped with `wrong version number`, Chrome showed ERR_SSL_PROTOCOL_ERROR, its generic SSL protocol error, and Firefox showed SSL_ERROR_RX_RECORD_TOO_LONG [9]. - **The firewall is open, the cloud rule is not.** A host firewall allows 443 while the provider's security group or network rule still blocks it, or the other way round. - **Only IPv4 opened.** The site has an IPv6 address in DNS, but 443 is open only on IPv4, so visitors on IPv6 networks time out. - **TCP open, UDP closed.** The site advertises HTTP/3, but UDP 443 is blocked. Pages still load over TCP [4], so this one shows up only as HTTP/3 never being used. - **A certificate for the wrong name.** Port 443 answers with a default certificate because the requested name is not configured; see [SNI](/glossary/sni/). ## FAQ **What is port 443 used for?** Port 443 is the default port for HTTPS, the encrypted version of HTTP. Browsers connect to it whenever an address starts with https:// and names no other port. **Is port 443 TCP or UDP?** Both. HTTPS over HTTP/1.1 and HTTP/2 uses TCP 443; HTTP/3 runs over QUIC on UDP 443, unless the server advertises another UDP port. IANA registers 443 to https on both. **How do I open port 443?** Allow inbound TCP 443, and UDP 443 if you serve HTTP/3, in the server's firewall and any cloud security group, then configure the web server to listen on 443 with a certificate. Test from another machine with nc or openssl s_client. **Is port 443 always secure?** No. The port number does not encrypt anything; TLS does. Port 443 carries HTTPS by convention, but a server could run anything on it, and an HTTPS site on 443 can still have an invalid certificate. **What is the difference between port 80 and 443?** Port 80 is the default for unencrypted HTTP and port 443 for HTTPS. A site on HTTPS keeps 80 open only to redirect visitors to HTTPS on 443. **What port does SMTP use for SSL?** Port 465 for implicit TLS, where the connection is encrypted from the start, and port 587 for STARTTLS, where it is upgraded after connecting. Both are for sending mail from a client; servers exchange mail on port 25, where TLS starts with STARTTLS. ## Related terms The protocol on top of the port is covered under [TLS](/tls/), and the browser messages that appear when it fails under [SSL errors](/errors/). The rest of the vocabulary is in [this glossary](/glossary/). ## Sources 1. IANA, Service Name and Transport Protocol Port Number Registry: https, http, ssh, submissions, submission, smtp, imaps, imap, pop3s, pop3, ldaps, ldap, domain-s, ftps, ftp. 2. IETF, RFC 9110, HTTP Semantics, §4.2.1 and §4.2.2; RFC 2818, HTTP Over TLS. 3. IETF, RFC 9113, HTTP/2, §3. 4. IETF, RFC 9114, HTTP/3, §3.1; RFC 9000, QUIC. 5. IETF, RFC 8314, Use of TLS for Email Submission and Access; [RFC 6409](https://www.rfc-editor.org/rfc/rfc6409), Message Submission for Mail; [RFC 3207](https://www.rfc-editor.org/rfc/rfc3207), SMTP Service Extension for Secure SMTP over TLS. 6. IETF, [RFC 4513](https://www.rfc-editor.org/rfc/rfc4513), LDAP Authentication Methods and Security Mechanisms (StartTLS); [RFC 4217](https://www.rfc-editor.org/rfc/rfc4217), Securing FTP with TLS (AUTH TLS); [RFC 7858](https://www.rfc-editor.org/rfc/rfc7858), DNS over TLS. 7. IETF, RFC 6797, HTTP Strict Transport Security, §8.3. 8. OpenSSL, openssl-s_client manual page, option -starttls. 9. Chromium, net/base/net_error_list.h (SSL_PROTOCOL_ERROR); OpenSSL, crypto/err/openssl.txt (wrong version number); Mozilla NSS, lib/ssl/SSLerrs.h (SSL_ERROR_RX_RECORD_TOO_LONG); a plain HTTP server contacted with OpenSSL 3.0, Chrome and Firefox in our test setup. --- https://bridge-ssl.com/glossary/certificate-pinning/ --- # What is certificate pinning? How it works and why it breaks Certificate pinning is a technique in which an app accepts only a specific certificate or public key for a server, instead of any certificate a trusted authority has issued for that name. It protects against a wrongly issued certificate being used to intercept traffic. It also makes the app fail whenever the server's certificate changes in a way the pin did not anticipate, which, with certificates now replaced every few months, is its main practical problem. It is part of the [glossary](/glossary/). ## Quick facts | | | |---|---| | Used in | mobile and desktop apps, API clients, devices | | Not used in | browsers for ordinary websites; the browser mechanism, HPKP, was removed | | What is pinned | the certificate, its public key, or an issuing authority's key | | Main risk | the app stops connecting after the server's certificate is replaced | | Platform support | Android Network Security Config; `NSPinnedDomains` on Apple platforms | ## How certificate pinning works Normally a client accepts a server's certificate if it chains to a root in the client's trust store and covers the hostname. Any of the many trusted authorities could issue such a certificate. See [certificate chains](/certificates/chain/). Pinning adds one more check. The app carries a fingerprint, the pin, of a key or certificate it expects. After the normal checks pass, the app compares what the server presented with the pin. If nothing in the chain matches, the app refuses the connection, even though the certificate is otherwise valid. The pin is fixed when the app is built or configured. Changing it requires an app update or a configuration change on every installed copy. SSH clients keep a similar record by default: they store a server's host key in `known_hosts` on first connection and warn if it ever changes, as described in [the comparison of SSL and SSH](/glossary/ssl-vs-ssh/). ## What can be pinned | Pin | Survives renewal? | Trade-off | |---|---|---| | The server's certificate | no; every renewal produces a new certificate | the narrowest pin and the most fragile | | The server's public key | yes, if the new certificate reuses the key | breaks when the key is rotated | | An intermediate authority's key | yes, while the authority issues from that intermediate | breaks when the authority switches intermediates | | A root authority's key | usually | protects only against authorities other than the chosen one | Pinning the public key rather than the certificate is the usual recommendation, because a certificate can be renewed with the same key. The pin is a hash of the key's SubjectPublicKeyInfo, usually SHA-256 in base64; SubjectPublicKeyInfo is the field of an [X.509 certificate](/glossary/x509/) that holds the public key and its algorithm. ## Why pinning breaks The trouble with pinning is operational. A pin records what the server presents today, and the server's certificate changes on someone else's schedule. The protocol version plays no part in this: a certificate carries none, which is why an SSL certificate and a TLS certificate are the same thing; see [how SSL and TLS differ](/glossary/ssl-vs-tls/). **Certificates are replaced more often.** The CA/Browser Forum [ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/) lowers the maximum lifetime of public certificates to 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. A certificate pin then breaks several times a year. See [renewal](/certificates/renewal/). **Keys and intermediates change too.** Automated clients often generate a new key at each renewal. Authorities rotate their intermediates, and some issue from several intermediates at once, so two consecutive certificates for the same site can chain through different ones. **The app cannot be fixed quickly.** When a pin breaks, every installed copy of the app fails until users install an update. Users who do not update stay broken. That is why pinning to the leaf certificate is now rarely defensible for public services, and why pins should always come with a backup. ## Pinning in browsers: HPKP Browsers once let websites set pins with an HTTP header, HTTP Public Key Pinning, defined in [RFC 7469](https://www.rfc-editor.org/rfc/rfc7469). A wrong pin could lock visitors out of a site for as long as the header said, and an attacker who briefly controlled a site could pin it to keys the owner did not have. Browsers removed HPKP. [Certificate Transparency](/glossary/certificate-transparency/) took over its purpose: wrongly issued certificates are found in public logs instead of being blocked by pins. Websites today have no pinning mechanism in browsers, and none is needed. The [HSTS security header](/glossary/hsts/), a different mechanism, still tells browsers to reach a site only over HTTPS, but it has never restricted which certificates they accept. ## If you pin in an app When an app talks to an API you control and the threat justifies it, pinning can be done with less risk: - **Pin keys, not certificates,** and pin at least two: the current key and a backup key kept offline, or keys of two authorities you could switch to. - **Use the platform's configuration rather than custom code.** Android's [Network Security Config](https://developer.android.com/privacy-and-security/security-config) supports a pin set with an expiry date, after which pinning stops instead of breaking the app. Apple platforms provide `NSPinnedDomains` in the app's settings. - **Plan rotation before release.** Write down who changes the server's key or authority, and how the app learns the new pin before the old one is retired. - **Keep a way out.** An expiry date on the pins, or a remotely updated pin list, prevents a permanent outage for users who never update. The [OWASP Pinning Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html) covers the implementation details per platform. For most apps, the alternative is better: rely on the platform's trust store, require Certificate Transparency, and keep the server's certificate valid. Pinning protects against a rare threat by adding a common failure. ## Pinning and interception tools Corporate proxies and debugging tools read encrypted traffic by presenting their own certificate, issued by a root installed on the device. An app with pins refuses those connections, which is why some apps fail on networks that inspect traffic. That is pinning working as designed. The same mechanism explains failures behind [unable to get local issuer certificate](/errors/unable-to-get-local-issuer-certificate/) in tools that do not pin but do not trust the proxy's root. ## FAQ **What is certificate pinning?** A rule in an app that accepts only a specific certificate or public key for a server. A certificate that is valid but does not match the pin is refused. **Is certificate pinning still recommended?** For browsers, no; HPKP was removed. For apps, only where the threat justifies it, with public-key pins, a backup pin and a plan for rotation. Many apps are better served by Certificate Transparency and the system trust store. **What is the difference between certificate pinning and public key pinning?** A certificate pin matches one certificate and breaks at every renewal. A public key pin matches the key inside it and survives renewals that keep the same key. **Why did my app stop working after the SSL certificate was renewed?** The app probably pins the old certificate or key. The new certificate does not match, so the app refuses it until the app is updated with the new pin. **What was HPKP?** HTTP Public Key Pinning, a header that let websites pin keys in browsers. It was removed from browsers because mistakes could lock visitors out of a site, and Certificate Transparency replaced its purpose. **Does certificate pinning stop man-in-the-middle attacks?** It stops attacks that use a certificate from another authority, including one issued by mistake or a proxy's own root. It does not help if the attacker has the server's private key. --- https://bridge-ssl.com/glossary/x509/ --- # What is an X.509 certificate? Fields, format and uses An X.509 certificate is a data structure that binds a public key to a subject, such as a domain name, and a certificate authority signs it to assert that binding [1]. The format comes from ITU-T Recommendation X.509 [2], and [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280) profiles it for the internet [1]. TLS requires X.509 version 3 for the certificates both sides send, unless the two ends negotiate another type ([RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) §4.4.2.2, §4.4.2.3) [3]. So an SSL/TLS certificate is an X.509 certificate: "X.509" names the format, "SSL certificate" names the use. This [SSL and TLS glossary](/glossary/) entry covers the fields, the extensions TLS reads and Go's `x509:` errors. - **Current version** — version 3, stored as the value 2 [1] - **Encoding** — ASN.1, signed as DER [1]; files hold DER or PEM text - **Structure** — to-be-signed data, the signature algorithm, the signature value [1] - **Read with** — `openssl x509 -in cert.pem -noout -text` [7] ## What an X.509 certificate contains An X.509 certificate is one ASN.1 sequence of three parts: the to-be-signed certificate (`tbsCertificate`), the algorithm the issuer signed it with, and the signature value [1]. `openssl asn1parse` decodes the DER of this page's test certificate and shows them: ```text $ openssl asn1parse -in cert.pem -i 0:d=0 hl=4 l= 827 cons: SEQUENCE 4:d=1 hl=4 l= 736 cons: SEQUENCE 744:d=1 hl=2 l= 10 cons: SEQUENCE 756:d=1 hl=2 l= 73 prim: BIT STRING ``` The 736-byte sequence is the to-be-signed part, with these fields [1]: | Field | What it holds | |---|---| | Version | 3 (value 2) whenever extensions are present, §4.1.2.1 | | Serial number | a positive integer, unique among the certificates one CA issues, §4.1.2.2 | | Signature | the signature algorithm; must match the outer one, §4.1.1.2 | | Issuer | the name of the authority that signed it, §4.1.2.4 | | Validity | `notBefore` and `notAfter`: the dates between which it may be used (§6.1.3) and the CA keeps status information about it (§4.1.2.5) | | Subject | the name of the entity that holds the public key, §4.1.2.6 | | Subject public key info | the public key and its algorithm, such as RSA 2048 or ECDSA P-256 | | Extensions | names and usage rules, version 3 only, §4.2 | ### Versions 1, 2 and 3 X.509 version 3 extends version 2 with extensions. A certificate with only the basic fields should be version 1, and CAs that follow RFC 5280 must not use the unique identifiers versions 2 and 3 allow [1]. Signing the test request without extensions, OpenSSL 3.0.13 wrote `Version: 1 (0x0)`. ## The extensions that matter for TLS For names and usage, a TLS client reads the extensions listed below. Each extension in an X.509 version 3 certificate is marked critical or non-critical, and RFC 5280 sets the rule: a system that meets a critical extension it does not recognize must reject the certificate, and an unknown non-critical one may be ignored [1]. - **Subject Alternative Name.** The host names the certificate covers. Under [RFC 9525](https://www.rfc-editor.org/rfc/rfc9525), a server's identity can only be expressed in this extension, and the subject's common name is not used [4]. See [Subject Alternative Names](/certificates/san/). - **Basic Constraints.** Whether the certified public key may verify signatures on other certificates. A website certificate has `CA:FALSE`; a CA certificate whose key signs certificates has `CA:TRUE`, with the extension marked critical [1]. - **Key Usage and Extended Key Usage.** What the key may do. A website certificate carries `TLS Web Server Authentication`, the `serverAuth` purpose; a client certificate for [mutual TLS](/glossary/mtls/) carries `TLS Web Client Authentication` [1]. ### Issuer, revocation and log extensions The other X.509 extensions point a client to the issuing certificate authority, its revocation list and public logs: - **Authority Information Access.** Where to download the issuer's certificate, as a single certificate in DER or a certs-only CMS bundle, and, if offered, the [OCSP responder](/glossary/ocsp-stapling/)'s address (RFC 5280 §4.2.2.1) [1]. - **CRL Distribution Points.** Where the issuer publishes its revocation list. CRLs list revoked certificates by serial number [1]. See revocation. - **Subject and Authority Key Identifiers.** Identify this certificate's key and the key that signed it, to make building the certification path easier [1]. - **Signed Certificate Timestamps.** A log's signed promise to add the certificate to its public record, stored under OID 1.3.6.1.4.1.11129.2.4.2 ([RFC 6962](https://www.rfc-editor.org/rfc/rfc6962) §3, §3.3) [5]; see [Certificate Transparency](/glossary/certificate-transparency/). ### Critical and non-critical: a test The test leaf was signed twice with an unknown extension under a private OID, once critical and once not. Here is what OpenSSL 3.0.13 and Go 1.27.2 did with each certificate: | Unknown extension | `openssl verify` | Go `crypto/x509` | |---|---|---| | marked critical | `error 34 … unhandled critical extension` | `x509: unhandled critical extension` | | not critical | `OK` | verified | ## How to read an X.509 certificate `openssl x509 -text` prints every field [7]. Shortened output for the test certificate: ```text $ openssl x509 -in cert.pem -noout -text Certificate: Data: Version: 3 (0x2) Signature Algorithm: ecdsa-with-SHA256 Issuer: CN = Example Test Intermediate Validity ... Subject: CN = example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) X509v3 extensions: X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com ... Signature Algorithm: ecdsa-with-SHA256 ``` The two algorithms belong to different keys. `rsaEncryption` is the subject's own key. `ecdsa-with-SHA256` is how the intermediate signed, and it appears twice because RFC 5280 requires the copy inside the signed data to match the one outside [1]. Printing single fields, reading a live server with `openssl s_client` and checking expiry are on [OpenSSL commands](/certificates/openssl-commands/). ## Why one changed byte breaks the certificate The issuer signs the DER encoding of the whole to-be-signed part [1], so editing any field invalidates the signature. In the test, one letter of `www.example.com` in the DER file was changed, and this is what OpenSSL then read and said: ```text $ openssl x509 -inform der -in tampered.der -noout -ext subjectAltName X509v3 Subject Alternative Name: DNS:example.com, DNS:www.xxample.com $ openssl verify -CAfile root.pem -untrusted int.pem tampered.der error 7 at 0 depth lookup: certificate signature failure ``` This is why an expiring certificate cannot be extended and has to be replaced; see renewal. [Certificate pins](/glossary/certificate-pinning/) on a public key hash the DER of the subject public key info ([RFC 7469](https://www.rfc-editor.org/rfc/rfc7469) §2.4) [6], so a new certificate for the same key keeps the pin valid. ## File formats: PEM, DER and others X.509 defines the content, not the file. A certificate is saved as DER, the binary encoding, or as PEM, the DER bytes in base64 between `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` lines; PEM's labels and line rules have their own glossary entry. File extensions such as `.crt`, `.cer` and `.pem` do not reliably tell you which encoding a file uses. PFX (PKCS#12) and P7B (PKCS#7) bundle X.509 certificates, PFX together with the private key. Telling them apart and converting is on [certificate formats](/certificates/formats/). ## Where X.509 certificates are used The key purposes RFC 5280 defines for Extended Key Usage name the jobs: TLS server authentication, TLS client authentication, code signing, email protection, time stamping and OCSP signing [1]. - **HTTPS and TLS.** The server sends its X.509 certificate during the TLS handshake [3], and the client checks the chain, dates and names. - **Client authentication.** In mutual TLS the client sends a certificate too, under the same X.509v3 rule [3]. - **Email.** S/MIME agents process X.509 certificates and validate them as RFC 5280 describes ([RFC 8550](https://www.rfc-editor.org/rfc/rfc8550)) [9]. - **VPNs.** IKEv2 carries DER-encoded X.509 certificates in its Certificate payload ([RFC 7296](https://www.rfc-editor.org/rfc/rfc7296) §3.6) [9]. The format is the same in each case; the extensions and the trust store that checks them differ. Path validation starts from a trust anchor, such as the top CA of a hierarchy [1]; on the web those are [root certificates](/certificates/root-certificate/). SSH is the exception. Servers are identified by host keys ([RFC 4251](https://www.rfc-editor.org/rfc/rfc4251) §4.1), and OpenSSH certificates are, in its manual's words, "a different, and much simpler, format to the X.509 certificates" [10]; see [SSL vs SSH](/glossary/ssl-vs-ssh/). ## X.509 errors in Go programs Messages that begin with `x509:` come from Go's `crypto/x509` package; when TLS fails, Go's `crypto/tls` puts `tls: failed to verify certificate:` in front of them [8]. Docker Engine, Kubernetes and Terraform are written in Go [11]; when they verify a certificate with Go's standard library, these are the texts they print. Each row was reproduced with Go 1.27.2 on the test chain: | Message | What failed | Test case | |---|---|---| | `x509: certificate signed by unknown authority` | no path to a trusted root; causes and fixes as for [unable to get local issuer certificate](/errors/unable-to-get-local-issuer-certificate/) | intermediate not supplied; root not in the pool | | `x509: certificate has expired or is not yet valid: …` | the date check; the browser equivalent is [ERR_CERT_DATE_INVALID](/errors/err-cert-date-invalid/) | clock set after `notAfter` | | `x509: certificate is valid for example.com, www.example.com, not b.example.com` | the requested name is not in the Subject Alternative Name list | host `b.example.com` | | `x509: certificate relies on legacy Common Name field, use SANs instead` | the name is only in the subject's common name, with no SAN extension | leaf without SAN | | `x509: unhandled critical extension` | a critical extension Go does not know | private OID marked critical | ## FAQ ### What is an X.509 certificate? A data structure in the X.509 format that binds a public key to a name, such as a domain name, signed by a certificate authority. SSL/TLS certificates are X.509 certificates. ### Is an SSL certificate an X.509 certificate? Yes. TLS requires X.509 version 3 unless both sides negotiate another type. "SSL certificate" describes the use; X.509 describes the structure. [3] ### What is the difference between X.509 and PEM? X.509 is the certificate's structure. PEM is one way to store it in a file: the DER encoding in base64 text between BEGIN and END lines. ### What does "x509: certificate signed by unknown authority" mean? A Go program could not link the server's certificate to a root it trusts. In the test above, it appeared both when the intermediate was missing and when the root was not trusted. ### What is the latest version of X.509? Version 3, the newest of the three RFC 5280 defines; the version field holds 2. It added extensions, including Subject Alternative Name, which TLS relies on. [1] ## Sources 1. RFC 5280, X.509 certificate and CRL profile: §3.1, §4.1, §4.2, §5.1.2.6, §6. 2. [ITU-T Recommendation X.509](https://www.itu.int/rec/T-REC-X.509), Public-key and attribute certificate frameworks. 3. RFC 8446, TLS 1.3: §4.4.2, §4.4.2.2, §4.4.2.3. 4. RFC 9525, Service Identity in TLS: §2, Appendix A. 5. RFC 6962, Certificate Transparency: §3, §3.3. 6. RFC 7469, Public Key Pinning: §2.4. 7. [OpenSSL 3.0 manual: openssl-x509](https://docs.openssl.org/3.0/man1/openssl-x509/), option `-text`; openssl-asn1parse; X509_STORE_CTX_get_error (errors 7 and 34). 8. [Go 1.27.2 source, crypto/x509/verify.go](https://github.com/golang/go/blob/go1.27.2/src/crypto/x509/verify.go); crypto/x509/x509.go; crypto/tls/common.go. 9. RFC 8550, S/MIME 4.0 Certificate Handling: Abstract; RFC 7296, IKEv2: §3.6. 10. RFC 4251, SSH architecture: §4.1; ssh-keygen(1) manual, Certificates. 11. go.mod of moby/moby, kubernetes/kubernetes, hashicorp/terraform. --- https://bridge-ssl.com/glossary/ssl-vs-ssh/ --- # SSL vs SSH: what is the difference? SSL, today TLS, and SSH both encrypt connections, but they protect different things. TLS secures connections between programs, above all browsers and websites, and proves the server's identity with a certificate issued by an authority. SSH gives an administrator a secure remote shell and file transfer, and identifies servers by keys that users accept on first connection. They are not competing choices for the same job. This page compares them and shows where each is used. It is part of the [glossary](/glossary/). ## At a glance | | SSL/TLS | SSH | |---|---|---| | Main use | HTTPS, mail, APIs, any program-to-program connection | remote command line, file transfer, tunnels | | Default port | 443 for HTTPS | 22 | | Server identity | X.509 certificate signed by a trusted authority | host key, accepted on first connection and remembered | | Client identity | usually none; optional client certificates | password or key pair, required | | Standards | TLS 1.3 in [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) | SSH-2 in [RFC 4251](https://www.rfc-editor.org/rfc/rfc4251) to RFC 4254 | ## What they have in common Both set up an encrypted channel the same way at heart. The two sides agree on algorithms, derive shared keys with a Diffie-Hellman exchange, authenticate the server, and then encrypt and integrity-protect every message with a symmetric cipher such as AES-GCM or ChaCha20-Poly1305. Both have dropped old algorithms over the years, and both protect against eavesdropping and tampering on the network. "SSL" itself is retired: every SSL version is deprecated and what runs today is TLS. The name survives in everyday use, as on [SSL vs TLS](/glossary/ssl-vs-tls/). ## How they verify the server This is the real difference, and it decides where each fits. **TLS uses certificate authorities.** A server presents an [X.509 certificate](/glossary/x509/) that a certificate authority signed after checking that the requester controls the name. The client trusts it because the chain ends at a [root certificate](/certificates/root-certificate/) in its trust store. A browser can therefore safely connect to a site it has never seen, which is what the web needs. **SSH usually trusts on first use.** The first time you connect, SSH shows the server's key fingerprint and asks whether to accept it. If you do, the key is stored in `known_hosts`, and SSH warns loudly if it ever changes. This works for a small set of servers an administrator knows; it would not work for millions of websites visited once. Large organisations can add SSH certificates signed by their own SSH authority, a separate format from X.509. Authorities are watched in public as well: [certificate transparency](/glossary/certificate-transparency/) records the certificates they issue in public logs, so one issued for your domain without your request can be found. Some apps go further with [certificate pinning](/glossary/certificate-pinning/), accepting only a specific certificate or key for a server, which is close to how SSH treats a host key it has remembered. ## How they verify the user TLS on the web usually identifies only the server; the website then signs users in with its own login. Mutual TLS adds a client certificate where a system must identify the client too; see [mTLS](/glossary/mtls/). SSH always identifies the user, by password or, preferably, by a key pair whose public half is stored on the server in `authorized_keys`. ## Where each is used **TLS:** HTTPS websites and APIs, mail between clients and servers and between servers, database connections, VPNs built on TLS, and DNS over TLS. The ports differ by protocol, as on [port 443](/glossary/port-443/). **SSH:** logging in to servers and network devices, running commands remotely, copying files with SCP or SFTP, Git over SSH, and tunnels that forward other traffic through an SSH connection. **SFTP and FTPS** are a common point of confusion. SFTP is file transfer over SSH, usually on port 22. FTPS is the old FTP protocol wrapped in TLS, on ports 990 or 21. They are different protocols that solve the same problem. ## Which to use Choose by the job, not by the encryption. - **Serving a website or an API:** TLS. Browsers and clients only speak HTTPS, and they need a certificate from a trusted authority. - **Administering a server:** SSH, with key-based login and password login turned off. - **Transferring files:** SFTP for administrators and automated jobs between systems you control; HTTPS uploads for anything public-facing. Running both on one server is normal: HTTPS on 443 for visitors, SSH on 22 for the people who maintain it. ## FAQ **What is the difference between SSL and SSH?** SSL, now TLS, secures connections between programs such as browsers and websites and verifies servers with certificates from trusted authorities. SSH secures remote logins and file transfers and verifies servers with keys accepted on first connection. **Is SSH more secure than SSL?** Neither is generally more secure; both use the same kinds of modern cryptography. They differ in how they establish trust. TLS relies on certificate authorities, SSH on keys the user accepts and remembers. **Does SSH use SSL certificates?** No. SSH uses its own host keys and, optionally, SSH certificates in a format different from X.509. TLS certificates are not used by SSH. **What port does SSH use, and what port does SSL use?** SSH uses port 22 by default. HTTPS, the most common use of SSL/TLS, uses port 443; other TLS protocols have their own ports, such as 465 and 993 for mail. **Is SFTP the same as FTPS?** No. SFTP is file transfer over SSH. FTPS is FTP over TLS. Both encrypt the transfer, but they are different protocols on different ports. **Can I use SSH instead of HTTPS for a website?** No. Browsers do not speak SSH. A website needs HTTPS, which means TLS and a certificate from a trusted authority. --- https://bridge-ssl.com/glossary/pem/ --- # What is a PEM file? Format, labels and line rules A PEM file is a text file that holds a certificate, a key or a signing request as base64 between a `-----BEGIN` line and an `-----END` line. [RFC 7468](https://www.rfc-editor.org/rfc/rfc7468) defines this textual encoding and traces it, name included, back to Privacy-Enhanced Mail, the email standard of [RFC 1421](https://www.rfc-editor.org/rfc/rfc1421) [1]. This [SSL and TLS glossary](/glossary/) entry covers what a PEM block contains, what its label means and when a parser accepts the text. - **Block** — a `-----BEGIN label-----` line, base64 lines, an `-----END label-----` line with the same label [1] - **Inside** — one binary ASN.1 structure per block, DER preferred: a certificate, key, request or revocation list [1] - **Line length** — 64 characters per line when written, the last line up to 64 [1] - **Size** — every 3 bytes of binary become 4 base64 characters ([RFC 4648](https://www.rfc-editor.org/rfc/rfc4648) §4) [2] - **File names** — `.crt` and, from many tools, `.cer` [1], as well as `.pem`; the extension is a convention, not the format ## What one PEM block contains A PEM block has three parts. RFC 7468 calls the first and the last encapsulation boundaries and is exact about both [1]. 1. **The opening line**, or pre-encapsulation boundary: exactly five hyphens, `BEGIN`, one space, the label, five more hyphens. 2. **The body**: the binary structure in base64, using the letters A to Z and a to z, the digits, `+` and `/`, with `=` as padding [2]. 3. **The closing line**: the same pattern with `END` and the same label. ``` -----BEGIN CERTIFICATE----- MIICcjCCAhigAwIBAgIUIjtcM7f5O3z6sHIpiCpBPfDNuJEwCgYIKoZIzj0EAwIw JDEiMCAGA1UEAwwZRXhhbXBsZSBUZXN0IEludGVybWVkaWF0ZTAeFw0yNjEwMTUx ... -----END CERTIFICATE----- ``` The text adds nothing to the certificate. Decode the body and you get the certificate's DER bytes; the 630-byte test certificate behind this example becomes 840 base64 characters. The old mail format allowed header lines inside the block. RFC 7468 does not: between the boundaries there is only base64 [1]. ## PEM labels and what they mean The label names the structure, so a PEM-format file tells you what it holds before you decode anything [1]. | Label | What the block holds | RFC 7468 | |---|---|---| | `CERTIFICATE` | an X.509 certificate | §5 | | `CERTIFICATE REQUEST` | a PKCS #10 certification request (CSR) | §7 | | `X509 CRL` | a certificate revocation list | §6 | | `PRIVATE KEY` | an unencrypted PKCS #8 private key | §10 | | `ENCRYPTED PRIVATE KEY` | a password-encrypted PKCS #8 private key | §11 | | `PUBLIC KEY` | a public key with its algorithm (SubjectPublicKeyInfo) | §13 | | `PKCS7`, `CMS` | signed or enveloped messages, including bundles of certificates | §8, §9 | Older labels still turn up in a PEM file. `X509 CERTIFICATE` is one that conforming software must no longer write, and `NEW CERTIFICATE REQUEST` is one that parsers may treat as `CERTIFICATE REQUEST` [1]. `RSA PRIVATE KEY` and `EC PRIVATE KEY` are not in RFC 7468 at all: they are OpenSSL's older "traditional" key format, covered under private keys below [3][5]. ## One file, several blocks A PEM file may contain more than one block, and RFC 7468 leaves the order to the context of use [1]. That is how a server certificate and its intermediate travel together as a certificate chain in one `fullchain.pem`. The order such a file needs is covered on the certificate formats page of the certificates section. Counting blocks is a text search. Reading them is where commands differ. In this test on OpenSSL 3.0.13, with a chain made for this page, `openssl x509` decoded only the first certificate and `openssl storeutl` listed both: ``` $ grep -c 'BEGIN CERTIFICATE' fullchain.pem 2 $ openssl x509 -in fullchain.pem -noout -subject subject=CN = example.com $ openssl storeutl -noout -certs fullchain.pem 0: Certificate 1: Certificate Total found: 2 ``` A certificate and its key can also share a file. OpenSSL's PEM readers skip blocks of a type they are not looking for [3]. A [client authentication certificate](/glossary/mtls/) for mutual TLS is passed to `openssl s_client` as files: the certificate with `-cert`, its key with `-key`, extra chain certificates with `-cert_chain` [6]. ## Line rules, and what a parser accepts Software that writes PEM must break the base64 into lines of exactly 64 characters and add no stray whitespace; software that reads it may accept other line lengths, must cope with different newline conventions and must not fail on text placed before the opening line [1]. RFC 7468 also records that extant parsers "diverge considerably" on whitespace. A file that one program reads can be refused by another. What OpenSSL 3.0.13 did with altered copies of the same PEM certificate: | Change to the file | Result | |---|---| | base64 rewrapped to 128-character lines | read; same fingerprint | | a `Subject:` line of text before `-----BEGIN` | read; same fingerprint | | Windows line endings (CRLF) | read; same fingerprint | | `END` line with a different label | refused: `Could not read certificate` | | four hyphens instead of five on the `END` line | refused: `Could not read certificate` | So when a pasted certificate is rejected, look at the two boundary lines first: in this test, one missing hyphen was enough for OpenSSL to refuse the file. ## The same certificate in different text PEM text is not canonical. Two files can differ in line length, line endings and explanatory text and still hold the same certificate; RFC 7468 says canonical comparison means decoding to DER, and that hashes for identification are computed over DER [1]. `openssl x509 -fingerprint` does exactly that: it digests the DER encoding of the whole certificate [4]. ``` $ openssl x509 -in cert.pem -noout -fingerprint -sha256 sha256 Fingerprint=9A:D5:D2:6D:C1:E3:6C:6C:... $ openssl x509 -in cert.pem -outform der -out cert.der $ openssl dgst -sha256 cert.der SHA2-256(cert.der)= 9ad5d26dc1e36c6c... ``` The rewrapped copy from the table above gives the same value. Compare two PEM certificates by fingerprint, never with `diff`. Pins work on decoded data too. An app [pinning a certificate](/glossary/certificate-pinning/) compares a hash of the certificate or of its public key, computed over the decoded structure, so rewrapping or re-saving the PEM file does not break the pin. ## Private keys in PEM OpenSSL reads private keys in PKCS #8 and in its older traditional format, encrypted or not [3]. In a PEM file that shows up as labels such as these: - **`PRIVATE KEY`** is PKCS #8, the standard form under RFC 7468 §10. `openssl pkey` writes it by default [5]. - **`ENCRYPTED PRIVATE KEY`** is PKCS #8 protected by a password [1]. - **`RSA PRIVATE KEY`** and **`EC PRIVATE KEY`** are traditional forms of RSA and EC keys, written with `-traditional`. OpenSSL's documentation reserves the traditional format for "compatibility with legacy programs" [3][5]. An encrypted traditional key still carries header lines inside the block, which RFC 7468 does not allow [1]: ``` -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,... ``` OpenSSL describes this encryption as a non-standard technique [3]. Converting is one command, `openssl pkey -in old.key -out new.key`, which writes `PRIVATE KEY` [5]. On an encrypted key that output is unencrypted; add a cipher such as `-aes-256-cbc` to get `ENCRYPTED PRIVATE KEY` instead [5]. Base64 is an encoding, not protection: anyone who can read an unencrypted `PRIVATE KEY` block in a PEM file has the key. ## Where PEM fits among formats PEM and DER carry the same structure, one as base64 text and one as binary. Bundles such as PKCS #12 are separate containers, and converting between all of them is on the certificate formats page; reading a certificate's fields is on the OpenSSL commands page and the X.509 entry. Extensions do not settle the question. RFC 7468 asks for `.crt` on PEM certificates and notes that many tools write PEM with `.cer` [1], although the [RFC 2585](https://www.rfc-editor.org/rfc/rfc2585) registration says a `.cer` file holds exactly one DER certificate [7]. Open the file: text with a `-----BEGIN` line is PEM. Bridge SSL is the certificate layer of Bridge CDN. TLS is terminated at the edge, so there is no certificate file on your machine and no chain to assemble, and Bridge SSL has no certificate upload. ## FAQ **What does PEM stand for?** Privacy-Enhanced Mail. RFC 7468 traces the text format back to that email standard, RFC 1421, and now defines it for certificates, keys and requests. **Is a .crt file the same as a .pem file?** It can be. A `.crt` file can hold a PEM certificate or a binary DER one. The name proves nothing; a `-----BEGIN` line in the text does. **Can one PEM file hold a certificate and its private key?** Yes. A PEM file can carry blocks of different types one after another, and OpenSSL picks the block type it needs [3]. Protect such a file as you would protect the key alone. **How do I see what a PEM file contains?** List the labels with `grep -- '-----BEGIN' file.pem`. To decode every certificate in the file, run `openssl storeutl -noout -text -certs file.pem` [6]. ## Sources 1. RFC 7468, Textual Encodings of PKIX, PKCS, and CMS Structures: §1, §2, §4, §5.1–§5.3, §6–§11, §13, §14, Appendix B. 2. RFC 4648, The Base16, Base32, and Base64 Data Encodings, §4. 3. [OpenSSL 3.0 manual: PEM_read_bio_PrivateKey](https://docs.openssl.org/3.0/man3/PEM_read_bio_PrivateKey/), Description, Notes, PEM encryption format. 4. [OpenSSL 3.0 manual: openssl-x509](https://docs.openssl.org/3.0/man1/openssl-x509/), option `-fingerprint`. 5. [OpenSSL 3.0 manual: openssl-pkey](https://docs.openssl.org/3.0/man1/openssl-pkey/), option `-traditional`. 6. OpenSSL 3.0 manual: openssl-s_client (`-cert`, `-key`, `-cert_chain`) and openssl-storeutl (`-certs`, `-text`). 7. RFC 2585, Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP. --- https://bridge-ssl.com/glossary/public-key-cryptography/ --- # What is public key cryptography? Key pairs in TLS Public key cryptography, also called asymmetric cryptography, uses a pair of keys, one public and one private, and a different key of the pair for each of two counterpart operations: encryption and decryption, or creating a signature and verifying it [1]. In SSL and TLS the certificate publishes the public key, and in TLS 1.3 the server uses the private key to sign, not to decrypt [2]. It is part of the [SSL and TLS glossary](/glossary/). - **Also called** — asymmetric cryptography, the term [RFC 4949](https://www.rfc-editor.org/rfc/rfc4949) defines [1] - **Key pair** — a private key known only to its owner and a public key that can be shared [1] - **Used for** — encryption, digital signatures and key agreement [1] - **Certificate key in TLS 1.3** — signs the handshake in the CertificateVerify message [2] - **Public TLS certificates** — RSA with a modulus of at least 2048 bits, or ECDSA on P-256, P-384 or P-521 [8] ## A key pair: one key kept, one given away A key pair is two keys generated together. The private key does not have to be known by anyone but its owner, and the public key can be handed to anybody who uses the algorithm, with no need to keep it secret [1]. In a test with OpenSSL 3.0.13 one command made the pair and a second wrote out the public half: ``` $ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out rsa.key $ openssl pkey -in rsa.key -pubout -out rsa.pub $ head -1 rsa.key; head -1 rsa.pub -----BEGIN PRIVATE KEY----- -----BEGIN PUBLIC KEY----- ``` The private key file is the one to protect. The public key is what goes into a certificate: the Subject Public Key Info field carries the key and names the algorithm it is used with [4]. The private key is never part of the certificate. Both files above are PEM text, which has its own entry in this glossary, and the certificate fields around the key are covered under X.509. ## Signing and verifying A signature is made with the private key and checked with the public key. Digital signatures detect unauthorized changes to data and authenticate the identity of the signatory [7], and anyone who has the public key can run the check. In the test, an RSA signature over a short message verified: ``` $ openssl dgst -sha256 -sigopt rsa_padding_mode:pss -sign rsa.key -out msg.rsa.sig msg.txt $ openssl dgst -sha256 -sigopt rsa_padding_mode:pss -verify rsa.pub -signature msg.rsa.sig msg.txt Verified OK ``` Changing "Pay 100" to "Pay 900" in the message gave `Verification failure`. So did checking the original message against the public key of a second, unrelated pair. Signing is not the private key "encrypting" the message. [RFC 8017](https://www.rfc-editor.org/rfc/rfc8017) defines RSA signature schemes (RSASSA-PSS, RSASSA-PKCS1-v1_5) apart from its encryption schemes (RSAES-OAEP, RSAES-PKCS1-v1_5), and calls it good practice to use one RSA key pair in only one scheme [5]. ECDSA and EdDSA are signature algorithms [2][6]. With a P-256 key and with an Ed25519 key, `openssl pkeyutl -encrypt` stopped at `Error initializing context`. ## Encryption and key exchange In an encryption scheme, anyone encrypts with the recipient's public key and only the matching private key decrypts [1]; RFC 8017 names delivering key material to another party as a typical use [5]. In the test, a short secret encrypted to `rsa.pub` with OAEP came back intact from `rsa.key`. The private key of the second pair returned `Public Key operation error`. TLS 1.2 could work that way. With RSA key exchange the client generates a premaster secret, encrypts it with the public key from the server's certificate and sends the result ([RFC 5246](https://www.rfc-editor.org/rfc/rfc5246) §7.4.7.1) [3]. In TLS 1.3, defined in [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446), static RSA and Diffie-Hellman cipher suites have been removed. Its key exchange is (EC)DHE, a pre-shared key, or both, and every public-key based exchange in it provides forward secrecy [2]. (EC)DHE is key agreement rather than encryption. Each side sends a key share, then uses its own private key and the other side's public key to compute the same secret [1][2]. Nothing is encrypted to the certificate's key. The message order is on the TLS handshake page, and what the change protects is on the forward secrecy page. ## What each key does in a TLS 1.3 connection The keys in a TLS 1.3 connection fall into two groups: the keys tied to certificates, where private keys sign and the public keys from certificates check those signatures, and the rest, which establish and protect the traffic. | Key | Held by | Job | |---|---|---| | Server certificate's private key | the server | signs CertificateVerify, explicit proof that the server possesses the private key matching its certificate [2] | | Server certificate's public key | the certificate, sent to every client | lets the client check that signature [2] | | Issuing authority's private key | the certificate authority | signed the certificate, certifying the binding between the public key and the subject [4] | | Issuing authority's public key | the issuer's certificate | lets the client check the certificate's signature [4] | | Key shares | client and server, sent in ClientHello and ServerHello | establish shared keying material [2] | | Traffic keys | client and server | protect application data once the handshake is complete [2] | Explanations of HTTPS in which the browser encrypts a session key with the server's public key describe RSA key exchange in TLS 1.2 [3]. In TLS 1.3 the certificate's key only signs [2]. ## Which keys a public certificate can carry A publicly trusted TLS certificate can carry only an RSA key whose modulus is at least 2048 bits and divisible by 8, or an ECDSA key on NIST P-256, P-384 or P-521. The CA/Browser Forum Baseline Requirements §6.1.5 permit no other algorithms or key sizes [8]. | Algorithm | Signature | Encryption | Public TLS certificates (BR §6.1.5) | Test, OpenSSL 3.0.13 | |---|---|---|---|---| | RSA | RSASSA-PSS, RSASSA-PKCS1-v1_5 [5] | RSAES-OAEP, RSAES-PKCS1-v1_5 [5] | modulus at least 2048 bits, divisible by 8 | 256-byte signature with a 2048-bit key; OAEP round trip | | ECDSA | yes [2] | none: a signature algorithm [2] | P-256, P-384, P-521 | verified; encryption refused | | Ed25519 | yes, 64-octet signatures [6] | none: a signature scheme [6] | not permitted | 64-byte signature; encryption refused | TLS 1.3 lists ed25519 and ed448 among its signature algorithms [2], so the protocol can use them while public certificates cannot carry them under §6.1.5. An RSA key signs the TLS 1.3 handshake with RSASSA-PSS: the RSASSA-PKCS1-v1_5 values refer solely to signatures in certificates and are not defined for signed handshake messages [2]. ## Certificates tie a key to a name A certificate tells a client which public key belongs to which name. By signing it, the authority certifies the binding between the public key and the subject [4]. Apps that want a narrower check can carry the expected key themselves, which is [pinning a certificate or its public key](/glossary/certificate-pinning/). Any trusted authority can sign such a binding, and [transparency logs for issued certificates](/glossary/certificate-transparency/) are where an unexpected one for your name becomes visible. If the private key leaks, whoever holds it can produce the CertificateVerify signature and pass as the server [2]. The Baseline Requirements list key compromise as a reason to revoke the certificate (keyCompromise), and an authority must reject a new request for a key it has been told is compromised [8]. Recorded TLS 1.3 traffic stays protected: a signature key compromised after the handshake does not compromise the session key, as long as the session key itself has been erased [2]. ## Where the keys live on Bridge CDN On Bridge CDN the key pair behind the certificate belongs to the platform. Bridge SSL is the certificate layer of Bridge CDN, and it issues its own certificates because it owns the key. TLS is terminated at the edge, so there is no certificate file on your machine, and Bridge SSL has no certificate upload. Generating a private key and a signing request are steps of a traditional installation; here the one step is adding the domain. The certificate is presented by the layer that terminates TLS, so Bridge SSL cannot hold the key for a site served elsewhere. ## FAQ **What is public key cryptography?** Public key cryptography is cryptography with a key pair: a private key that its owner keeps and a public key anyone may have, each used for one side of an operation such as signing and verifying [1]. TLS uses it to prove the server's identity and to agree on keys [2]. **Is asymmetric cryptography the same as public key cryptography?** Yes. RFC 4949 defines asymmetric cryptography and gives "public-key cryptography" as its popular name [1]. **Does the server's public key encrypt my data in HTTPS?** Not in TLS 1.3. The certificate's key signs the handshake, and traffic is protected with keys both sides derive from the key exchange [2]. Encrypting a secret to the server's public key was RSA key exchange in TLS 1.2 [3], which TLS 1.3 removed. **What key size does an SSL certificate need?** A publicly trusted certificate needs an RSA key with a modulus of at least 2048 bits, or an ECDSA key on P-256, P-384 or P-521 [8]. ## Sources 1. RFC 4949, Internet Security Glossary, Version 2: §4, "asymmetric cryptography". 2. RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: §1.2, §2, §4.2.3, §4.4.3, Appendix E.1. 3. RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2: §7.4.7.1. 4. [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280), Internet X.509 Public Key Infrastructure Certificate and CRL Profile: §4.1.1.3, §4.1.2.7. 5. RFC 8017, PKCS #1: RSA Cryptography Specifications Version 2.2: §6, §7, §8. 6. [RFC 8032](https://www.rfc-editor.org/rfc/rfc8032), Edwards-Curve Digital Signature Algorithm (EdDSA): Abstract, §7. 7. [NIST FIPS 186-5, Digital Signature Standard (DSS)](https://csrc.nist.gov/pubs/fips/186-5/final), Abstract. 8. [CA/Browser Forum Baseline Requirements for TLS server certificates](https://cabforum.org/working-groups/server/baseline-requirements/requirements/): §4.9.1.1, §6.1.1.3, §6.1.5. --- https://bridge-ssl.com/glossary/ocsp-stapling/ --- # What is OCSP stapling? OCSP stapling is a TLS server handing the client a signed, recent answer to the question "has this certificate been revoked?" along with the certificate itself, so the client need not ask anyone else. Stapling is the `status_request` extension of [RFC 6066](https://www.rfc-editor.org/rfc/rfc6066) [2][4]. OCSP, the Online Certificate Status Protocol of [RFC 6960](https://www.rfc-editor.org/rfc/rfc6960), is how that question is asked: a client sends the issuing authority or a responder an identifier of the certificate and gets back a signed status [1]. Both share one entry in this [SSL and TLS glossary](/glossary/), since stapling changes only who asks. - **Status** — good, revoked or unknown [1] - **Signed by** — the issuing authority, a responder it designated, or one the client trusts [1] - **Must-staple** — a certificate extension that makes a staple expected, [RFC 7633](https://www.rfc-editor.org/rfc/rfc7633) [4] ## How it works Without stapling, a client that checks status asks the responder named in the certificate and holds off accepting the certificate until the answer arrives [1][6]. With stapling, the client puts `status_request` in its ClientHello, and a server that agrees fetches the answer itself and sends the complete OCSP response with its certificate [2]. In TLS 1.2 and earlier it is a separate CertificateStatus message; in TLS 1.3 it sits inside the certificate entry it describes ([RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) §4.4.2.1) [3]. RFC 6066 allows a single response [2]; [RFC 6961](https://www.rfc-editor.org/rfc/rfc6961) added an extension covering intermediates too [5], deprecated by RFC 8446 [3]. The server cannot write a favourable answer for itself, because the response is signed by the authority or a responder the client accepts [1]. Each response records when its status was known to be correct [1]. In a test for this page on OpenSSL 3.0.13, changing one digit of a saved response made verification fail: `Response Verify Failure`. ## Why it matters OCSP stapling removes a third-party connection from the TLS handshake, and RFC 7633 lists what that costs: privacy, performance and reliability [4]. - **Privacy.** The request identifies the certificate [1], so an OCSP responder asked by every visitor learns which site each one is checking. - **Performance.** RFC 6066 describes the extension as saving round trips and resources [2]. - **Reliability.** A client checking on its own waits for the responder [1], and RFC 7633 treats blocking the OCSP response as a denial of service against the client [4]. ## When the staple is missing or wrong A connection without a staple is not insecure for that reason alone. A server may skip it even after agreeing to send one [2], and a client cannot tell a server without the feature from one knowingly withholding status on an invalid certificate [4]. Must-staple closes that gap: with the TLS Feature extension set to `status_request`, a client can fail at once when no staple comes [4]. A wrong staple is worse than none. A client that finds the stapled response unsatisfactory must abort the handshake with a fatal alert [2]; browser error messages are sorted in the errors section. A staple also needs an authority that answers OCSP, which the CA/Browser Forum Baseline Requirements call an "optional OCSP capability" [6]. `openssl s_client -status` asks for status and prints any response [7]; on a test server for this page that staples: ``` $ openssl s_client -connect "$HOST" -status example.com.chained.crt ``` Omitting the intermediates produces the selective trust failure on [ERR_CERT_AUTHORITY_INVALID](/errors/err-cert-authority-invalid/), which works for whoever installed it and fails for fresh visitors. ## Place the files The certificate and key files belong outside the document root, with the key restricted. IIS works differently: [installing an SSL certificate on IIS](/install/iis/) means importing the certificate and key into the Windows certificate store, not placing files. ```text $ chmod 600 example.com.key $ chown root:root example.com.key ``` > **Warning.** Apache reads the key at startup as the privileged process, > so the key does not need to be readable by the user the workers run as. > Widening permissions to resolve a startup error hides a configuration > problem behind a real exposure. If Apache cannot read the key, check the > path and the ownership rather than the mode. ## Configure the virtual host The encrypted site lives in its own virtual host on the encrypted port, with encryption switched on explicitly. ```text ServerName example.com ServerAlias www.example.com SSLEngine on SSLCertificateFile /etc/ssl/example.com.chained.crt SSLCertificateKeyFile /etc/ssl/example.com.key #... the rest of the site configuration ``` `SSLEngine on` is the directive that actually enables encryption. A virtual host on the encrypted port without it answers in plain text, which is the fault behind SSL_ERROR_RX_RECORD_TOO_LONG. `ServerName` and `ServerAlias` must between them list every hostname this site serves, and the certificate must cover all of them, or visitors to the uncovered name see a name mismatch error, ERR_CERT_COMMON_NAME_INVALID in Chrome. ### Redirect the unencrypted version A separate virtual host on the unencrypted port sends visitors across. ```text ServerName example.com ServerAlias www.example.com Redirect permanent / https://example.com/ ``` The redirect runs after the connection is established, so it cannot rescue a name the certificate does not cover. Both names still need to be on the certificate. ## Test and restart Apache validates its configuration on demand, and doing so before restarting turns a possible outage into a message. ```text $ apachectl configtest $ apachectl graceful ``` A graceful restart applies the new configuration while letting existing connections finish, which is preferable to a hard restart on a live server. If the test complains about unknown directives, the encryption module is not enabled, which is the case worth checking first because the message does not say so plainly. ### Verify from outside Confirm the certificate presented, the completeness of the chain, and the coverage of every name in `ServerName` and `ServerAlias`. An external checker reports all three; your own browser reports the first reliably and the second not at all. Run this after every certificate change. On Apache in particular, a virtual host that fails to load silently leaves the previous configuration in place, so a restart that appeared to succeed can be serving the old certificate. ## Several sites on one server Apache selects a virtual host by the requested name. If none matches, the first virtual host defined for that port serves the request, along with its certificate. That default behaviour produces two recognisable symptoms. A new site whose virtual host was never created receives another site's certificate. And a site whose virtual host failed to load, because of a syntax error elsewhere in the file, falls back the same way while appearing to be configured. Where several names share a certificate, one virtual host can serve them all. Where they have separate certificates, each needs its own virtual host, since a virtual host holds one certificate. ## When the site is behind something else Where TLS terminates decides whether this page applies at all, and it is settled before anything is installed. If a load balancer, a reverse proxy, or a delivery layer terminates connections in front of Apache, the certificate visitors see belongs there, not here. Installing one on Apache in that arrangement changes nothing they experience, and time spent debugging it is time spent on the wrong machine. Apache may still need its own certificate in that arrangement, for the connection between the front end and itself. That certificate serves a different purpose and often has different requirements: it is not seen by visitors, and depending on the configuration it may not need to be issued by a public authority at all. Establishing which of the two you are configuring takes one question, and asking it first avoids the most frustrating variety of certificate work, where everything is correct and nothing changes. ## Common mistakes on Apache **The encryption module is not enabled.** Directives are rejected as unknown, and the message points at syntax rather than at the module. **The chain is missing or supplied twice.** Either the intermediates are absent, or they are both in the combined file and pointed at by the deprecated directive. **The configuration was tested and the service not restarted.** Testing validates; restarting applies. **A syntax error elsewhere prevented the virtual host from loading.** Everything looks configured, and the site is served by the default host. ## Automate this with Bridge SSL Bridge SSL issues certificates and serves them with their full chain, so the combination step, the version-dependent chain directive, and the restart all disappear from the process. Renewal happens on a schedule rather than as work on the server, which removes the case where a certificate is renewed correctly and the service never picks it up. See what the platform offers at [Bridge CDN](https://bridge-cdn.com/). ## FAQ **Which directives does Apache need for SSL?** Three, and all of them inside a virtual host listening on the encrypted port: the directive that turns encryption on, the one naming the certificate file, and the one naming the private key. Placing them outside that virtual host is a common reason a configuration loads and changes nothing. **Do I need a separate chain file?** Not on current versions, where the intermediates belong in the same file as the certificate, in order towards the root. Older releases used a separate directive for the chain, which is why configurations copied from older guides often reference something the running version ignores. **Apache says the directives are unknown.** The encryption module is not loaded, so the directives that belong to it are not recognised. The message describes this as a syntax error, which sends people to check spelling instead of checking which modules are enabled, and the fix is one module away. **Should I restart or reload?** A graceful restart, which applies the new configuration while letting connections already in progress finish normally. A hard restart drops them mid-request, and on a busy server that turns a routine certificate change into a brief outage nobody planned for or announced. **Why is another site's certificate being served?** Either no virtual host matched the requested name, or the one that should have matched failed to load and was skipped silently. In both cases the first virtual host defined for that port answers, presenting a certificate that is perfectly valid for a name the visitor did not ask for. **How do I confirm it worked?** From outside the machine, check three things: which certificate is actually presented, whether the chain reaches a trusted root, and whether every name the virtual host answers for appears in that certificate. A name configured on the server but missing from the certificate fails only for visitors. --- https://bridge-ssl.com/install/nginx/ --- # Install an SSL certificate on nginx Nginx needs three things to serve HTTPS: the certificate file with its chain, the private key, and a `server` block that listens on port 443 with the `ssl` parameter. The configuration is short, and most broken installations come from a chain that was not combined or a `listen` line without `ssl`. This page covers the configuration, the redirect from HTTP, TLS versions, and nginx in front of an application. The steps common to every server are on [installing a certificate](/install/). ## Before you start - **The certificate and its intermediates**, as separate files or already combined. Many authorities and ACME clients provide a combined file, often named `fullchain.pem`. A PFX bundle, the usual import format when you [install an SSL certificate on IIS](/install/iis/), has to be converted to PEM files first. The OpenSSL commands for that split are part of [exporting an SSL certificate to another server](/install/import-export-certificate/). - **The private key** generated with the request, covered on [CSR](/certificates/csr/). - **Access to edit the configuration and reload nginx.** - **The configuration file that serves this site.** On a server with several sites there are several, and editing the wrong one changes nothing. If you obtain certificates with an ACME client, it can usually write the files and reload nginx itself. See [ACME clients](/acme/clients/). ## Combine the certificate and chain Nginx reads the site's certificate and its intermediates from one file, in that order: the site's certificate first, then the intermediate that signed it. The [nginx documentation](https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate) describes the same order. Current Apache versions read the same combined file, as covered under [how to install an SSL certificate on Apache](/install/apache/). ```text $ cat example.com.crt intermediate.crt > example.com.chained.crt ``` Reversed order makes nginx present the intermediate as the site's certificate, and nginx refuses to start because it no longer matches the key. Leaving the intermediate out produces no error at all: browsers that already know the intermediate connect, and other clients fail with [unable to get local issuer certificate](/errors/unable-to-get-local-issuer-certificate/). The root does not belong in the file; clients already have it. See [certificate chains](/certificates/chain/). ## Place the files Keep both files outside the web root and restrict the key: ```text $ chmod 600 example.com.key $ chown root:root example.com.key ``` > **Warning.** The nginx master process reads the key as root at startup, before the worker processes drop privileges, so the key does not need to be readable by the worker user. Making it readable by everyone to clear a permissions error turns a configuration problem into an exposed key. Check the path and ownership instead. ## Configure the server block ```text server { listen 443 ssl; listen [::]:443 ssl; http2 on; server_name example.com www.example.com; ssl_certificate /etc/ssl/example.com.chained.crt; ssl_certificate_key /etc/ssl/example.com.key; # the rest of the site configuration } ``` **`listen 443 ssl`** turns on TLS for the port. Without the `ssl` parameter nginx answers on port 443 in plain HTTP, and browsers report [ERR_SSL_PROTOCOL_ERROR](/errors/err-ssl-protocol-error/) or, in Firefox, `SSL_ERROR_RX_RECORD_TOO_LONG`. See [port 443](/glossary/port-443/). **`http2 on`** [enables HTTP/2](/tls/alpn/). It is a separate directive since nginx 1.25.1; older guides put `http2` on the `listen` line, a form that newer versions accept with a deprecation warning. On versions before 1.25.1, keep `listen 443 ssl http2;` and leave out the directive. **`server_name`** must list every hostname this block serves, and the certificate must cover each of them. A name served here but missing from the certificate produces a name mismatch in the browser, not an nginx error. See [Subject Alternative Names](/certificates/san/). ### Set TLS versions ```text ssl_protocols TLSv1.2 TLSv1.3; ``` That is the default in current nginx, so on a recent version the line only states it explicitly. Older versions enabled TLS 1.0 and 1.1 by default, and configurations copied from old guides often list them too. Where they appear, remove them. Cipher lists change more often than versions; rather than copying one from a guide, generate a current one with the [Mozilla SSL Configuration Generator](https://ssl-config.mozilla.org/). Why the versions matter is on [TLS versions](/tls/versions/), and what a bad cipher list produces is on [cipher mismatch](/errors/err-ssl-version-or-cipher-mismatch/). ### Redirect HTTP to HTTPS ```text server { listen 80; listen [::]:80; server_name example.com www.example.com; return 301 https://$host$request_uri; } ``` The redirect only works after the HTTPS connection succeeds, so it cannot help a name the certificate does not cover. Once HTTPS works for every name, [HSTS](/glossary/hsts/) tells browsers to skip the HTTP step on later visits. ## Test and reload ```text $ nginx -t $ nginx -s reload ``` `nginx -t` checks the configuration and names the file and line of any error. Reload only after it reports success: nginx keeps running the old configuration if the new one fails, but testing first shows you why. A reload applies the change without dropping open connections, so a full restart is not needed. On systems managed by systemd, `systemctl reload nginx` does the same. If nginx reports `key values mismatch`, the certificate and the key do not belong together, usually because a reissued certificate was installed next to the old key. The [certificate and key matcher](/tools/certificate-key-matcher/) confirms it in one step. ### Verify from outside Check from a machine other than the server, against each hostname: ```text $ curl -I https://example.com/ $ openssl s_client -connect example.com:443 -servername example.com -showcerts **Certificates that renew themselves** — Bridge SSL is the certificate layer of Bridge CDN: issuance and renewal happen as part of serving your site, wildcards included when your DNS is on Bridge DNS. Nothing to install, nothing to schedule. [Get started](https://bridge-cdn.com/) [Fix an error first](/errors/) --- https://bridge-ssl.com/tls/forward-secrecy/ --- # Forward secrecy: why yesterday stays private Somebody records your encrypted traffic today and steals your server's private key a year from now. Forward secrecy is the property that makes the recording useless to them anyway: [the keys protecting each conversation](/tls/) were never derivable from that long-term key at all. ## What it protects against Forward secrecy protects against one specific attack, and the protection is narrower than the confident name suggests. The attack is simply stated: capture now, decrypt later. Storage is cheap enough that recorded traffic can wait years for a key to leak, be seized under legal process, or eventually be broken. Without forward secrecy, a single key compromise turns every recorded conversation protected by it into readable text, retroactively and all at once. With it, each conversation used keys that existed only for that conversation, derived over the `TLS` handshake from material both sides contributed and then discarded. The long-term key proves identity; it does not encrypt anything that could be replayed against the archive. ## How the separation works Two jobs that used to be handled by a single key, now split apart between two of them. The certificate's `RSA` or elliptic-curve key answers "is this really the server for this name", which is the identity half of the handshake. The session keys answer "what protects the next few minutes of traffic", and they are computed fresh from contributions both sides make and neither stores. That split is why the property exists at all. An attacker holding the long-term key can impersonate the server going forward, which is serious in its own right, but cannot go back and read what was recorded, because the material needed for that was never written down anywhere and cannot be reconstructed from what they hold. Whether a given connection has this property depends entirely on which combination of algorithms the two sides agreed on, which is what [cipher suites](/tls/cipher-suites/) name. [TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446) removed static RSA key exchange, so every full handshake in it uses an ephemeral Diffie–Hellman exchange, usually over elliptic curves (ECDHE), which is part of why fewer connections lack the property than used to. One more consequence follows, and it is the reason the property is worth having even on sites with nothing secret in them. Traffic that is worthless to an attacker today may be valuable later: an address, a name, a pattern of use that means nothing now and identifies somebody in five years. Deciding today that a conversation will never matter is a prediction, and this property removes the need to make it. ## What it does not cover Forward secrecy leaves four things uncovered, and each is a different conversation. **It does not protect the future.** Somebody holding your key can present themselves as you until the certificate is replaced and the old one is no longer trusted anywhere, which is what revocation exists for and why it is a considerably harder problem than it first looks. **It does not protect what either endpoint keeps.** Traffic being unreadable in transit says nothing about the copy sitting in your database, in your logs, or in the visitor's browser. Most data loss is not interception at all, and this property addresses only interception. **It does not survive a compromised endpoint at the time.** If the server was already under somebody else's control when the conversation happened, that somebody had the session keys as well, because the server itself needed them to hold the conversation. **It does not make recording pointless.** Traffic patterns, timing, sizes, the name requested through `SNI` and the [protocols offered through ALPN](/tls/alpn/) remain visible to anybody in the path, which is why that name is worth thinking about as a separate question. ## Why it took so long to become normal The arrangement costs a little more work per connection than the simpler one it replaced, and for years that cost was weighed against a threat that seemed theoretical: who would store encrypted traffic for years on the chance of a future key compromise? The answer turned out to be anybody with storage, and the calculation changed. Configurations written before that shift are still running. They are not broken and their sites work, which is precisely why nobody revisits them. That makes this one of the few security properties worth checking on a working system rather than only on a failing one. ## What to do about it Very little, and the fact that there is little to do is itself the point. This is not a setting you enable. It follows from which algorithms your server is willing to use, so the practical action is to configure from a current source rather than from an article of unknown age, and to check what your host actually agrees to against what its configuration file appears to say. The distinction matters because the effective list combines the software's defaults with your own settings. If you inherited a configuration that predates the current protocol generation, that check is worth doing once, deliberately. It takes a minute and either confirms something comforting or finds something that has been quietly true for years. ## FAQ **What is forward secrecy in simple terms?** Each conversation gets its own keys, created for that conversation and thrown away when it ends. Stealing the server's long-term key later does not help anybody with traffic recorded earlier, because that traffic was never protected by that key in the first place and nothing derivable from it remains. **Does forward secrecy protect me if my private key leaks?** Forward secrecy protects past recorded traffic and nothing else. Somebody holding your key can impersonate your site going forward until the certificate is replaced and the old one is no longer trusted, so a leak remains an emergency requiring an immediate response rather than a manageable inconvenience. **Is forward secrecy something I turn on?** Not directly, and looking for the switch is how people conclude they do not have it. It follows from the combination of algorithms your server agrees to use, so it is an outcome of configuration rather than a setting. Check what a host actually negotiates rather than what its configuration file suggests it might. **Do I still need it now?** Yes, and on a modern setup you most likely already have it. The current generation of the protocol removed many of the combinations that lacked the property, so the practical question is usually not whether to adopt it but whether an old configuration somewhere is still permitting something it should not. --- https://bridge-ssl.com/tls/handshake/ --- # The TLS handshake: what each step actually does The TLS handshake is the negotiation at the start of every [TLS](/tls/) connection, before your request is sent. Two sides that have never met agree on terms, one of them proves it owns the name being asked for, and both end up holding keys that nobody watching the exchange can reconstruct. ## What has to be settled, and why in this order Every step exists because the next one cannot happen without it. Nothing can be encrypted until both sides agree which algorithms to use, so the opening messages travel in the clear. Nobody should trust a key from a party whose identity is unproven, so identity is established before the keys are used for anything that matters. And no application data can move until both sides have confirmed they derived the same keys, because a silent mismatch would produce garbage rather than an error. That ordering also explains why early failures look different from late ones: the early ones are about what the two sides have in common, the later ones about whether one of them is who it claims to be. ## Step by step in TLS 1.3 The current version, [TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446), completes a full handshake in one round trip: 1. **ClientHello.** The client lists the versions and [cipher suites it supports](/tls/cipher-suites/), the name it wants in the [SNI](/glossary/sni/) extension, and a key share for the exchange it expects the server to pick. 2. **ServerHello.** The server picks a version and a cipher suite and sends its own key share. From here both sides can compute the same handshake keys, and everything after this message is encrypted. 3. **EncryptedExtensions.** Further settings the server agreed to, such as [the application protocol negotiated by ALPN](/tls/alpn/). 4. **Certificate and CertificateVerify.** The server's certificate chain, then a signature over the handshake so far made with the certificate's private key. 5. **Finished, from the server.** A value computed over the whole exchange with the derived keys. 6. **Finished, from the client.** The same check in the other direction. The client can send its first request right after it. In [TLS 1.2](https://www.rfc-editor.org/rfc/rfc5246) the same work takes two round trips: the server's certificate and key exchange travel unencrypted, and keys are settled in separate ClientKeyExchange and ChangeCipherSpec messages before either side sends Finished. ## The client opens with what it can do The ClientHello is a statement of capability, not a request for anything in particular. It says which protocol versions the client supports, which combinations of algorithms it accepts, and which name it is trying to reach. That last detail matters more than its size suggests: one address commonly serves many names, and without the name up front a server could not know which certificate to present. The client also sends key exchange material immediately, guessing which method the server will pick. That guess is what lets TLS 1.3 finish in fewer round trips than TLS 1.2. ## The server answers with what it chose The ServerHello is a set of decisions, not a negotiation. It names the version and the cipher suite the server selected and contributes its own key share. From that point both sides derive the same secrets independently: the keys are computed on each side rather than sent between them, so recording the conversation gives an observer nothing to decrypt with. That is also why a stolen server key does not expose past sessions, the property described on [forward secrecy](/tls/forward-secrecy/). If the server finds nothing acceptable in what the client offered, the exchange stops here. That failure has nothing to do with certificates and produces no warning about identity, which is why a handshake failure reads so differently from the certificate errors people expect. ## The server proves the name is its own Two separate things happen here, and they are routinely conflated. **The certificate is presented.** It states which names it covers, who issued it and for how long it is valid. What a certificate contains belongs to [certificates](/certificates/). **The server proves it holds the matching private key.** This is the CertificateVerify signature, and it is what makes the certificate mean anything. A certificate is public and can be copied by anybody who has seen it; what cannot be copied is a signature only the holder of the private key can make. Without the second half, the first would prove nothing: somebody could present the certificate of any site they had ever visited. The client then checks the chain, the names and the dates, and stops with a browser warning if any check fails. ## Both sides confirm they agree The exchange ends with each side's Finished message: a value computed over everything said so far, using the derived keys. If the other side computes a different value, the connection is abandoned. This does two jobs at once. It confirms that key derivation matched, and it detects tampering with the earlier messages, because altered messages produce a different value. That is the defence against an attacker in the path forcing both sides onto weaker terms than they actually support. ## How to watch a handshake Both curl and OpenSSL print the handshake as it happens: ```text $ curl -v https://example.com/ -o /dev/null $ openssl s_client -connect example.com:443 -servername example.com -msg ``` In curl's output, the lines marked TLS handshake show the ClientHello and ServerHello and the negotiated version and cipher. OpenSSL with -msg prints every handshake message by name, which is the quickest way to see where an exchange stops. ## Where TLS 1.2 and TLS 1.3 differ Two differences matter in practice. Latency: TLS 1.3 overlaps agreement and key establishment, so a connection becomes usable one round trip sooner, which matters most for visitors far from the server. And subtraction: TLS 1.3 removed key exchange and cipher options instead of adding them, so a modern handshake has fewer ways to end up in a weak configuration. Which versions to enable is covered on [TLS versions](/tls/versions/). ## FAQ **What is the TLS handshake?** The TLS handshake is the negotiation that runs before any of your data is sent. The two sides agree on a protocol version and cipher suite, each derives the same keys from exchanged key shares, and the server proves it holds the private key for the name requested. **What are the steps of the TLS handshake?** In TLS 1.3: ClientHello, ServerHello, EncryptedExtensions, the server's Certificate and CertificateVerify, then a Finished message from each side. It takes one round trip; TLS 1.2 needs two. **Is the SSL handshake the same as the TLS handshake?** Yes in everyday use. SSL is the old name of the protocol, and every connection today runs TLS, so an "SSL handshake" is a TLS handshake. **How long does a handshake take?** It is dominated by round trips rather than computation, so it depends on the distance between the two sides. TLS 1.3 needs one round trip for a full handshake, TLS 1.2 two. **Why does a handshake fail with no certificate warning?** Because it failed before identity was ever discussed. If the two sides share no acceptable version or cipher suite, the exchange ends at the ServerHello stage, and no certificate has been presented to complain about. **Are the keys sent over the connection?** No. Each side sends a key share from which both compute the same secret independently, so the secret itself never travels, and a recording of the exchange cannot be used to reconstruct it. --- https://bridge-ssl.com/tls/versions/ --- # TLS versions: 1.0 to 1.3, and which to enable TLS versions are the successive revisions of the protocol behind every [TLS](/tls/) connection. Four exist, two are still allowed, and the current one, TLS 1.3, changed more than any revision before it. This page is about the versions themselves: what each one is, what changed, and how to check and set what a server accepts. ## Which versions exist, and which are still allowed | Version | Specification | Status | |---|---|---| | TLS 1.0 | RFC 2246 | deprecated by RFC 8996 | | TLS 1.1 | RFC 4346 | deprecated by RFC 8996 | | TLS 1.2 | RFC 5246 | allowed | | TLS 1.3 | RFC 8446 | current | The versions before them were called SSL and are deprecated as well; how the name changed is covered on [SSL vs TLS](/glossary/ssl-vs-tls/). [RFC 8996](https://www.rfc-editor.org/rfc/rfc8996) formally deprecates TLS 1.0 and 1.1, and current browsers refuse them. A server today should accept TLS 1.2 and TLS 1.3 and nothing older. ## What TLS 1.3 changed [TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446) is not an incremental revision. It removed the options that caused most of the trouble in earlier versions and rebuilt the handshake around fewer choices. **A shorter handshake.** A full handshake completes in one round trip instead of two, because the client sends its key share in the first message. The steps are on [the TLS handshake](/tls/handshake/). **Only forward-secret key exchange.** Static RSA and static Diffie–Hellman key exchange are gone; every full handshake uses an ephemeral exchange, so a stolen server key cannot decrypt recorded sessions. See [forward secrecy](/tls/forward-secrecy/). **Only authenticated encryption.** [The remaining cipher suites](/tls/cipher-suites/) all use AEAD constructions. Older ciphers and modes that earlier versions still allowed cannot be negotiated at all. **More of the handshake encrypted.** Everything after the ServerHello, including the server's certificate and its [ALPN protocol choice](/tls/alpn/), travels encrypted, so an observer sees less of the exchange. **Built-in downgrade protection.** The server signals in its random value when it is being pushed to an older version, and a TLS 1.3 client detects it. ## Is TLS 1.2 still safe? Yes, when configured with modern cipher suites. TLS 1.2 itself is not deprecated; the risk is in the options it still permits, such as non-forward-secret key exchange and older ciphers. A TLS 1.2 configuration that allows only ephemeral key exchange and AEAD ciphers is sound, and keeping it enabled lets older clients connect while newer ones negotiate TLS 1.3. ## How to check which versions a server accepts [Ask for each version in turn](/certificates/openssl-commands/) and see which handshakes complete: ```text $ openssl s_client -connect example.com:443 -servername example.com -tls1_3 $ openssl s_client -connect example.com:443 -servername example.com -tls1_2 $ openssl s_client -connect example.com:443 -servername example.com -tls1_1 ``` The first two should complete; the third should fail. A scan lists everything at once: ```text $ nmap --script ssl-enum-ciphers -p 443 example.com ``` Check from outside, against the hostname visitors use. A configuration file says what was intended; the handshake says what is actually served, and behind a CDN or load balancer the two may be different machines. ## How to set the versions Web servers name the accepted versions in one directive. In nginx: ```text ssl_protocols TLSv1.2 TLSv1.3; ``` In Apache: ```text SSLProtocol -all +TLSv1.2 +TLSv1.3 ``` Both directive names still say SSL; the values are what matter. Reload the server and repeat the checks above, because a directive in a file that is not loaded changes nothing. ## 0-RTT and its trade-off TLS 1.3 also lets a returning client send its first request together with the ClientHello, using a key from a previous session. This "early data" saves a full round trip, but it can be replayed: an attacker who captures it can send it again. That is acceptable for requests that change nothing, such as fetching a page, and not for anything that does. Servers that enable early data should accept it only for safe requests. ## FAQ **What is the latest TLS version?** TLS 1.3, defined in RFC 8446. It is supported by every current browser and by current server software, and it is negotiated automatically whenever both sides support it. **What is the difference between TLS 1.2 and TLS 1.3?** TLS 1.3 completes a full handshake in one round trip instead of two, allows only forward-secret key exchange and authenticated encryption, and encrypts more of the handshake. TLS 1.2 permits older options that have to be disabled by configuration. **Which TLS versions should be enabled?** TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 are deprecated by RFC 8996, and every SSL version is deprecated as well. **Is TLS 1.2 deprecated?** No. TLS 1.2 is still allowed and safe when configured with ephemeral key exchange and AEAD cipher suites. Only TLS 1.0, TLS 1.1 and SSL are deprecated. **How do I check which TLS version a website uses?** Run openssl s_client against the hostname with -tls1_3 or -tls1_2 and see which completes, or open the browser's developer tools, where the security panel shows the negotiated version for the current connection. --- https://bridge-ssl.com/tls/cipher-suites/ --- # TLS cipher suites: what they are and how to read them A cipher suite is a named set of algorithms that a client and a server agree to use for one TLS connection. In TLS 1.2 the name lists all of them: how the keys are exchanged, how the server proves its identity, how data is encrypted and which hash is used. TLS 1.3 shortened the list to five suites that name only encryption and hashing. Both sides choose a suite during the [TLS handshake](/tls/handshake/), and it is part of the [TLS protocol](/tls/) section. ## Quick facts | | | |---|---| | Chosen | during the handshake: the client offers a list, the server picks one | | TLS 1.2 example | `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` | | TLS 1.3 suites | five defined; three enabled by default in OpenSSL | | Registry | [IANA TLS Cipher Suites](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) | | When none match | the handshake fails; see [cipher mismatch](/errors/err-ssl-version-or-cipher-mismatch/) | ## What a cipher suite does A TLS connection needs four jobs done. The two sides must agree on a shared secret without revealing it, the server must prove it holds the certificate's private key, the data must be encrypted, and every record must be protected against changes in transit. A cipher suite settles which algorithm does each job, so the two sides choose one name instead of negotiating four separate choices. The suite is fixed for the connection. A different connection to the same site, from another client, can use another suite. ## How to read a TLS 1.2 suite name Take `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` apart: | Part | Job | Meaning | |---|---|---| | `ECDHE` | key exchange | elliptic-curve Diffie-Hellman with a new key for each connection, which gives [forward secrecy](/tls/forward-secrecy/) | | `RSA` | authentication | the server proves its identity with an RSA certificate key | | `AES_128_GCM` | encryption | AES with 128-bit keys in GCM mode, which also authenticates the data | | `SHA256` | hash | used to derive keys during the handshake | The authentication part has a practical consequence. A suite marked `RSA` works only with a certificate that has an RSA key, and a suite marked `ECDSA` only with an ECDSA key. A server whose list allows only ECDSA suites while its certificate has an RSA key cannot complete any TLS 1.2 handshake. ## What changed in TLS 1.3 TLS 1.3 removed key exchange and authentication from the suite name. Key exchange is always ephemeral Diffie-Hellman, negotiated separately as a group, and the signature algorithm is negotiated on its own as well. What remains is the encryption algorithm and the hash. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446#appendix-B.4) defines five suites: | Suite | Note | |---|---| | `TLS_AES_128_GCM_SHA256` | required for every TLS 1.3 implementation | | `TLS_AES_256_GCM_SHA384` | enabled by default in OpenSSL | | `TLS_CHACHA20_POLY1305_SHA256` | enabled by default in OpenSSL; fast on devices without AES hardware | | `TLS_AES_128_CCM_SHA256` | for constrained devices; rarely enabled on web servers | | `TLS_AES_128_CCM_8_SHA256` | for constrained devices; rarely enabled on web servers | All five use authenticated encryption, and all the older choices are gone: RC4, 3DES, CBC-mode ciphers and static RSA key exchange do not exist in TLS 1.3. That is why a TLS 1.3 configuration rarely needs attention, while a TLS 1.2 list still does. ## How client and server choose The client sends the suites it supports in its first message, most preferred first, as it does with application protocols in [the ALPN extension](/tls/alpn/). The server picks one it also supports. Most servers can be told to prefer their own order instead of the client's, for example `ssl_prefer_server_ciphers` in nginx or `SSLHonorCipherOrder` in Apache. With a list made only of strong suites, either order gives a secure result. If the two lists share nothing, the server ends the handshake with a `handshake_failure` alert. Firefox shows that as `SSL_ERROR_NO_CYPHER_OVERLAP` and Chrome as `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`; fixes are on [cipher mismatch](/errors/err-ssl-version-or-cipher-mismatch/). ## Two naming systems The same suite has two names. The standard name, registered with IANA, is `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`. OpenSSL and the servers built on it, including nginx and Apache, use their own name: `ECDHE-RSA-AES128-GCM-SHA256`. TLS 1.3 suites use the standard names everywhere. OpenSSL prints both side by side: ```text $ openssl ciphers -stdname -v 'ECDHE-RSA-AES128-GCM-SHA256' TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ``` In OpenSSL-based servers, TLS 1.2 suites and TLS 1.3 suites are configured separately. A cipher list such as nginx's `ssl_ciphers` affects only TLS 1.2 and older; TLS 1.3 suites keep their defaults unless set in their own setting. ## Which suites to allow For a public website the principle is short: TLS 1.3 with its defaults, and for TLS 1.2 only suites with ECDHE key exchange and AEAD encryption (GCM or ChaCha20-Poly1305). Everything else either lacks forward secrecy or uses encryption modes with a history of attacks. Rather than copying a list from a guide, generate one for your server and the oldest clients you need with the [Mozilla SSL Configuration Generator](https://ssl-config.mozilla.org/). Lists change as clients move, and a generator is updated; a list pasted into a configuration years ago is not. Which protocol versions to enable is on [TLS versions](/tls/versions/). ## How to see what a server offers To check which suites a server accepts, list them from outside: ```text $ nmap --script ssl-enum-ciphers -p 443 example.com ``` To see the suite one connection used, read the handshake summary of `openssl s_client`, which prints a line such as `New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384`. To see what a cipher string in a configuration expands to before using it: ```text $ openssl ciphers -v 'ECDHE+AESGCM:ECDHE+CHACHA20' ``` An empty result or `no cipher match` means the string selects nothing. More commands are on [OpenSSL commands](/certificates/openssl-commands/). ## FAQ **What is a cipher suite in TLS?** A named set of algorithms both sides use for one connection. In TLS 1.2 it names key exchange, authentication, encryption and hash; in TLS 1.3 only encryption and hash, because the rest is negotiated separately. **How many cipher suites does TLS 1.3 have?** Five, defined in RFC 8446: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 and TLS_AES_128_CCM_8_SHA256. Web servers usually enable the first three. **Which cipher suites should I use?** TLS 1.3 defaults, plus TLS 1.2 suites with ECDHE key exchange and GCM or ChaCha20-Poly1305 encryption. Generate the exact list for your server with the Mozilla SSL Configuration Generator. **What happens if the client and server have no cipher suite in common?** The handshake fails before any data is sent. Firefox reports SSL_ERROR_NO_CYPHER_OVERLAP and Chrome ERR_SSL_VERSION_OR_CIPHER_MISMATCH. **Why does OpenSSL use different cipher names?** OpenSSL kept its own short names for TLS 1.2 and older suites. openssl ciphers -stdname shows the standard IANA name next to each one. **How do I check which cipher suite a website uses?** Run openssl s_client -connect example.com:443 and read the line that names the protocol and cipher, or list everything the server accepts with nmap --script ssl-enum-ciphers. --- https://bridge-ssl.com/tls/alpn/ --- # ALPN: how TLS chooses HTTP/2 or HTTP/1.1 ALPN, Application-Layer Protocol Negotiation, is a TLS extension that lets the client and the server agree which protocol they will speak inside the encrypted connection, such as HTTP/2 or HTTP/1.1. The choice is made during the [TLS handshake](/tls/handshake/), so it costs no extra round trip. Browsers rely on it to use HTTP/2 over HTTPS, and HTTP/3 requires it. ALPN is defined in [RFC 7301](https://www.rfc-editor.org/rfc/rfc7301) and belongs to the [TLS protocol](/tls/) section. ## Quick facts | | | |---|---| | Defined in | RFC 7301 (2014) | | Sent in | the ClientHello; the server's choice comes back in the handshake | | Common identifiers | `h2` (HTTP/2), `http/1.1`, `h3` (HTTP/3) | | If nothing matches | the server may end the handshake with `no_application_protocol`, or continue without choosing | | Check it | `openssl s_client -alpn h2,http/1.1` or `curl -v` | ## What ALPN does One port, 443, carries several protocols: HTTP/1.1, HTTP/2 and others. Before any request is sent, client and server must know which one they are speaking. Without ALPN that would take an extra exchange after the encrypted connection is ready. ALPN puts the question into the handshake itself, so the first request after the handshake already uses the agreed protocol. ALPN replaced NPN, an earlier extension created for SPDY, the experimental protocol that became HTTP/2. In NPN the client chose; in ALPN the server chooses from the client's list. ## How the negotiation works 1. **The client offers.** Its first message, the ClientHello, contains an ALPN extension listing the protocols it supports, in order of preference. A browser typically sends `h2` and then `http/1.1`. The same message lists [the cipher suites the client accepts](/tls/cipher-suites/). 2. **The server chooses.** It picks one protocol from the list that it also supports. In TLS 1.2 the choice comes back in the ServerHello; in TLS 1.3 it is sent in the encrypted part of the server's reply, the EncryptedExtensions message. In a full handshake that part is encrypted with keys from an ephemeral key exchange, the one that gives TLS 1.3 [forward secrecy](/tls/forward-secrecy/). 3. **Both use it.** After the handshake, the connection carries the chosen protocol from the first byte. The identifiers are registered with IANA. Each is a short string, such as `h2` for HTTP/2 over TLS. ## When no protocol matches RFC 7301 tells the server to end the handshake with a fatal `no_application_protocol` alert when it supports none of the offered protocols. OpenSSL's own test server does exactly that; `openssl s_client` then reports `SSL alert number 120`. Web servers usually behave more gently. If the client offered `h2` and `http/1.1` and the server has HTTP/2 turned off, the server picks `http/1.1` or makes no choice, and the browser falls back to HTTP/1.1. A missing `h2` therefore makes a site slower, not unreachable. The handshake fails only when a client insists on a protocol the server does not have, which happens mostly with specialised clients, such as gRPC, that require HTTP/2. ## ALPN and HTTP/2, HTTP/3 **HTTP/2.** Browsers support HTTP/2 only over TLS and negotiate it only through ALPN. A server that has HTTP/2 enabled but cannot offer `h2` in ALPN, for example because its TLS library is too old, serves HTTP/1.1 to every browser. In nginx, HTTP/2 is turned on with `http2 on`, and nginx then offers `h2` automatically; see [installing on nginx](/install/nginx/). **HTTP/3.** HTTP/3 runs over QUIC, which carries the TLS 1.3 handshake inside it. QUIC requires ALPN, and HTTP/3 is identified as `h3`. Browsers usually learn that a site offers HTTP/3 from an `Alt-Svc` header or a DNS record, then connect over QUIC and confirm it through ALPN. ## ALPN and certificates ALPN also carries one certificate-related job. The ACME validation method TLS-ALPN-01, defined in [RFC 8737](https://www.rfc-editor.org/rfc/rfc8737), proves control of a domain over port 443: the authority connects offering only the protocol `acme-tls/1`, and the server answers with a special temporary certificate instead of its usual one. That lets a server validate a name without serving files over port 80. How validation methods compare is on [ACME](/acme/). ALPN does not affect which certificate a site normally presents. That is chosen by the hostname the client sends, called [SNI](/glossary/sni/). ## How to check ALPN Offer protocols with OpenSSL and read which one the server picked: ```text $ openssl s_client -connect example.com:443 -servername example.com -alpn h2,http/1.1 :443 -servername example.com &1 | grep -E 'Protocol version|Peer certificate|Verification' Protocol version: TLSv1.3 Peer certificate: CN = bridge-ssl.com Verification: OK ``` `Verification: OK` means OpenSSL built a path from the server's certificate to a root in your machine's trust store. Without `-brief`, the same result appears near the end as `Verify return code: 0 (ok)`. `s_client` finishes the connection even when verification fails, so read the code rather than trusting that a printed certificate is a valid one [1]. `-showcerts` prints the certificates exactly as the server sent them, in the order it sent them, and the manual stresses that this is not a verified chain [1]. If the list stops at the site's own certificate, the server is not sending its intermediates: browsers may hide that by filling the gap from their cache, while scripts fail with `unable to get local issuer certificate`. Other verify return codes are listed on this site's page of OpenSSL commands for checking certificates. ### Names ``` $ openssl s_client -connect bridge-ssl.com:443 -servername bridge-ssl.com /dev/null | openssl x509 -noout -ext subjectAltName X509v3 Subject Alternative Name: DNS:bridge-ssl.com ``` Browsers match the hostname against this list only. To test one name directly, `-verify_hostname` checks it against the certificate the server sent [1]. This site's certificate lists the bare domain and no `www` name, so asking for `www` fails: ``` $ openssl s_client -connect bridge-ssl.com:443 -servername bridge-ssl.com -verify_hostname www.bridge-ssl.com /dev/null | grep -E '^Verify return code' Verify return code: 62 (hostname mismatch) ``` Code 62 is OpenSSL's hostname mismatch error [3]. In Chrome the same fault shows as ERR_CERT_COMMON_NAME_INVALID behind the warning "Your connection is not private". ### Expiry ``` $ openssl s_client -connect bridge-ssl.com:443 -servername bridge-ssl.com /dev/null | openssl x509 -noout -checkend 1209600 Certificate will not expire ``` `-checkend` asks whether the certificate expires within the given number of seconds, and it exits with a nonzero status if it will [1]. 1209600 seconds is 14 days. The answer `Certificate will expire`, or a status of 1, means renewal is due or failed; once the end date has passed, browsers show ERR_CERT_DATE_INVALID. ### Protocol versions ``` $ openssl s_client -connect bridge-ssl.com:443 -servername bridge-ssl.com -tls1_2 /dev/null | grep -E '^ +Protocol' Protocol : TLSv1.2 ``` Each flag offers a single version, so a completed handshake proves the server accepts it. Run it again with `-tls1_3`; on this site that line reads `TLSv1.3`. [RFC 9325](https://www.rfc-editor.org/rfc/rfc9325) requires TLS 1.2, recommends TLS 1.3, and rules out TLS 1.0 and 1.1 [4]. A server that refuses both current versions fails in browsers with ERR_SSL_VERSION_OR_CIPHER_MISMATCH. What changed between the versions is part of [how TLS works](/tls/). ### OCSP stapling ``` $ openssl s_client -connect bridge-ssl.com:443 -servername bridge-ssl.com -status /dev/null | grep -E '^OCSP' OCSP response: no response sent ``` `-status` asks the server to staple an OCSP response, the authority's signed answer on whether the certificate is revoked [1]. Stapling is optional on both sides in [RFC 6066](https://www.rfc-editor.org/rfc/rfc6066) §8 [5], and an OCSP address in the certificate is optional too under the CA/Browser Forum Baseline Requirements §7.1.2.7.7 [6]. So read `no response sent` together with the certificate: ``` $ openssl s_client -connect bridge-ssl.com:443 -servername bridge-ssl.com /dev/null | openssl x509 -noout -ext authorityInfoAccess,crlDistributionPoints ``` On bridge-ssl.com the output lists a CA Issuers address and a CRL address and no OCSP address, so there is nothing to staple. A certificate that is not short-lived and has no OCSP address must carry a CRL address (§7.1.2.11.2) [6]. How clients use either is a question of certificate revocation, not of this check. ## When a check fails 1. **Verification fails, or the chain stops at position 0.** The server is missing its intermediates or the certificate comes from an authority your machine does not trust. Start with the error unable to get local issuer certificate. 2. **A name is missing.** The certificate was issued for the wrong set of names. Reissue with every hostname visitors use, the bare domain and `www` included. 3. **Expiry is within your margin.** Renewal has not run or has not reached this address. If one address passes and another fails, the stale certificate sits on the second machine. 4. **The handshake fails before any certificate is shown.** Compare protocol versions first. If the server starts and then refuses every connection after a certificate change, [check that the certificate and key belong together](/tools/certificate-key-matcher/). The browser codes these failures produce, from ERR_CERT_DATE_INVALID to ERR_SSL_VERSION_OR_CIPHER_MISMATCH, are explained with their fixes among the [SSL certificate errors](/errors/). ## Online checkers and the command line An online SSL checker connects from outside your network, so it sees what visitors see, and it reports the certificate, the chain the server sends, the protocol versions and ciphers it accepts, and known configuration problems. It may also grade the result. The commands on this page grade nothing; they answer one question each, and the answer can go into a script or a monitor. Use an online check after the first installation of a public site. Use the commands for hosts an online service cannot reach, for checking each address behind a name, and for a scheduled expiry test after every renewal. Reading a certificate file rather than a live host is a separate job for a certificate viewer, and what each field in website certificates means is covered under [website certificates](/certificates/). ## FAQ ### How do I verify an SSL certificate? Connect with `openssl s_client -connect example.com:443 -servername example.com -brief` and look for `Verification: OK`. That confirms the chain reaches a trusted root. Then confirm the name with `-verify_hostname` and the expiry with `openssl x509 -checkend`. ### How do I test an SSL certificate? Run the commands in the table above from a machine outside the server. They cover the same names, dates, chain and protocol tests as an online checker, and they also work on internal hosts that online services cannot reach. ### How do I validate an SSL certificate in one command? Add `-verify_hostname` with your hostname and `-verify_return_error` to `openssl s_client`. OpenSSL then stops at the first verification error instead of carrying on, and the exit status says which happened: on this site it is 0 for `bridge-ssl.com` and 1 for `www.bridge-ssl.com`, a name the certificate does not list. [1] ## Sources 1. [OpenSSL 3.0 manual](https://docs.openssl.org/3.0/man1/openssl-s_client/): openssl-s_client (`-connect`, `-servername`, `-brief`, `-verify_hostname`, `-verify_return_error`, `-showcerts`, `-tls1_2`, `-tls1_3`, `-status`) and openssl-x509 (`-ext`, `-checkend`). 2. [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110), HTTP Semantics, §4.2.2: the https URI scheme and TCP port 443. 3. OpenSSL source, include/openssl/x509_vfy.h: X509_V_OK 0, X509_V_ERR_HOSTNAME_MISMATCH 62. 4. RFC 9325, Recommendations for Secure Use of TLS and DTLS, §3.1.1. 5. RFC 6066, TLS Extensions, §8 Certificate Status Request. 6. [CA/Browser Forum Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/documents/), version 2.3.1, §7.1.2.7.7 and §7.1.2.11.2. **Continue in this section** - [SSL tools: decode, convert and check certificates](/tools/) — Six checks for certificates, keys and signing requests, each run on your own machine. What each one settles, and the page that explains the answer. - [How to check that a certificate and key belong together](/tools/certificate-key-matcher/) — A certificate and a private key either belong together or the service will not serve. Check the pair before restarting, and see what a mismatch looks like. --- https://bridge-ssl.com/vs/lets-encrypt/ --- # Let's Encrypt alternative: when you actually need one For domain-validated certificates, Let's Encrypt is the default across most of the encrypted web, and for most sites it is also the right answer. A page titled as an alternative should say that first, because the honest comparison starts by conceding almost everything. Usually you do not need one. What follows is the narrow set of situations where something else is warranted, stated as criteria. ## Where it is stronger than the alternatives Let's Encrypt is stronger nearly everywhere, for the case it covers. **Automation is the product.** Issuance and renewal happen through a protocol implemented by every serious client, described on [ACME](/acme/). Nothing about obtaining a certificate involves a person, which is what current certificate lifetimes require anyway. **It is free, without a paid tier withholding anything.** There is no version of the same certificate you could buy that would be better, which distinguishes this from most free offerings. **Ubiquity means everything supports it.** Clients, hosting platforms, control panels, and documentation all assume it. That is a practical advantage independent of any technical property: the path is well trodden and the failures are well documented. **The trust position is settled.** It is present in trust stores everywhere, and has been long enough that the question does not arise. Any comparison that opens by looking for weaknesses here is answering a question nobody asked. ## What it does not do Three things, and each maps to a situation rather than to a deficiency. **Organisation or extended validation.** Only domain validation is offered, because that is what can be automated. Where a compliance framework, a customer's procurement process, or an internal policy names organisation validation, this is not the authority to use. See [certificate types](/certificates/types/). **A support relationship.** There is documentation and a community, and nobody contractually obliged to answer you. For most sites that is sufficient, and for some it is not. **Long-lived certificates.** Lifetimes are short by design, which is correct for automated setups and a problem for devices that cannot be automated and must be updated by hand. Absent from that list: nothing about encryption, browser acceptance, or the quality of the certificates. Those do not differ, as covered on [choosing an authority](/vs/). ## When an alternative is warranted An alternative is warranted in four situations. If none applies, the comparison is over. **A requirement names organisation validation.** The requirement is the reason, and satisfying it means an authority that performs those checks. This is the most common legitimate case and it has nothing to do with technical merit. **You need someone answerable.** Where a certificate problem must be escalated to a party under contract, that relationship is purchased. Worth being precise about what you are buying: a response obligation, not better certificates. **A device cannot be automated.** Appliances and equipment that accept certificates only through a manual interface, and cannot handle frequent replacement, need a longer-lived certificate from an authority that issues them. **Operational limits genuinely bind you.** At sufficient scale, or with many distinct names, limits become a planning constraint. The numbers change, so read them from Let's Encrypt's own documentation. ## Reasons that are not reasons Three arguments appear regularly and do not survive examination. **"Free certificates are less trusted."** Trust is binary and identical. There is no gradation among authorities in the trust stores, and no visitor sees a difference. **"Short lifetimes are risky."** They are the opposite: shorter validity limits the damage from a compromised key, which is why the industry moved this way. Short lifetimes are a problem only where automation is absent, which is a property of your setup rather than of the certificate. **"You get what you pay for."** In this specific market, what you pay for is validation depth and support obligations. The certificate itself is not a place where paying more produces a better artefact. They matter because they are how the alternative is usually sold. ## If you are considering switching to it The blocker is rarely the authority and almost always automation. Moving from a manually installed annual certificate to short-lived automated ones means the renewal process changes, not just the supplier. Where automation is already running, switching is a configuration change; where it is not, the automation is the project and the authority is incidental. The check to run first is whether your termination point can obtain certificates itself or work with a client, discussed on [ACME clients](/acme/clients/). That answer determines whether this is an afternoon or a piece of infrastructure work. ## What a support relationship actually buys The thing purchased is an obligation to respond, and the value of that depends entirely on what you would escalate. Certificate problems fall into two groups, and only one of them benefits. **Problems at the authority.** Issuance failing, validation behaving oddly, an urgent revocation needing processing. Here a contractual relationship helps: someone is obliged to look, and there is a route that does not depend on community goodwill. **Problems at your end.** An incomplete chain, a configuration that was never reloaded, an expired certificate nobody renewed. These are the large majority of certificate incidents, and no authority's support helps with any of them, because nothing is wrong on their side. So the question to ask before buying support is which group your likely incidents fall into. For a setup where certificates are automated and the failures are the ordinary operational ones, the support relationship addresses a category that rarely occurs. Where it does earn its cost is in organisations that must be able to point at an accountable party during an incident, regardless of where the fault lies. That is an organisational requirement, not a technical one; it deserves to be named as such instead of being dressed as a reliability argument. ## Alternatives worth knowing Other authorities also offer automated domain-validated issuance, with differences in interface, tooling, and terms rather than in the certificates. [ZeroSSL](/vs/zerossl/) covers one such comparison. Where organisation validation or a support relationship is the requirement, the field is commercial authorities generally, and the criteria on choosing an authority apply; no single comparison does. ## Certificates handled for you with Bridge SSL Bridge SSL obtains and renews certificates as part of serving your site, so which authority issues them stops being an operational concern. Where your requirement is organisation validation or a contractual support relationship, that is a different need and this page's criteria apply rather than any platform. See what Bridge offers at [Bridge CDN](https://bridge-cdn.com/). ## FAQ **Do I need an alternative to Let's Encrypt?** Usually not, and the honest cases are narrow. An alternative is warranted when a requirement names organisation validation, when you need someone contractually obliged to respond, when a device cannot be automated and needs a longer-lived certificate, or when operational limits genuinely bind you. **Are its certificates less secure?** No. Encryption comes from the protocol and the keys negotiated during the handshake, and browser trust is binary across every publicly trusted authority. A certificate from this issuer and one from an expensive commercial authority protect the same connection in the same way. **Why are the certificates short-lived?** Because a shorter validity window limits how long a compromised key remains useful to whoever took it. That is a security improvement rather than a restriction, and it only becomes a burden where renewal is still done by hand, which is the situation automation exists to remove. **Can I get organisation-validated certificates from it?** No. Only domain validation is offered, because that is the only level a protocol can verify without a human checking company records. If a requirement names organisation or extended validation, this is the wrong authority and no configuration changes that. **Does Let's Encrypt issue wildcard certificates?** Yes, for one level of names such as `*.example.com`, and only through the DNS-01 challenge, which means the issuing client needs write access to your DNS. File-based validation cannot authorise a wildcard at all. **What about rate limits?** Let's Encrypt rate limits exist, and ordinary use rarely approaches them. Limits start to matter at scale, with very many distinct names, or when something retries in a loop. The classes of limit and the practices that keep you inside them are covered separately. **What stops most people switching to it?** Not the authority itself, but the automation its lifetimes require. Moving from a manually installed annual certificate means the renewal process changes, not just the supplier, and where automation already runs the switch is a configuration change measured in minutes. --- https://bridge-ssl.com/vs/zerossl/ --- # ZeroSSL vs Let's Encrypt: what actually differs Both are [publicly trusted authorities](/vs/) issuing free domain-validated certificates through the same automated protocol. The certificates they produce are equivalent, the browser behaviour is identical, and no visitor could tell which of the two issued the one they received, so the comparison is entirely operational. The differences are in the surrounding arrangement rather than in the certificate, and there are fewer of them than comparison pages imply. Specific values (limits, certificate lifetimes, and what each tier includes) change over time and are read best from each authority's current documentation. Below are the classes of difference, which do not depend on those values. ## What is the same **The protocol.** Both support automated issuance through the same standard, so the same clients work with either, as covered on [ACME clients](/acme/clients/). Switching between them is a configuration change rather than a change of process. **The validation.** Domain validation, with the same challenge types and the same constraint that wildcards require the DNS method. **Browser trust.** Both are in the trust stores. Trust is binary, and there is no gradation among authorities that are present. **The certificate itself.** Same standards, same contents, same behaviour in every client. So a comparison cannot be about certificate quality, and any that is described that way is describing something else. ## Where the difference genuinely lies Three areas, and they are matters of preference rather than of correctness. **Account model.** Let’s Encrypt is designed to be used entirely by software, with no account concept a person interacts with. ZeroSSL offers an account with a web interface where certificates can be seen and managed. Which is better depends on whether anyone wants to look: for a fully automated installation, the interface is unused; for a small team that occasionally needs to check something without command-line access, it is the deciding feature. **Non-automated routes.** Where certificates are obtained through a web form rather than a client, that route exists at ZeroSSL and not at Let’s Encrypt. This matters for the same population that struggles with automation generally: devices, appliances, and setups where nothing can run a client. **Commercial tiers alongside the free offering.** Let’s Encrypt is a non-commercial service with a single free offering; ZeroSSL has paid tiers with additional features and support. That difference cuts both ways, as described below. ## What the commercial tier changes **In favour:** a paid relationship provides someone obliged to respond, and paid tiers can include longer certificate lifetimes and organisation validation, which the free automated route cannot offer. Where a requirement names those, which are among the cases that warrant [an alternative to Let's Encrypt](/vs/lets-encrypt/), having them from the same provider is convenient. **Against:** a free offering that sits alongside paid tiers is subject to commercial decisions in a way that a service without them is not. Free tiers get restructured, and the incentive to move users towards paid plans exists by construction. This consideration applies here rather than to the non-commercial alternative. Neither point is decisive. The first matters if you might need what the paid tiers provide; the second matters if you want the arrangement to be stable for reasons outside anyone's business model. ## How to choose between them Four questions, and most people can answer all four in a minute. **Will a person ever need to see the certificates?** If yes, an interface helps. If everything is automated and nobody logs in, it is irrelevant. **Do you need a route that is not a client?** Devices that cannot run one, or people who cannot use a command line, are served by a web-based issuance route where it exists. **Might you need organisation validation or longer lifetimes later?** Obtaining them from the same provider is simpler than adding a second one, though it is not difficult either way. **Do you prefer a non-commercial arrangement?** A legitimate preference, and the honest reason is stability of terms rather than any technical property. If none of those distinguishes them for you, they are interchangeable, and the correct action is to use whichever your tooling already supports. ## The comparison that matters more Neither choice affects the failures you will have. Certificate incidents come from incomplete chains, configurations never reloaded, automation that stopped silently, and names not covered. None of those depends on the authority, and all of them are covered elsewhere in this material. A setup with well-monitored automation on either authority is in a better position than a carefully chosen authority with unmonitored automation. That is the argument for spending decision-making effort on renewal automation rather than on this page. The authority is a preference; the automation is the risk. ## Switching between them Cheap, and worth knowing because it removes the weight from the decision entirely. Both speak the same protocol, so switching means pointing your client at a different issuance service and letting it obtain a certificate. The names stay the same, the client stays the same, and the server configuration does not change at all. The one thing that differs is the chain, since it comes from whichever authority issued the certificate. Serving the previous authority's chain with the new certificate is the mistake to avoid, and it is the same mistake described on [certificate chains](/certificates/chain/). A client that installs the chain alongside the certificate handles this without anyone thinking about it. There is no migration, no coordination, and nothing to plan. Whichever you choose, the choice is reversible at the next renewal, which is a good reason not to spend long on it. ## Limits Both apply rate limits, and both publish them. The classes are the same: duplicates, per-domain caps, and a stricter allowance for failed validations. Specific values differ and change, which is why they are not reproduced here. Where limits are a real constraint for you, read the current figures from the authority’s own documentation: comparison pages, this one included, go out of date. ## Certificates as part of the stack with Bridge SSL Bridge SSL obtains and renews certificates as part of serving your site, which makes this comparison an implementation detail rather than a decision you maintain. Where you need organisation validation or a contractual support relationship, that is a different requirement and the criteria on choosing an authority apply instead. See what Bridge offers at [Bridge CDN](https://bridge-cdn.com/). ## FAQ **Are ZeroSSL and Let's Encrypt certificates different?** No, in every respect a visitor could observe. Both are publicly trusted, both issue domain-validated certificates through the same automated protocol, and both produce the same padlock with the same protection. The differences are in the arrangement around issuance, not in the artefact. **Can I use the same client with both?** Yes. Both speak the same automated protocol, so any serious client works with either and switching amounts to pointing it at a different issuance service. That also means the decision is reversible at the next renewal rather than something you are committing to. **Which should I choose?** Whichever your tooling already supports, unless one of three things applies: somebody needs a web interface to look at certificates, a device cannot run a client and needs a browser-based route, or you may later want paid tiers with organisation validation from the same provider. **Does the commercial tier make one better?** It cuts both ways. Paid tiers add options a free service cannot offer, such as organisation validation and someone obliged to respond. They also mean the free offering exists inside a commercial structure with an incentive to move users upward, which a non-commercial service does not have. **Do their rate limits differ?** The specific values differ and change over time; the classes of limit are the same. That is why no figures appear here: a comparison page is the worst possible source for a number that moves, and the authority's own documentation is the only one worth reading. **What should I actually worry about?** Not this choice. Certificate incidents come from incomplete chains, automation that stopped without anyone noticing, and names that were never covered, and none of those depends on which authority signed. Effort spent here is effort not spent where the failures actually originate. --- https://bridge-ssl.com/free-wildcard-ssl/ --- # Cheap wildcard SSL cert? The free wildcard included with Bridge CDN If you came here pricing a cheap wildcard SSL cert, there is none to buy on Bridge CDN: the certificate for your domain and the wildcard `*.example.com` are included with the account, issued and renewed by Bridge SSL, the certificate layer of Bridge CDN. It is the wildcard half of [a certificate you never have to renew](/). Two conditions come with it: the site is served through Bridge CDN, and the domain's DNS is on Bridge DNS. Without Bridge DNS, hostnames on Bridge CDN still get an ordinary certificate for their specific names; only the wildcard is unavailable. | | | |---|---| | Price | included with a Bridge CDN account: nothing per certificate, nothing per wildcard, nothing per renewal | | Covers | the domain and `*.example.com`, domain-validated; one wildcard per domain | | Requires | the site served through Bridge CDN; for the wildcard, also the domain's DNS on Bridge DNS | | Proof of control | ACME DNS-01 ([RFC 8555](https://www.rfc-editor.org/rfc/rfc8555) §8.4) [2], with the record placed and removed by the platform | | Matching | one label in place of the asterisk ([RFC 9525](https://www.rfc-editor.org/rfc/rfc9525) §6.3) [4] | | Renewal | ahead of expiry, by the layer that serves the site, written down per hostname | ## What "free" means for this wildcard Free here means included with the Bridge CDN account, not handed to anyone without one. Bridge SSL is not sold on its own, so there is no separate SSL plan and no extra line for wildcards. The account you already have pays for both the certificate and the wildcard. That also makes it a different thing from a cheap wildcard SSL certificate bought from a reseller. There is no certificate file to take to another server: nothing is installed, the platform holds the key, and the certificate works only for hostnames Bridge CDN serves. At commercial authorities a wildcard is a second, separately priced certificate. Here the domain and `*.example.com` are issued as one certificate, with both names listed in its subjectAltName. | What comes with the account | On Bridge CDN | |---|---| | Domain-validated certificate for the domain | included | | Wildcard `*.example.com` | included | | Renewals | included | | Installation and configuration | nothing to do | | DNS-01 record at each issue and renewal | placed and removed by the platform | | Record of every issue and renewal | written per hostname | Current terms and plans for the account itself live on the Bridge CDN site, where signup does. ## Why the wildcard needs Bridge DNS The free wildcard on Bridge CDN is issued only when the domain's DNS is on Bridge DNS. The reason is the validation method, not a pricing rule. A public authority may validate a wildcard only by a method the CA/Browser Forum Baseline Requirements mark for wildcards. Their table of methods (version 2.3.1, §3.2.2.4) leaves two ACME challenges, HTTP-01 (§3.2.2.4.19) and TLS-ALPN-01 (§3.2.2.4.20), unmarked in the Wildcard column, while DNS Change (§3.2.2.4.7) is marked [1]. Let's Encrypt puts it in plain words: HTTP-01 "cannot be used to issue wildcard certificates", and DNS-01 "allows you to issue wildcard certificates" [3]. The rule binds every publicly trusted authority, so a cheap wildcard SSL certificate from a reseller is validated the same way: through DNS or another method marked in that table, never through HTTP-01. DNS-01 works through a TXT record under `_acme-challenge`, holding a value derived from the challenge token and the account key [2]. Whoever answers the challenge needs write access to the zone, and needs it again at every renewal. Bridge SSL obtains [ACME certificates](/acme/) for sites on Bridge CDN and answers that challenge itself, which it can do where the zone is on Bridge DNS: the platform places the record and removes it, rather than you. ## How to get the free wildcard on Bridge CDN Getting the free wildcard on Bridge CDN takes two actions on your side, in this order: 1. Add the domain in Bridge CDN. There is no certificate to buy, no key or signing request to prepare and no file to copy. 2. At the domain's registrar, switch its NS records to Bridge DNS, so the platform can answer DNS-01 for the wildcard. Bridge CDN terminates TLS and delivers the page, which is why the certificate can live there. The rest is done by the platform: 1. Bridge SSL proves control: the DNS-01 record is placed, validated and removed, and the domain and `*.example.com` are issued and presented at the edge. 2. Subdomains are covered before they exist. The wildcard is issued once the domain's DNS is on Bridge DNS, so the first request to a new name such as `shop.example.com` does not wait on issuance. 3. Renewal happens ahead of expiry, by the same layer, proof included. Each issue, renewal and retry is written to the certificate log, per hostname. ## Where the free wildcard on Bridge CDN stops - **One label.** A wildcard in a certificate can only match one label of a hostname [4]. `*.example.com` covers `www.example.com` and `shop.example.com`; a name with more labels in front of `example.com` is outside it. The platform issues one wildcard per domain, `*.example.com`, and no second one a level down. - **Domain-validated.** The certificates prove control of the name. Where a requirement names organisation or extended validation, this is not the mechanism. - **No upload.** A wildcard certificate you buy elsewhere cannot be installed here; there is no import path. - **No choice of authority.** The issuing authority is the platform's decision, not a setting. - **No time commitment.** Issuing and renewal have no published guaranteed time. Keep an outside check on what your hostnames present. - **Bridge DNS for the wildcard.** With the zone anywhere else, no wildcard is issued, because the platform answers DNS-01 only in a zone it holds. - **Bridge CDN only.** The free wildcard, like every Bridge SSL certificate, is for hostnames Bridge CDN serves. A site served from its origin directly, or through another CDN, gets nothing from this layer. ## Free wildcard on Bridge CDN, ACME client or a bought certificate Three routes lead to a wildcard. They differ less in the certificate than in who answers the proof and where the result can be used. | | Bridge CDN account | Free authority, your ACME client | Commercial authority | |---|---|---|---| | Price of the wildcard | included with the account | free at Let's Encrypt [7] | a second, separately priced certificate | | Proof of control for the wildcard | DNS-01, answered by the platform | DNS-01, answered by your client, which needs API access to your DNS [3] | a method the Baseline Requirements allow for wildcards; not HTTP-01 [1] | | Where the certificate works | hostnames Bridge CDN serves | servers you install it on | servers you install it on | | Installation and renewal | nothing to install; renewed by the serving layer | the DNS-01 client, the renewal job and the reload are yours to run and watch | yours, before the expiry date | ### Which route fits - The free wildcard on Bridge CDN fits a site that is, or can be, served through Bridge CDN with DNS on Bridge DNS, and where subdomains keep appearing: catalogues, APIs with regional names, staging environments that multiply. - An ACME client with a free authority fits when the certificate has to sit on your own servers or behind another CDN, and someone will run and watch the renewal job. - Buy a wildcard certificate when a requirement names organisation or extended validation, or a specific authority. Those are the cases this layer does not cover. ## Check what a hostname presents Renewal moved to the platform; checking stays with you. A check from outside, asking what the hostname presents, shares nothing with the system that renewed the certificate. From any machine with OpenSSL: ```shell openssl s_client -connect shop.example.com:443 -servername shop.example.com /dev/null | openssl x509 -noout -ext subjectAltName ``` `-servername` sets the name sent in the TLS SNI extension [5], and `-ext subjectAltName` prints the names the presented certificate covers [6]. For a one-label subdomain, `*.example.com` should appear in that list. ## FAQ **Is the wildcard SSL certificate really free?** Yes, within a Bridge CDN account: no separate SSL plan, no per-certificate charge and no extra line for wildcards. "Free" means already paid for by the account you have, not free to anyone with no account, and it requires the site to be served through Bridge CDN. **What does a wildcard SSL certificate cost on Bridge CDN?** Nothing on top of the account. The certificate, the wildcard and renewals are included; current terms for the account itself are on the Bridge CDN site. **Can I buy a wildcard cert elsewhere and upload it?** No. Bridge SSL has no import path for a certificate bought elsewhere. If an existing certificate has to be used, this layer is the wrong fit. **Do I need Bridge DNS for the free wildcard?** Yes. The wildcard is proved through DNS-01, and the platform places and removes that record itself, which it does when the domain's DNS is on Bridge DNS. ## Sources Statements about what Bridge CDN does are product statements, kept apart from the protocol facts and checked against the platform before publication; [About Bridge SSL](/about/) describes how. 1. [CA/Browser Forum Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/documents/), version 2.3.1, §3.2.2.4: validation methods and the Wildcard column; §3.2.2.4.7, §3.2.2.4.19, §3.2.2.4.20. 2. RFC 8555, Automatic Certificate Management Environment (ACME), §8.4 DNS Challenge. 3. [Let's Encrypt: Challenge Types](https://letsencrypt.org/docs/challenge-types/): HTTP-01, DNS-01 and wildcards. 4. RFC 9525, Service Identity in TLS, §6.3. 5. [OpenSSL 3.0 manual, openssl-s_client](https://docs.openssl.org/3.0/man1/openssl-s_client/): -connect, -servername. 6. OpenSSL 3.0 manual, openssl-x509: -noout, -ext. 7. Let's Encrypt home page: a certificate authority that provides free TLS certificates. ## Add the domain. The certificate is the part you stop thinking about. Bridge SSL is the certificate layer of Bridge CDN, and signup lives there. Current terms, plans and everything else the account covers are on the same page. [Start on Bridge CDN](https://bridge-cdn.com/) --- https://bridge-ssl.com/install/iis/csr/ --- # Generate a CSR in IIS: the wizard, certreq and where the key stays To generate a CSR in IIS, open **Server Certificates** in IIS Manager and choose **Create Certificate Request…** [1]. The wizard asks for the subject, a cryptographic service provider and a bit length, then writes the request to a file you name. The private key stays on that server; the response installs only on the computer that sent the request [2]. This page is the first half of [installing an SSL certificate on IIS](/install/iis/). For several names on one certificate, use `certreq` with an INF file: the wizard has a common name field and none for other names [1][5]. Steps shared by every server are on [install SSL certificates](/install/). - **Where** — IIS Manager, **Server Certificates**, **Create Certificate Request…** [1] - **Key size** — RSA of at least 2048 bits, or ECDSA on P-256, P-384 or P-521 [4] - **Wizard default** — 1024-bit RSA in IIS 7, below that minimum [1] - **Command line** — `certreq -new -machine request.inf example.com.req` [5] - **To finish** — **Complete Certificate Request…** or `certreq -accept`, on the same computer [2][5] ## Wizard or certreq Both run on the server that will use the certificate and write a request file for the authority. The certreq example below sets `RequestType = PKCS10`, the request format defined in [RFC 2986](https://www.rfc-editor.org/rfc/rfc2986) [5][9]. The two differ in what you can put into the request. | | IIS Manager wizard | certreq with an INF file | |---|---|---| | Names | one common name [1] | common name plus a subject alternative name list [5] | | Key | RSA SChannel or DH SChannel provider, bit length from a list [1] | `KeyAlgorithm` RSA or ECDSA_P256, ECDSA_P384, ECDSA_P521, `KeyLength` [5] | | Exportable key | no option on the wizard pages [1] | `Exportable = TRUE` or `FALSE` [5] | | Completing | **Complete Certificate Request…** [2] | `certreq -accept` [5] | ### What you need - **Administrator rights** on the server. The local computer store is shared by every user of the machine; without administrator rights you can manage certificates only for your own account [10]. - **The exact hostnames** the certificate must cover, for example `example.com` and `www.example.com`. - For organisation-validated certificates, your organisation's registered name and location, typed as the authority will verify them. ## Create the request in IIS Manager Microsoft documents the wizard page by page for IIS 7 [1]. Its IIS 10.0 procedure uses the same **Server Certificates** feature and finishes with **Complete Certificate Request** in the same **Actions** pane [3]. 1. Open IIS Manager and select the server in **Connections**. In **Features View**, double-click **Server Certificates**. 2. In **Actions**, choose **Create Certificate Request…**. The **Request Certificate** wizard opens. 3. On **Distinguished Name Properties**, type the hostname the site answers on as the **Common name** [1]. **Organization**, **City/locality** and **State/province** are for an organisation-validated certificate, which must carry the organisation, the country and a city or state; a domain-validated certificate carries at most the country and the common name [4]. For an organisation-validated certificate, write city and state names in full. Leave **Organizational unit** empty: the Baseline Requirements do not allow that attribute in domain-validated or organisation-validated certificates [4]. 4. On **Cryptographic Service Provider Properties**, select **Microsoft RSA SChannel Cryptographic Provider** and a **Bit length** of 2048 or more. 5. On **File Name**, enter a path for the request file and click **Finish** [1]. 6. Open the file in a text editor and send the whole text to the authority, including the first and last lines. Subject fields and signing requests in general are covered in the CSR guide of the certificates section. ### Choose the key size The bit length you pick on the cryptographic service provider page decides whether the CSR you generate in IIS is usable at all. The Baseline Requirements allow RSA keys whose modulus is at least 2048 bits, and ECDSA keys on NIST P-256, P-384 or P-521; no other algorithms or key sizes are permitted [4]. An authority must reject a request whose private key does not meet these sizes [4]. The IIS 7 wizard defaults to 1024 bits for the RSA SChannel provider, and the DH SChannel provider uses 512 [1]. Change the bit length before clicking **Next**, and leave the DH provider alone: DH is not among the permitted algorithms. ## Create the request with certreq `certreq -new` builds a request from an INF file [5]. Use it to create a CSR for IIS when the certificate needs a subject alternative name list, or when you want the private key settings written down rather than chosen in a dialog. Save this as `request.inf`: ```text [Version] Signature=$Windows NT$ [NewRequest] Subject = "CN=example.com" KeyAlgorithm = RSA KeyLength = 2048 KeySpec = 1 KeyUsage = 0xa0 MachineKeySet = TRUE Exportable = FALSE HashAlgorithm = sha256 ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 [EnhancedKeyUsageExtension] OID = 1.3.6.1.5.5.7.3.1 [Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=example.com&" _continue_ = "DNS=www.example.com" ``` Then, in an elevated prompt on the server that will use the certificate: ```text certreq -new -machine request.inf example.com.req ``` The output is a base64-encoded request file [6]. ### What the INF keys do - `MachineKeySet = TRUE` creates the key for the computer, not for you. Key material is kept in the security context of whoever created the request; a key created in an administrator's context is one the machine cannot access [5]. The `-machine` option must agree with it [5]. - `2.5.29.17` is the subject alternative name extension; each `_continue_` line adds a name [5]. A publicly trusted certificate must carry that extension, and a common name, if present, must be one of those names [4]. - `OID = 1.3.6.1.5.5.7.3.1` asks for server authentication [6]. - `KeyUsage = 0xa0` is digital signature and key encipherment [5]. - `HashAlgorithm = sha256` is set explicitly: Microsoft's certreq reference notes that its content follows default settings that include SHA1 [5], and Microsoft's Operations Manager example sets SHA256 [7]. - `Exportable = FALSE` follows Microsoft's advice that private keys shouldn't be exportable, unless several machines must share the key [5]. ### From PowerShell `certreq` is an executable, so the same command runs in PowerShell started as administrator. When you pipe or redirect its output in a script, add `-unicode`, which Microsoft describes as helping when certreq is invoked from Windows PowerShell scripts [5]. ## Check the request before you send it Read the CSR back before it reaches the authority, whichever tool generated it: ```text certutil -dump example.com.req ``` `certutil -dump` prints the contents of a file [11]. Check the subject and every subject alternative name, the bit length of the public key, and the signature algorithm. A missing name costs a new request after issuance. The text file starts with a `-----BEGIN` line. RFC 2986 requests in this text form are labelled `CERTIFICATE REQUEST` by [RFC 7468](https://www.rfc-editor.org/rfc/rfc7468), which also notes that the label `NEW CERTIFICATE REQUEST` is in wide use and that parsers may treat the two as equivalent [12]. Send the file as it is. ## Where the private key stays The private key is not in the CSR. A request carries a distinguished name, a public key and optional attributes, signed with the private key [9]; the key itself stays on the server. For IIS, Microsoft states one rule: the response can be installed only on the computer from which the request was sent [2]. The mechanics are documented for the Windows certificate enrollment API. Creating a request generates the key pair and places a placeholder certificate in the request store; installing the response reads that placeholder and takes the private key from it [8]. With certreq, the key container is generated and maintained by the system [5]. Microsoft's Operations Manager procedure points to **Certificates (Local Computer)** > **Certificate Enrollment Requests** when a requested certificate does not show up in **Personal** [7]. 1. **Complete on the same computer**, the one that sent the request [2]. 2. **Keep the pending request.** Without it the response has no key to pair with [8], and a new CSR is needed. 3. **Use the same context.** A request created without `MachineKeySet` belongs to the account that made it [5]. ## Complete the request When the authority returns the certificate: - **IIS Manager:** in **Server Certificates**, choose **Complete Certificate Request…**, select the authority's file, enter a friendly name and choose the store [3]. The friendly name is a label, not part of the certificate [3]. - **certreq:** run `certreq -accept example.com.cer`. It links the previously generated private key with the issued certificate and removes the pending request [5]. While a matching request is outstanding, no `-user` or `-machine` option is needed; without one, you must specify the context [5]. After `certreq -accept`, the certificate is in the computer's **Personal** store [6]; after the IIS dialog, in the store you chose [3]. Binding it to a site, importing intermediates and checking the result are the next steps of the IIS installation guide. ## Common mistakes - **1024-bit key.** The IIS 7 wizard default [1] is below the 2048-bit minimum; an authority must reject the request [4]. - **Only one name.** The wizard has no field for subject alternative names [1]; for `example.com` and `www.example.com` together, use certreq. - **Request on one server, response on another.** Complete it where the request was made [2], then move the certificate and key as a PFX file. - **Certificate present, key missing.** If the key is still on the server, `certutil -repairstore` repairs a key association [11]; if it is not, request again. Servers configured with key files, such as when you [install an SSL certificate on Apache](/install/apache/), create the key and request with OpenSSL instead and keep both as files. ## FAQ **Where is the private key stored for an IIS CSR request?** On the server that created the request, and not in the CSR [9]. Microsoft states that the response installs only on that computer [2]. In the Windows enrollment API the key waits with a placeholder certificate in the request store until the response is installed [8]. **How do I get the CSR from IIS?** The wizard writes it to the file name you enter on its last page [1]. Open that file in a text editor and copy the whole text, including the `BEGIN` and `END` lines. **Can I convert a CSR to a PFX?** No. A CSR carries the public key and no private key [9], while a PFX holds the certificate together with its private key [11]. Complete the request first; then `certutil -exportPFX` exports the certificate and its key into a PFX file [11], provided the key was created exportable [5]. **How do I view a CSR before submitting it?** Run `certutil -dump example.com.req` on Windows [11] and check the names and key length it shows. ## Sources 1. Microsoft Learn, [Request an Internet Server Certificate (IIS 7)](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732906%28v=ws.10%29): wizard pages, providers and default bit lengths. 2. Microsoft Learn, Install an Internet Server Certificate (IIS 7): the response installs only on the computer that sent the request. 3. Microsoft Learn, PowerScribe One SSL certificate renewal: the IIS 10 Complete Certificate Request dialog. 4. [CA/Browser Forum Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/documents/), version 2.3.1: §6.1.1.3 subscriber key pair generation, §6.1.5 key sizes, §7.1.2.7.2 and §7.1.2.7.4 domain- and organisation-validated subject attributes, §7.1.2.7.6 subscriber certificate extensions, §7.1.4.3 common name. 5. Microsoft Learn, [certreq](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1): `-new`, `-accept`, `-machine`, `-unicode`, INF keys. 6. Microsoft Learn, Enable LDAP over SSL with a third-party certification authority: example request INF, `certreq -new`, `certreq -accept`, Personal store. 7. Microsoft Learn, Obtain a certificate for use with Windows Servers and System Center Operations Manager: SHA256 INF, Certificate Enrollment Requests. 8. Microsoft Learn, IX509Enrollment::CreateRequest and IX509Enrollment::InstallResponse. 9. IETF, RFC 2986, PKCS #10: Certification Request Syntax Specification, version 1.7. 10. Microsoft Learn, How to: View certificates with the MMC snap-in. 11. Microsoft Learn, certutil: `-dump`, `-repairstore`, `-exportPFX`. 12. IETF, RFC 7468, Textual Encodings of PKIX, PKCS, and CMS Structures, section 7. **Continue in this section** - [Install an SSL certificate on IIS](/install/iis/) — Install a certificate on IIS: complete a request or import a PFX, add the https binding with SNI, do it in PowerShell, and keep it bound after renewal. - [Install an SSL certificate on Apache](/install/apache/) — The three directives Apache needs, where each of them goes, and the version difference deciding whether the chain lives in a separate file or not. - [Installing an SSL certificate: steps for any server](/install/) — Installation is the same five steps on every server. Most failures are one of those five left incomplete, and three outside checks find which. --- https://bridge-ssl.com/install/import-export-certificate/ --- # Export and import a certificate with its private key To export and import a certificate between servers, move it together with its private key. On Windows the pair travels as a PFX file, the PKCS #12 format defined in [RFC 7292](https://www.rfc-editor.org/rfc/rfc7292): a transfer syntax for private keys and certificates that can protect them with a password [1]. You export the SSL certificate on the server that holds the key and import it on the new one; what each server needs after that is covered in [installing SSL certificates](/install/). One condition decides whether this works: the key has to be exportable. Servers such as nginx and Apache read PEM files instead of a PFX, and OpenSSL converts between the two in both directions [5]. - **File** — PFX (PKCS #12): the certificate, its private key and, if you include it, the chain [1][2] - **Export on Windows** — `certlm.msc`, `certutil -exportPFX` or `Export-PfxCertificate` [2][6][7] - **Import on Windows** — `certlm.msc`, `certutil -importPFX` or `Import-PfxCertificate` [3][6][8] - **Condition** — the private key is marked as exportable [2] - **To and from PEM** — `openssl pkcs12` [5] ## Can the key be exported? Check this first, on the server where the certificate is installed. In the export wizard, **Yes, export the private key** appears only if the key is marked as exportable and you have access to it [2]. Microsoft states that a key is exportable only when the certificate request or template asked for it [2]. On import, each tool sets the same flag in its own way: | Where the key came from | Exportable afterwards | |---|---| | Certificate request or template | only if the request or template specified it [2] | | Certificate Import Wizard | only with **Mark key as exportable** selected [3] | | `Import-PfxCertificate` | only with `-Exportable` [8] | | `certutil -importPFX` | non-exportable with the `NoExport` modifier [6] | If the key is locked, the wizard does not offer the option [2], and Microsoft's example for exporting a whole store needs every key in it to be exportable [7]. Request a new certificate on the target server instead. Which request tools on IIS let you mark the key exportable is covered where you [generate a CSR in IIS](/install/iis/csr/). ## Export a PFX on Windows Exporting an SSL certificate issued to a computer takes an administrator, or a user given the right permissions [2]. On IIS a server certificate sits in the Local Computer store. `certlm.msc` opens that store; `certmgr.msc` opens the Current User store of your own account [4]. | | Certificates console | certutil | PowerShell | |---|---|---|---| | Export | **All Tasks**, **Export** [2] | `-exportPFX` [6] | `Export-PfxCertificate` [7] | | Chain | a checkbox in the wizard [2] | `NoChain` leaves it out, `NoRoot` only the root [6] | included unless `-ChainOption EndEntityCertOnly` [7] | | Key encryption | not among the documented steps [2] | `CryptoAlgorithm=` TripleDES-Sha1 or Aes256-Sha256 [6] | TripleDES_SHA1 by default, or AES256_SHA256 [7] | ### In the Certificates console 1. Run `certlm.msc` [4], expand **Personal** and select **Certificates** [2]. 2. Select the certificate. On the **Action** menu, point to **All Tasks** and click **Export** [2]. 3. Choose **Yes, export the private key**. If the option is missing, the key is not exportable or you cannot access it [2]. 4. Select **Include all certificates in the certification path if possible**. Leave **Delete the private key if the export is successful** cleared [2]. 5. Type a password twice, then a path for the `.pfx` file, and click **Finish** [2]. The certificate stays in the store after the export. Microsoft documents this wizard for Windows 7 and Windows Server 2008 R2. Strong protection is on by default and is not compatible with some programs; for a key you will use with one of them, clear **Enable strong protection** [2]. ### With PowerShell or certutil Run PowerShell as an administrator. As in Microsoft's example, the identifier at the end of the path selects one certificate; without it, the command takes every certificate in the store [7]: ``` $password = Read-Host -AsSecureString Get-ChildItem -Path Cert:\LocalMachine\My\5F98EBBFE735CDDAE00E33E0FD69050EF9220254 | Export-PfxCertificate -FilePath C:\certs\example.com.pfx -Password $password ``` `Read-Host -AsSecureString` shows asterisks while you type and returns a SecureString, the type `-Password` takes [9][7]. `Export-PfxCertificate` includes the whole chain and the extended properties, and encrypts the private key with TripleDES_SHA1 unless you pass `-CryptoAlgorithmOption AES256_SHA256` [7]. certutil accepts the subject common name as the certificate ID. A name can match more than one certificate; a SHA-1 certificate hash is another accepted ID [6]: ``` certutil -p -exportPFX My example.com C:\certs\example.com.pfx ``` certutil works on the machine certificate store; `-user` switches it to your own [6]. ## Import the PFX on the target server Copy the file to the new server. Importing certificates for a web server means the Local Computer store, not your own. 1. In `certlm.msc`, select **Personal**. On the **Action** menu, point to **All Tasks** and click **Import** [3]. 2. Select the `.pfx` file and type its password [3]. 3. Select **Mark key as exportable** only if you will move or back up this key again [3]. 4. Choose **Place all certificates in the following store** and pick **Personal**, or let the wizard select the store by certificate type [3]. The wizard also offers **Enable strong private key protection**, which prompts for a password every time the private key is used [3]. The same import in PowerShell: ``` $password = Read-Host -AsSecureString Import-PfxCertificate -FilePath C:\certs\example.com.pfx -CertStoreLocation Cert:\LocalMachine\My -Password $password ``` The key arrives non-exportable unless you add `-Exportable` [8]. With certutil, `certutil -p -importPFX My C:\certs\example.com.pfx NoExport` does the same and keeps the key locked [6]. The PFX file stays where it was after the import [3]; delete it once it is no longer needed. Binding the imported certificate to a site is the next step for [an SSL certificate on IIS](/install/iis/). ## PFX to PEM files for nginx or Apache To take a certificate from Windows to Linux, split the PFX into three PEM files: the certificate, its intermediates and the key: ``` $ openssl pkcs12 -in example.com.pfx -clcerts -nokeys -out example.com.crt $ openssl pkcs12 -in example.com.pfx -cacerts -nokeys -out intermediate.crt $ openssl pkcs12 -in example.com.pfx -nocerts -noenc -out example.com.key ``` Each command asks for the import password. `-clcerts` writes only the certificate that belongs to the private key. Without it, OpenSSL writes every certificate in file order, and nothing guarantees the first one is the key's [5]. `-cacerts` writes the CA certificates, here the intermediate. `-noenc` writes the key without encryption; it replaces `-nodes`, deprecated since OpenSSL 3.0 [5]. Protect `example.com.key` as you would the PFX. Each output file opens with `Bag Attributes` lines above the `-----BEGIN` line; for the certificate and the key they hold the local key ID and the friendly name. [RFC 7468](https://www.rfc-editor.org/rfc/rfc7468) permits text before that line and requires parsers to handle it [10]. Where the files go next depends on the server: see how to [install an SSL certificate on Apache](/install/apache/) or [install an SSL certificate on nginx](/install/nginx/). The certificate formats themselves are explained in the formats guide of the certificates section. ## PEM files to a PFX for Windows For the other direction, assemble the three PEM files into one PFX. `-inkey` takes the private key [5]: ``` $ openssl pkcs12 -export -out example.com.pfx -inkey example.com.key -in example.com.crt -certfile intermediate.crt -name example.com Enter Export Password: Verifying - Enter Export Password: ``` `-certfile` adds the intermediate, and `-name` sets the friendly name that importing software shows [5]. Import the result into the certificate store as described above. ### Which algorithms the file uses OpenSSL 3.0 encrypts the key and the certificates with AES-256-CBC and PBKDF2 by default. `-info` shows the algorithms and iteration counts a file uses [5]; on Windows, `certutil -dumpPFX` dumps its structure [6]. On the lab file built above: ``` $ openssl pkcs12 -in example.com.pfx -info -noout Enter Import Password: MAC: sha256, Iteration 2048 MAC length: 32, salt length: 8 PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256 Certificate bag Certificate bag PKCS7 Data Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256 ``` The two certificate bags are the certificate and the intermediate; the shrouded keybag is the private key, encrypted [1]. With `-legacy`, OpenSSL uses the legacy algorithms instead: 3DES for the key, RC2 or 3DES for the certificates, depending on the build [5]. A file with RC2-40 certificate encryption, like the lab's `-legacy` file, fails in OpenSSL 3.0 without the flag: ``` $ openssl pkcs12 -in legacy.pfx -info -noout Enter Import Password: MAC: sha1, Iteration 2048 MAC length: 20, salt length: 8 PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Error outputting keys and certificates 40A73845A8720000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:386:Global default library context, Algorithm (RC2-40-CBC : 0), Properties () ``` With `-legacy` the same command reads it, as the manual advises for RC2-40-CBC [5]. ## Common mistakes - **No key option in the wizard.** The key is not exportable, or your account cannot access it [2]. - **Key deleted on export.** **Delete the private key if the export is successful** removes the key from the source server [2]. - **Chain left out.** Without **Include all certificates in the certification path**, the intermediates are not included [2]; `-ChainOption EndEntityCertOnly` and `NoChain` drop them on purpose [7][6]. - **Wrong store.** `certmgr.msc` and `Cert:\CurrentUser\My` belong to one user account [4][8]. - **Files left behind.** The PFX stays on disk after import [3], and the key from `-noenc` has no password at all [5]. ## FAQ **How do I create a PFX file from a CRT and a key?** Run `openssl pkcs12 -export -out example.com.pfx -inkey example.com.key -in example.com.crt -certfile intermediate.crt` and set an export password [5]. **How do I extract the private key from a PFX file?** Run `openssl pkcs12 -in example.com.pfx -nocerts -noenc -out example.com.key`. The key is written without a password [5]. **How do I get a PFX file from a Windows server?** Export the certificate with its private key in `certlm.msc` or with `Export-PfxCertificate`, on the server that holds the key [2][7]. This works only if the key is exportable [2]. ## Sources 1. IETF, RFC 7292, PKCS #12: Personal Information Exchange Syntax v1.1. 2. Microsoft Learn, [Export a Certificate with the Private Key](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754329%28v=ws.11%29): exportable keys, wizard options. 3. Microsoft Learn, Import a Certificate: Mark key as exportable, store selection. 4. Microsoft Learn, How to: View certificates with the MMC snap-in. 5. OpenSSL, [openssl-pkcs12](https://docs.openssl.org/3.0/man1/openssl-pkcs12/) manual page, version 3.0. 6. Microsoft Learn, certutil: `-exportPFX`, `-importPFX`. 7. Microsoft Learn, [Export-PfxCertificate](https://learn.microsoft.com/en-us/powershell/module/pki/export-pfxcertificate). 8. Microsoft Learn, Import-PfxCertificate. 9. Microsoft Learn, Read-Host. 10. IETF, RFC 7468, Textual Encodings of PKIX, PKCS, and CMS Structures, section 2. **Continue in this section** - [Install an SSL certificate on IIS](/install/iis/) — Install an SSL certificate on IIS 10: complete the request or import a PFX, add the https binding with SNI, and rebind after every renewal. - [Install an SSL certificate on nginx](/install/nginx/) — Configure nginx for HTTPS: the chain file, listen 443 ssl, http2, TLS versions, the HTTP redirect, testing, and TLS in front of an application. - [Install an SSL certificate on Apache](/install/apache/) — The three directives Apache needs, where each of them goes, and the version difference deciding whether the chain lives in a separate file or not. --- https://bridge-ssl.com/about/ --- # About Bridge SSL: who writes this, and how it is checked Bridge SSL is the certificate layer of Bridge CDN, and this site is its documentation: how certificates and encrypted connections work, written by the team that operates them. This page says who writes the material and how it is checked, because documentation you might act on should be willing to answer that. ## Who writes this The Bridge CDN team writes this site, and the same team builds the platform it describes. Pages are published under the team rather than under individual names: accuracy is a shared responsibility here, and a page is held to the same standard whoever drafted it. ## How this site is written and checked Four rules govern what gets published, and they explain absences you may notice. - Protocol behaviour is traced to specifications. Where a page says how certificates or connections behave, that comes from the standards rather than from repetition, and a specification number appears with a link where it helps a reader. - Values that change are dated or omitted. Certificate lifetimes, rate limits, deprecation deadlines and browser behaviour all move. Where a figure cannot be attributed to a source and dated, the page describes the mechanism and leaves the number out. - Product claims are kept apart from protocol claims. How encryption works and what Bridge CDN does are different kinds of statement, and the second kind is checked against the product before it is published. - Boundaries are respected. Certificate pages cover certificates. Questions that belong to naming or to delivery are named as such and left to the sites that cover them. ## What you will not find here - Configuration that ages badly. Server pages give the directives that have been stable for years and leave out protocol and cipher settings, which change on schedules set by browser vendors. A page listing exactly which ciphers to enable would be wrong within a year and would be followed anyway. - Instructions built on interface names. Where a platform renames its menus, an instruction written around those names breaks, so pages describe actions and models instead. - Comparisons that pretend the other side has no strengths. Where a page compares, the other option’s advantages come first, and where the honest answer is that the choice barely matters, the page says so. ## Corrections Every page shows when its text last changed, and that date moves when the text does. A specific report about one sentence is worth more than a general impression, and a technical correction is applied on its merits whoever sends it. ## Contact Bridge SSL has no separate contact address. The team is reached through [Bridge CDN](https://bridge-cdn.com/), where the product and the account live, and reports about this site go the same way. ## The platform Bridge SSL is not sold on its own: certificate issuance and renewal are part of a Bridge CDN account, run by the team that writes this site. Wildcards follow the same rule: there is no separate [wildcard SSL certificate to buy](/free-wildcard-ssl/), and *.example.com is issued when the domain’s DNS is on Bridge DNS. Technical pages describe how certificates work without reference to any provider, and product statements appear as product statements. Several pages argue against paying for things that do not differ, and one argues that automated renewal does not remove the need for an independent check. If a page ever reads as though a protocol fact were a reason to buy something, that is a defect worth reporting. ## Where to start Three entry points cover most of the material: [SSL errors](/errors/) if something is broken right now, [certificates](/certificates/) for what they contain and how the lifecycle works, and [ACME](/acme/) for automated issuance and renewal. If you are installing for the first time, [installation](/install/) covers the five steps that apply on every server. ## FAQ **Who writes Bridge SSL documentation?** The Bridge CDN team, the same people who build the platform, which is why the pages describe failures from the side that has to repair them. Material is published under the team rather than under individual names, so responsibility for a correction sits with the team that can make it. **Why do some pages not give specific numbers?** Because the numbers in this subject move: certificate lifetimes, issuance limits and vendor deadlines all change on schedules nobody here controls. Where a figure cannot be attributed to a source and dated, the page describes the mechanism that produces it instead, since the mechanism outlasts the value. **Why is there no cipher configuration here?** Because configuration advice ages faster than anything else in this subject and is still followed years later. A setting that was correct when written can weaken a server once vendors move, and nothing in a copied block says when it was written. **How do I report a mistake?** Through Bridge CDN, which is where the team is reached. A report that quotes the sentence and says what is wrong with it is the fastest to act on, and every page shows when its text last changed. **Is the documentation independent of the product?** The technical pages describe how certificates and connections behave without reference to any provider, because the behaviour is the same whoever issues them. Where a statement is about Bridge CDN rather than about the technology, it is presented as such and kept apart from the explanation. --- https://bridge-ssl.com/privacy/ --- # Privacy: what this site stores and sends bridge-ssl.com sets no cookies, runs no analytics or advertising scripts, and loads nothing from other domains. The one thing it keeps in your browser is the colour theme you choose. ## What this site keeps in your browser When you switch between the light and dark theme, the choice is saved in your browser’s local storage, so the next page opens in the same theme. It stays on your device, the page does not send it anywhere, and clearing this site’s data in your browser removes it. ## What this site does not do - No cookies. No page sets one. - No analytics or advertising. There are no tracking pixels, analytics scripts or advertising scripts. - No third-party resources. Scripts, styles and fonts are served from this domain, so loading a page does not contact anyone else. - No forms. Nothing you type on this site is submitted to it. ## Checks you run yourself The checks described under [tools](/tools/) run with standard software on your own machine. Nothing about your certificates or keys is submitted to this site. ## Requests to the server Like any website, the server that delivers these pages receives each request, including the address it came from and the page asked for. Questions about how such records are handled go to [Bridge CDN](https://bridge-cdn.com/). ## Names in certificates are public This is a property of the certificate system rather than of this site: publicly trusted certificates are recorded in public logs, including the names they cover. See [certificate transparency](/glossary/certificate- transparency/). ## Bridge CDN accounts Signing up, the account and the certificates issued for your domains are part of [Bridge CDN](https://bridge-cdn.com/), and Bridge CDN’s own terms govern that data. This page covers bridge-ssl.com only.