Capítulo 6 de 8

HTTPS in production

Renewal automation, shorter lifetimes, HSTS, monitoring and rollback.

Unos 11 minutos de lectura

Al terminar este capítulo podrá

  • Explain why manual renewal stopped being viable
  • Describe an ACME renewal pipeline including reload
  • Choose a safe rollout order for HSTS
  • List the external checks that catch real outages

01Why lifetimes keep shrinking

Certificate lifetimes are falling because short-lived certificates limit the damage of a leaked key, reduce reliance on revocation, and force automation that removes human error. A ninety-day certificate renews six times a year; a 47-day certificate renews roughly eight times, which is only practical if no human is involved.

LifetimeRenewals per yearRealistic process
398 days1Manual, with calendar reminders
90 days4-5Automated with monitoring
47 days8Automated end to end, no manual steps

02The renewal pipeline

  1. 1

    Detect

    A scheduler or agent notices the certificate is inside its renewal window.

  2. 2

    Obtain

    ACME (or an internal CA API) issues a new certificate using a challenge.

  3. 3

    Write

    The new certificate and key are written to the location the service reads.

  4. 4

    Reload

    The service is told to reload. This is the step that most often fails silently.

  5. 5

    Verify

    An external probe checks the served certificate serial and expiry, not just the local file.

  6. 6

    Alert

    Failure at any step raises an alert before expiry, with enough lead time to fix it.

03HSTS, rolled out safely

HTTP Strict Transport Security tells browsers to refuse plain HTTP for a domain for a period of time. It defends against downgrade and cookie-theft attacks, and it is unforgiving if you enable it too early.

  • Start with a short max-age and no includeSubDomains
  • Confirm every subdomain, including forgotten ones, serves valid HTTPS first
  • Only then raise max-age and add includeSubDomains
  • Keep the preload decision separate: preloading is effectively permanent

04Monitoring that catches reality

CheckCatches
Expiry from outsideRenewal or reload failures
Served certificate serialWrong file, wrong virtual host
Chain completeness from a strict clientMissing intermediate in one environment
Hostname match per environmentCopy-paste configuration drift
Protocol and cipher inventoryAccidental downgrade after a change

Monitor from the position a real client occupies: outside the network, using the same hostname the application uses, and more than one toolchain. A single 'it works in the browser' check hides most failures.

Para recordar

  • Shorter lifetimes exist to reduce risk and force automation
  • Renewal is only complete when the running service serves the new certificate
  • HSTS should be rolled out gradually and only after every subdomain is ready
  • External, multi-client monitoring catches the failures that internal checks miss