The padlock, and why you never have to think about it
Every app on the Node Platform answers over HTTPS from its first request, behind its own certificate, and that certificate renews itself before it expires. This page explains what is actually behind the browser padlock, why certificate expiry still takes real businesses offline, and how we made the whole problem disappear. It is part of our Under the hood series, where we explain the technology the platform stands on.
What a TLS certificate is
HTTPS is ordinary web traffic wrapped in TLS, the encryption layer that stops anyone between a browser and a server from reading or tampering with what passes. The padlock in the address bar means two distinct things at once: the connection is encrypted, and the server has proved it really is the site named in the address, not an impostor.
That proof is the certificate: a signed digital document saying "the holder of this key controls this domain", issued by a certificate authority that browsers are built to trust. Certificates deliberately expire, typically within months, so a stolen key or a stale proof of control cannot be abused for years.
Expiry is where the trouble has always lived. A certificate is invisible while valid and catastrophic the day it lapses: browsers greet every visitor with a full-page warning, and to your customers the site is simply down. Some of the best-known outages on the web have been exactly this, at organisations with no shortage of engineers, because a renewal that depends on a human and a calendar reminder will eventually meet a holiday.
Let's Encrypt, and the automation of trust
For the web's first two decades, certificates were bought from commercial authorities: a yearly fee per certificate, a manual verification dance, a file to install by hand. The cost and the friction meant much of the web simply went without encryption.
Let's Encrypt changed that. Run by the Internet Security Research Group (ISRG), a nonprofit, it issues certificates free of charge to anyone who can prove control of a domain. The proof is the clever part: a protocol called ACME (Automatic Certificate Management Environment) lets a server demonstrate control by answering a cryptographic challenge, entirely machine to machine, with no forms and no waiting. ACME is published as an open internet standard, RFC 8555, so anyone can implement it.
Let's Encrypt's default certificates last 90 days, and it recommends renewing around every 60. That short lifetime is a feature: it shrinks the window in which a compromised key is useful, and it makes manual renewal so tedious that automation becomes the only sane approach. The design assumes machines, not people, will do the renewing.
The buying question: whose calendar is my certificate on?
If you host anywhere, this is the question worth asking: when this certificate needs renewing, what exactly happens? If the answer involves a person, a reminder, or an annual invoice from a certificate vendor, you are one missed email away from a Saturday outage. If the answer is "software renews it automatically, and the renewal is monitored", the failure mode has been designed out rather than delegated to diligence.
On this platform, the answer is the second one, for every app, as standard.
How Node runs it
Our apps run on Kubernetes, and certificates there are managed by cert-manager, an open source certificate controller and a graduated project of the Cloud Native Computing Foundation. Its job description matches ours exactly: it obtains TLS certificates for workloads and renews them before they expire.
When an app is deployed into your workspace, its public hostname is declared alongside it, and cert-manager takes over: it requests a certificate from Let's Encrypt over ACME, answers the domain-control challenge, and installs the result so the app is served over HTTPS from the outset, each app behind its own certificate. Well before the 90 days are up, it renews without being asked. Like everything on the platform, the machinery is monitored, so an engineer would hear about a failed renewal long before a browser would.
The practical effect is an absence. Deploy Nextcloud and it answers on HTTPS from the first request; the same is true of every app in the catalogue. There is no certificate to buy, no renewal date to diarise, no configuration step to forget. Encryption in transit is simply a property of being hosted here, which is how we think it should be.
Automatic HTTPS is one layer of a platform we are happy to show you in full: the tour is at How the Node Platform is built, and the rest of this series lives at Under the hood. Curious how any of it works in your case? Ask us anything and an engineer will answer.
Frequently asked questions
What happens when a TLS certificate expires?
Browsers refuse the connection and show visitors a full-page security warning, so to your customers the site is down, even though the software behind it is running perfectly. Expiry is one of the most common self-inflicted outages on the web, which is why we designed humans out of the renewal loop entirely: on our platform certificates are renewed automatically, well before their expiry date.
Why do Let's Encrypt certificates only last 90 days?
It is deliberate. Let's Encrypt's default certificates are valid for 90 days, and it recommends renewing them around every 60. A short lifetime limits how long a stolen key stays useful, and it makes manual renewal so impractical that automation stops being optional. That trade only works if renewal is genuinely automatic, which on our platform it is.
Do I pay extra for certificates?
No. Let's Encrypt does not charge for certificates, and we do not either: issuance and renewal are simply part of how an app is deployed here. The era of paying a yearly fee per certificate, then paying again in staff time to install it, is one the web has thankfully left behind.
What is ACME?
The Automatic Certificate Management Environment: the protocol Let's Encrypt created so software could request certificates without a human filling in forms. Your server proves it controls a domain by answering a challenge, and the certificate authority issues the certificate, all machine to machine. It is published as an open internet standard, RFC 8555, and it is what our platform speaks when it requests and renews certificates.
Who is behind Let's Encrypt?
The Internet Security Research Group (ISRG), a nonprofit whose stated aim is a more secure and privacy-respecting web. Let's Encrypt issues certificates free of charge to anyone who can prove control of a domain, and in doing so moved most of the web from unencrypted HTTP to HTTPS in under a decade.