NZAI Security
SSL Certificate Management for NZ sites: lifecycle, renewal windows, expiry monitoring and recovery from expiry
Cyber Basics

SSL Certificate Management for NZ Sites

Guide Educators + General Updated 20 Sept 2026

Plain-English guide to SSL/TLS certificate management for NZ sites: the certificate lifecycle, renewal windows, expiry monitoring, and what to do when expired.

Written and reviewed by Feroze Ashraff Last reviewed Editorial standards

Quick answer

An SSL/TLS certificate is what makes HTTPS work, and it expires on a fixed date — usually every 90 days with Let's Encrypt, or 1–2 years with paid commercial CAs. When a certificate expires, browsers refuse to load the site and show a full-page warning. For New Zealand schools and small businesses, the modern best practice is to use Let's Encrypt (free, automatic, 90-day lifetime) with automated renewal — and to monitor the renewal so you find out about renewals failing before your visitors do.

If a certificate has already expired on your site, see the "What to do when a cert has expired" section below — but the practical recovery is to renew immediately, restart the web server so it picks up the new cert, and confirm with openssl s_client.

What an SSL/TLS certificate is

When a browser visits your site over HTTPS, the server presents a TLS certificate (often called an "SSL certificate" — SSL is the old name). The certificate is a small signed document that says three things:

  • Who the certificate was issued to — by domain name (e.g. nzaisecurity.com)
  • Who signed and vouches for it — by which Certificate Authority (e.g. Let's Encrypt, Sectigo, DigiCert)
  • Until when it is valid — by a fixed expiry date

The browser checks all three: does the cert cover the domain I'm visiting, do I trust the CA that signed it, and has it not expired. If all three check out, the padlock appears in the address bar and the TLS handshake proceeds.

If any check fails — wrong domain, untrusted CA, or the expiry date has passed — the browser blocks the page entirely. There is no "ignore the warning" path the browser offers; it's a hard stop. For a school or small-business site, an expired certificate means parents and prospective families see a scary red warning screen instead of your content.

The certificate lifecycle

A typical certificate passes through five stages:

1. Key generation. The server creates a public/private key pair (RSA 2048+ or ECDSA P-256 are current best practice). The private key never leaves the server.

2. Certificate Signing Request (CSR). A CSR is generated from the public key, containing the domain name and organisation details. The CSR is sent to a Certificate Authority.

3. CA validation. The CA verifies that the requester actually controls the domain. For DV (Domain Validation) certs, this is automated — typically a DNS TXT record or an HTTP file the requester places on the site. OV (Organisation Validation) and EV (Extended Validation) require additional identity verification.

4. Issuance. The CA returns a signed certificate and (typically) a chain of intermediate certificates. The server is configured with the leaf certificate and the chain.

5. Validity period. The certificate is now live. Browser clients will accept it until the expiry date. As expiry approaches, the server (or automated tooling) renews by repeating steps 2–4 and replacing the certificate on disk.

Modern best practice is a 90-day certificate lifetime — short enough that loss of the private key has limited blast radius, frequent enough that misconfigurations get caught quickly. Let's Encrypt, the free automated CA used by most modern sites, issues 90-day certs by default and expects you to automate renewal every 60 days.

Lifetime used to be 1–3 years. The CA/Browser Forum (the body that sets rules for publicly trusted CAs) cut it to 90 days maximum in 2026, and is moving toward 47 days by 2029 (1). The reason is automation: if you can only reliably automate renewal every 3 months, you want the lifetime to match — any longer and a renewal failure means a longer outage.

Renewal windows and the 90-day rhythm

If your site uses Let's Encrypt (or any automated 90-day CA), the renewal happens in the background:

  1. A scheduled task runs twice per day (certbot renew or equivalent)
  2. It checks whether any certificate is within 30 days of expiry
  3. If yes, it requests a new certificate from Let's Encrypt via the ACME protocol
  4. It validates the new certificate (DNS or HTTP-01 challenge)
  5. It writes the new certificate to disk and reloads the web server

For most servers with a working setup, this is invisible — the cert just rolls over. The failure modes are:

  • ACME validation fails — DNS misconfiguration, HTTP-01 endpoint blocked by the web server, port 80 closed, or rate-limit hit. The renewal fails silently if not monitored.
  • Disk write fails — out of disk space, permissions wrong, path moved by an upgrade.
  • Server reload fails — the new cert is on disk but nginx/Apache is still serving the old one. This is the most common cause of "the cert renewed but the browser still sees the old one" reports.

For automation details — including DNS-01 vs HTTP-01 and certbot configuration — see TLS Certificate Renewal Automation for NZ Sites.

What to do when a cert has expired

If a browser is already showing your visitors a certificate error:

Step 1 — Renew now. Whether you're on Let's Encrypt or a commercial CA, request a fresh certificate immediately:

sudo certbot renew --force-renewal

This bypasses the normal 30-day threshold and forces issuance now.

Step 2 — Replace the certificate on disk. Certbot usually places the new files in a directory named after your domain, under /etc/letsencrypt/live/. If your server is configured to point elsewhere, copy or symlink.

Step 3 — Restart the web server. Even if you replaced the cert, nginx/Apache reads certificates at startup. Reload:

sudo systemctl reload nginx    # or apache2

Step 4 — Verify the new cert is being served. From another machine:

echo | openssl s_client -connect yoursite.nz:443 -servername yoursite.nz 2>/dev/null | openssl x509 -noout -dates

The output should show the new notAfter date — about 90 days from now.

Step 5 — Investigate why the renewal failed in the first place. Common causes:

  • The scheduled task was not installed (or was removed during a server move)
  • DNS records changed and broke ACME validation
  • Port 80 became blocked by a CDN or WAF added later
  • Rate limit hit (Let's Encrypt allows ~50 certs per domain per week)
  • Cron jobs disabled during server hardening

If the renewal mechanism is unreliable, fix it before assuming the next 90-day cycle will work.

Monitoring that catches renewals before they fail

Three monitoring patterns, in increasing depth:

1. Free: external cert expiry check. Sites like SSL Labs and https://check-your-website.server-daten.de/ show you the cert expiry in days. Run them monthly, or subscribe to a free expiry-monitor service that emails you at 30, 14, and 7 days out.

2. Built-in: an ACME renewal hook. When certbot renew fails, it can run a hook script. The simplest hook sends you an email:

# /etc/letsencrypt/renewal-hooks/deploy/alert-failure.sh
#!/bin/bash
echo "Cert renewal failed for $RENEWED_DOMAINS" | mail -s "ALERT: certbot renewal" admin@yourschool.nz

3. Comprehensive: a server-side checker. A short script that runs daily, parses certbot certificates output, and reports anything under 21 days remaining:

certbot certificates | grep -E "Certificate Name|Expiry Date" | awk '/VALID:/{print $4, $5, $6}'

A school IT team running this on a daily cron and forwarding to a shared inbox catches problems 60+ days before browser visitors see them.

Treat "the cert looks fine" as an unverified claim until you've checked the expiry within the last 7 days. Many certificate outages happen because the renewal mechanism silently failed and no-one looked.

Special cases for New Zealand schools and small businesses

A few patterns that come up often in NZ deployments:

1. Shared hosting without root access. Most managed WordPress / cPanel / Plesk hosts run their own certificate automation, often via AutoSSL (cPanel) or Let's Encrypt plugins. You may not have control over the cert. In that case, monitor expiry via external services; if it expires, the right escalation is to the host's support team.

2. Multi-domain (SAN) certificates. New sites sometimes need one certificate to cover yourschool.nz and www.yourschool.nz, plus internal subdomains. Modern Let's Encrypt supports this via the -d flag (multiple separate certs) or wildcard certs via DNS-01. See the renewal automation article.

3. Certificates behind Cloudflare or a CDN. If you front your site with Cloudflare, the certificate the visitor sees is Cloudflare's edge cert, not your origin cert. Your origin cert still needs to be valid (otherwise the CDN-to-origin connection fails), but the visitor-facing expiry shown to users is Cloudflare's. Cloudflare's universal certificate auto-renews; set it and forget it for typical NZ sites.

4. Long-lived paid certificates. If you have a 1-year or 2-year commercial cert, switch to Let's Encrypt unless a specific vendor or compliance regime requires otherwise. The shorter lifetime with automation is more reliable than a longer one with manual renewal, and the cost saving is real for school and SMB budgets.

SSL Certificate Management for NZ sites — issuer, expiry and renewal monitoring for HTTPS websites

Common mistakes to avoid

  • Relying on a manual calendar reminder. Calendar reminders work until someone leaves the team, switches off notifications, or just forgets. Use automation.
  • Renewing at the wrong time. If you renew at 14 days out instead of 30, you've left only 14 days to fix any failure. Stay with the CA's recommended renewal threshold.
  • Storing the private key in a public repo. Keys occasionally leak via git, CI logs, or backup snapshots. Treat the private key as a credential, not a config value.
  • Mixing certs across multiple CAs. If you accidentally serve a Let's Encrypt cert where a commercial one was expected (or vice versa), browsers will still work, but you'll get intermittent trust errors on older devices.
  • Setting up one server, forgetting the others. A multi-server deployment needs every server to have the new cert at the same time. Renewal automation that only refreshes one node creates a partial outage that looks like random TLS errors.
Test that the renewal hook actually reloads your web server. Many outages come from the cert successfully being written to disk but the post-renewal systemctl reload step failing silently — usually a permissions or path issue in the deploy hook. Run a forced renewal in staging and watch the server log to confirm.

Knowledge check

Test your understanding of certificate management with these questions. Click or tap each card to flip it and see the answer.

Q1A parent calls: visitors to your school website see a full-screen certificate warning. You check the server; the cert is in /etc/letsencrypt/live/yourschool.nz/fullchain.pem and the date looks valid. What is the most likely cause?tap to flip
Answer: The new certificate is on disk but the web server is still serving the old one from startup. The renewal hook wrote the file but did not reload nginx/Apache (or the reload was interrupted). Run sudo systemctl reload nginx manually, then verify with openssl s_client. After restoring service, check why the post-renewal hook did not fire — almost always the script ran but exited non-zero, or the deploy-hook directory is not in the certbot config (1).
Q2You renew a Let's Encrypt cert manually with certbot renew --force-renewal and the new files appear on disk. But every visitor still sees the old cert in their browser, even after waiting 10 minutes. What layer is likely caching the old cert?tap to flip
Answer: Almost certainly the CDN or reverse proxy in front of the origin. Cloudflare, Fastly, Cloudfront and similar services terminate TLS at their edge and serve their own certificate to the visitor, with a separate (often pooled) connection back to your origin. Updating the cert on your origin does not change what the visitor sees. The fix is to update the edge certificate via the CDN's UI or API; for Let's Encrypt + Cloudflare, the universal certificate auto-renews but custom certificates need to be re-uploaded (2).
Q3Your cert expired two hours ago and parents are calling. You do not have root access to the server — the host manages it. What is the fastest correct response?tap to flip
Answer: Open a high-priority support ticket with the host immediately, stating the domain, the certificate expiry time, and the impact (full-page browser warning on every visitor). Most managed WordPress / cPanel / Plesk hosts will issue a new certificate within minutes once aware — AutoSSL is usually a one-click trigger the host can run. While waiting, set up a static "site temporarily unavailable" page via the host's control panel so visitors see a friendlier message than the default browser warning. Long term, ensure the host's automated renewal is enabled and add an external expiry monitor so you find out before the next renewal (3).

Sources and references

[1] CA/Browser Forum. (2026). Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. https://cabforum.org/baseline-requirements-documents/

[2] Let's Encrypt. (2025). Rate Limits. https://letsencrypt.org/docs/rate-limits/

[3] Mozilla. (2025). MDN Web Docs — Web security certificate. https://developer.mozilla.org/en-US/docs/Web/Security/Certificate

[4] Internet Security Research Group. (2025). Let's Encrypt — How it works. https://letsencrypt.org/how-it-works/

[5] CERT NZ. (2025). Critical controls for small organisations. https://www.cert.govt.nz/

What to do next