Bridge SSL · part of Bridge CDN

A certificate that never expires on you. Issued where the site is served, renewed without you, and a record that says when.

A browser warning has no grace period: the day a certificate runs out, every visitor sees it at once. Bridge CDN issues the certificate in the same layer that serves your site, renews it ahead of expiry, and writes down when it did. 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.

What it costs

Zero for the certificate. Zero for the wildcard.
The account you already have pays for both.

Here$0

Certificate and *.example.com issued and renewed for you, inside the Bridge CDN account.

Commercial authoritiesSold

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.

Before anything else

If this is not your site,
nothing on this page fixes it.

Stated first, because it is the assumption that costs people the most time. A certificate error is the site’s to fix, not the visitor’s. 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 Removed
NET::ERR_CERT_COMMON_NAME_INVALID Chrome, Edge Your connection is not private Site owner Removed
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 Removed

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.

The full error library Every code browsers print, what each one actually means, who can fix it, and a column saying whether Bridge SSL closes it, answered one row at a time.

Where you are now

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.

Renewal is a calendar entry

Waiting for someone to remember

Certificate held on the server. Renewal depends on a job, a person, or both.

  • 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.

Renewal is the serving layer’s job

Renewed where it is served

Certificate issued and used in the same place. Nothing travels, so nothing is left behind.

  • 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 it works

The certificate never travels.
That is the whole mechanism.

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.

Authoritysigns Your laptopdownload bundle Server diskcopy, assemble chain Running serviceedit config, reload ×wrong file, expired link ×chain incomplete ×renewed, never reloaded Three handovers between signing and serving. Each one is a place the certificate can be on disk and still not be the one presented. then again before expiry Authoritysigns Edge · Bridge CDNissued · held · presentedone place, no copy BrowserTLS handshake proof of control presented on every request ✓renewed here, ahead of expiry, written down The certificate is used where it is issued. There is no second location for it to be stale in.
  1. 1
    You → Bridge CDNAdd the domain
  2. 2
    Edge → AuthorityProves control of the name. HTTP‑01 for a hostname; DNS‑01 for a wildcard, with the record placed and removed by the platform
  3. 3
    Authority → EdgeSigned certificate
  4. 4
    Edge → BrowserPresented 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, and the reason is in the questions below: 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.


Doing it yourself, counted

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. The point is that all nine of them are handovers between you and the server, and a handover is the only place this can break.

The usual procedure 9 steps · then again before expiry
  1. 1 Generate a private key
  2. 2 Create a signing request
  3. 3 Buy the certificate
  4. 4 Prove you control the name
  5. 5 Download the bundle
  6. 6 Copy it onto the server
  7. 7 Assemble the chain
  8. 8 Edit the server config
  9. 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. 1 Install the client on the server
  2. 2 Prove control of the name
  3. 3 Point the server at the files it wrote
  4. 4 Reload the service
  5. 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. 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 server9each one a place it can break · then again before expiry
Handovers, with an ACME client5two of them repeat, silently, with every renewal
Handovers on Bridge SSL0one 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.

The renewal window

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.

day 0 · issuedday 60 · renewal windowday 90 · expiry By hand reminder? · depends on a person warning for every visitor ACME job job fires? · silent if not reload? · separate step Edge renewed ✓ presented ✓ written down
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.

Which is why the monitor should not be that layer either.

Same ninety days on every route. What changes is whether anything on the line can go wrong without being written down.


Scope, stated exactly

A wildcard covers exactly one label.
Here too.

*.example.com 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. The wildcard issued here is *.example.com, and it stops where every wildcard stops. Names one level deeper are outside it, and this page does not claim otherwise.

One asterisk, one label, on every authority, and on this one. Said here so it is not discovered after a DNS change.


Alongside the alternatives

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, and leaving that out would be dishonest.

Source: Cloudflare — Universal SSL. Commercial issuers referenced by their published product pages: DigiCert, GlobalSign, Sectigo, GoDaddy. Checked .


Is this you

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, and it is better to know that now than after a DNS change.

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.

Better said here

Four things this deliberately does not do.
Better said here than discovered later.

You cannot bring your own certificate

There is no 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 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.


Certificate log

How you know it happened.

Every issue and renewal is written down. 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.
TimeHostnameEventValid toOutcome
Mar 02 03:14example.comissuedJun 01presented
Mar 02 03:14*.example.comissuedJun 01presented · warmed on add
Mar 02 03:20api.example.comfirst request—served by *.example.com
Mar 09 10:41example.orgissuedJun 08presented
Mar 09 10:41*.example.orgissuedJun 08presented · DNS‑01, record removed
May 02 03:14example.comrenewedAug 01presented
May 02 03:14*.example.comrenewedAug 01presented
May 09 10:42*.example.orgrenewal attemptJun 08authority: 503, retry queued
May 09 11:12*.example.orgrenewed on retryAug 08presented
May 14 11:02shop.example.comadded—covered by *.example.com
Jul 02 03:14example.comrenewedOct 01presented
Jul 02 03:14*.example.comrenewedOct 01presented
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.

Alongside, not instead

Three layers, three questions,
one account.

DNS answers where the name points.

Bridge DNS holds the records; for a wildcard, that is also 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.

Browserasks for a name Bridge DNS · where the name pointsrecords · DNS‑01 proof placed and removed here Bridge SSL · whether the browser trusts itcertificate issued, held, presented · TLS ends here Bridge CDN · who serves the requestcache, route, deliver Your originunchanged 1. resolve 2. handshake 3. fetch

Keep the monitor. Keep the origin. The certificate is the part that stops being yours to carry.


Sections

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.

ACME 1 page

ACME lets software obtain and renew certificates without a person. See how the protocol works, what the challenges prove, and what…

TLS 1 page

Between clicking a link and seeing a padlock, two sides agree how to talk and one proves who it is. See the order of events and…


Questions

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?

It is written down: 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; the reason is in the next answer.

Do I still need to monitor certificates?

Yes, and the reason is worth understanding. 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?

It 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. If your names go that deep, better to know it here than after a DNS change.

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; 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. There is no import path, and none is planned as a setting. If an existing certificate has to be used, this layer is the wrong fit and it is better to know that now.

What if I use another CDN or serve from my origin directly?

There is nothing here that can hold the key for a site served elsewhere. Bridge SSL is the certificate layer of Bridge CDN and works only for hostnames it serves.


Where this lives

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.