Domain2026-08-05·7 min read

SSL certificate renewal for Australian small businesses

For most small-business sites, SSL certificate renewal is automatic and invisible - Let’s Encrypt certs renew every 90 days. A manual renewal or expiry warning is the tell.

For most Australian small businesses, SSL certificate renewal is no longer a task you do - it’s a thing that happens to you:

  • Auto-renewal is the norm - modern certificates from Let’s Encrypt last 90 days and are renewed by your host or CDN roughly every 60 days, with no human involved.
  • Shorter lifetimes by design - the maximum certificate validity is capped at 397 days and falling, which is precisely why manual renewal is being engineered out and automation is mandatory.
  • Manual renewal is the exception - you only act by hand if you bought a paid certificate or run a self-managed server that nobody configured to auto-renew.
  • An expiry warning is a broken pipe - a “certificate has expired” message means the automation didn’t run, not that you forgot something.

The fix is never to renew once and move on - it’s to find out why renewal wasn’t automatic and make it automatic.

For most small-business websites, SSL certificate renewal should be automatic and invisible - modern certificates from Let's Encrypt and similar issuers renew themselves every 90 days, handled by your host or CDN without anyone touching anything. If you find yourself renewing manually, or you're staring at a "your certificate has expired" warning, the real problem isn't that you forgot a task - it's that the automation that should be doing this for you isn't set up, or it broke.

Why renewal should be automatic now

The certificate that proves your site is who it says it is - and that turns the padlock on and the "not secure" label off - used to be a once-a-year purchase you renewed by hand. That model is dying, on purpose.

Let's Encrypt, the free non-profit certificate authority that now secures a large share of the web, issues certificates that last 90 days and are designed to be renewed by software, not people. The short lifespan is the whole point: if a certificate is only valid for 3 months, a stolen or mis-issued one stops being useful quickly. Reissuing every 90 days by hand would be miserable, so the entire ecosystem assumes a machine does it. Your host renews it roughly every 60 days - well before the 90-day expiry - and you never see it happen.

This is not a niche arrangement. If your site runs on Squarespace, Wix, Shopify, WordPress.com, Webflow, most Australian shared-hosting cPanel accounts, or sits behind Cloudflare, the certificate is almost certainly auto-issued and auto-renewed already. You didn't choose it and you don't manage it, which is exactly how it should be.

The trend is moving further this direction, not back. The maximum lifetime a certificate authority is allowed to issue has been falling for years - it's now capped at 397 days, and the industry has already agreed to drive it down toward 47 days over the next few years. Every step shorter makes manual renewal less viable and automation mandatory. So if your current process is "diarise it for next March and buy a new one", you are maintaining a habit the industry is actively engineering out of existence. The right move is to make sure renewal is automated, then forget about it.

If you want the background on what these certificates actually are and why the browser cares, SSL vs TLS explains the naming, and what "not secure" means in the browser covers the label that appears when one is missing.

How to check your certificate

You don't need any tools to confirm your certificate is healthy. Two ways:

Click the padlock. Open your site in a browser, click the padlock (or the tune/site-info icon) in the address bar, and look for "Connection is secure" → "Certificate is valid". You can see the issuer and the expiry date there. If the expiry is more than a few weeks out and creeping forward each time you look, automation is working.

Run a free checker. The SSL Labs server test takes a domain and returns a full report - issuer, expiry, the protocol versions you support, and a letter grade for the whole configuration. It's the same tool security professionals use, it's free, and it needs nothing installed. Aim for an A. If you're not sure how to read the result, what an SSL Labs grade means walks through the letters, and why SSL Labs flags old TLS explains the most common deduction - an outdated protocol version, which is a configuration problem, not a renewal one.

The useful habit isn't checking the expiry date obsessively. It's checking once, confirming the date is automatically marching forward, and then trusting it. A certificate that renewed itself last month will renew itself next month.

When you actually have to renew manually

Manual renewal is a real thing in two situations, and only two.

You bought a paid certificate. Some businesses still purchase certificates from a commercial authority - sometimes for an Organisation Validated or Extended Validation certificate that puts the verified company name in the certificate details, sometimes because a vendor or compliance checklist asked for one. These don't auto-renew on their own. You're issued a certificate, you install it, and when it nears expiry you buy and install a replacement. Because the industry maximum is now 397 days, even the longest paid certificate you can buy expires inside 13 months - the multi-year certificates some providers still advertise are sold as multi-year coverage you redeem one ≤397-day certificate at a time. If this is you, the renewal date belongs in a calendar with a fortnight of warning, because nobody else is watching it.

Your host doesn't automate it. A self-managed server - a VPS you rent and run yourself, an older on-premises box, a bespoke setup a developer built years ago - only auto-renews if someone configured it to. The standard fix is a tool called certbot (the Let's Encrypt client) running on a schedule, which converts the whole thing back into the invisible non-event it should be. On a Windows server - where certbot is a less natural fit than it is on Linux - Certify The Web is a well-regarded ACME client that does the same job behind a proper interface and is worth a look; we have no relationship with them. If you're paying for a managed server and renewal still isn't automatic, that's a reasonable thing to ask your provider to fix.

Everyone else - which is most small businesses - does nothing. If you're on a mainstream website builder or hosting plan and you've never installed a certificate in your life, that's not an oversight. It's the system working.

What an expiry warning really means

A browser warning - "your connection is not private", "this site's certificate has expired", a red strikethrough on the padlock - feels like you did something wrong. You almost certainly didn't. It means the automation that was supposed to renew the certificate didn't run, or never existed.

Common causes, in rough order of likelihood: the certificate was never on auto-renewal in the first place (a one-off manual install that quietly lapsed); a renewal script on a self-managed server stopped running or started failing silently; a domain or DNS change broke the automated check the renewal depends on; or a paid certificate hit its expiry date with nobody watching the calendar. Notice that every one of these is an automation failure, not a moral one.

So the fix is never "renew it once and move on" - that just resets the same clock to break again later. The fix is to find out why it wasn't automatic and make it automatic. On a managed platform, that usually means a support ticket asking them to reissue and confirm auto-renewal is on. On your own server, it means getting certbot's scheduled renewal working and tested. Manually reinstalling a certificate without fixing the automation guarantees you'll be back here in 90 days, or 397, with the same warning and a worse mood.

One thing worth ruling out first: if the warning says the certificate is for the wrong domain name, or your browser clock is simply set to the wrong date, that's a different problem entirely - not an expiry.

When this isn't enough

A valid, auto-renewing certificate is the floor, not the ceiling. It proves the connection is encrypted and the site is who it claims to be. It says nothing about whether you're running an outdated protocol version, whether your domain is protected against the records being tampered with, or whether your email is forgeable - all of which sit alongside the certificate in the same trust story but renew on none of the same plumbing.

This is the same pattern as the domain underneath it. Knowing which Australian domain registrar to use and picking the best Australian domain registrar sets up who renews your name and controls the settings the certificate depends on - and the same security basics that get neglected there get neglected here. Most Australian small businesses, for instance, never turn on the records that stop their domain's answers being spoofed: why most Australian SMBs have no DNSSEC is the closest cousin to a lapsed certificate - a free protection nobody enabled.

The way to know where you stand on all of it at once is to look from the outside, the way an attacker or a customer's browser does. Run your domain through our scan: the Security category checks the certificate and the protocol versions behind it, and the Domain category checks the records the certificate sits on top of - graded against the baseline of other Australian small businesses, so you can see whether "the padlock is green" is actually the end of the story or just the beginning.

#domain#australian-business#small-business