Who renews your PWA's SSL certificate?

The story is always the same. The site worked yesterday. Nobody touched anything — not the content, not the settings, not the code. And this morning, every visitor lands on a full-screen warning with a "Back to safety" button most of them are quick to click. Nothing is broken, strictly speaking: everything is still there, intact. A date went by, that's all.

Your app has a web face too: its PWA — the version of your app that opens in a browser, at your address, on your domain. That address is protected by the same mechanism as the rest of the web: a certificate. So the question this article answers fits in one line: that certificate has an end date; who takes care of the next one?

An SSL certificate — the name comes from the early days of the web; the protocol has long since been replaced by its successor, TLS, but "SSL" stuck — does two things: it proves that the address your user is visiting really is yours, and it encrypts the exchange. It's the padlock in the address bar.

And it expires. That's neither a flaw nor negligence: it's the security model. A stolen or compromised certificate is dangerous for as long as it remains valid — the shorter its life, the narrower the window. Let's Encrypt, the authority that secures a large share of the web, issues 90-day certificates on purpose.

And the pace is picking up. In 2025, the industry — browsers and certificate authorities, gathered in the CA/Browser Forum — adopted a stepped reduction of the maximum lifetime of public certificates: 398 days today, 200 in 2026, 100 in 2027, 47 days from March 2029. At that point, a certificate gets renewed roughly eight times a year. The web didn't just accept that certificates expire: it decided they would expire more and more often.

A date is only dangerous if nobody keeps the calendar. The industry just multiplied the dates.

Imagine maintaining your app and its infrastructure yourself. That calendar would be yours. Get the certificate, install it, prove at every renewal that the domain really is yours, do it all again before every deadline. Set up automation, of course — then watch the automation itself, because that's the classic of the genre: the renewal script that quietly stopped running months ago, discovered the morning the certificate expires. The warning emails, meanwhile, go to an address someone checks once a year.

At 90-day lifetimes, this is already an on-call duty. At 47 days, it changes nature: manual renewal stops being an option, even a bad one. Keeping that calendar becomes a job — or something you hand over to people whose job it is.

When you connect your domain name, its certificate is provisioned automatically — nothing to buy, nothing to install. Its expiration date is then tracked as part of the system's state, and the certificate is renewed ahead of the deadline: the incident isn't fixed quickly, it's anticipated. That's the whole difference between reacting to an outage and making sure it never happens.

It's also why this family of incidents lends itself so well to being taken care of: it's the most predictable failure in the world. Everything is dated, everything is known in advance. Someone just has to make it their job — every day, for every app at once, including when the deadlines start coming closer together.

The full map of who handles what is in the first article; for deadlines, it's short.

Your domain name. It's registered with your registrar, in your name — that's what makes it yours — and it comes up for renewal. An expired domain takes down everything that lives on it, however healthy the rest may be. That renewal can only come from you.

Your Apple and Google developer accounts. Same logic, same conclusion — they're in your name, and their dates are yours. The rule holds across this whole series: what's common to every app lives on the platform's side; what's registered in your name lives with you.

The benefit, as often in this series, is invisible: the padlock is in the address bar this morning, like yesterday, like at the next renewal — and there's nothing more to tell. While certificate lifetimes keep shrinking, the only thing that changes for you is: nothing.

For the engineering version of what expires and degrades over three years, the details are on dev.to. And if your app doesn't exist yet, you might as well build it where the calendar is kept for you: create my app with GoodBarber.

Do I need to buy an SSL certificate for my PWA?

With GoodBarber, no: when you connect your domain name, a certificate is provisioned automatically, then renewed ahead of every deadline. If you maintain your own infrastructure, obtaining it, installing it and renewing it — every time — is on you.

What happens when an SSL certificate expires?

Browsers show a full-screen warning — "Your connection is not private" — and most visitors turn back. Nothing is broken: the site and its content are intact; a date has simply passed. Getting back online means renewing the certificate; on a platform that keeps the calendar, the renewal comes before the date.

Why do SSL certificates expire faster and faster?

Because it's safer: a compromised certificate is dangerous for as long as it's valid, and a short life narrows that window. In 2025, the industry adopted a stepped reduction, from 398 days today to 47 days in 2029. The practical consequence: manual renewal becomes untenable, and automating the calendar stops being a comfort and becomes the only workable approach.

Is my native app affected?

The "Your connection is not private" screen is a browser story: it concerns your PWA and the web pages linked to your app. Your native app, installed from the stores, won't show it — but it communicates over encrypted connections too, and part of its calls rely on the same certificate as your PWA. The calendar this article describes covers it as well.