Certifikat-rotation uden nedetid: reload, load balancere og Kubernetes

Et nyt certifikat er kun halvdelen af arbejdet — det skal også tages i brug uden at afbryde brugernes forbindelser. Forskellen mellem en graceful reload og en hård restart afgør om rotationen er usynlig eller mærkes som et udfald. Her er hvordan du roterer certifikater uden nedetid på nginx, Apache, bag en load balancer og i Kubernetes.

Kort svar

Roter et certifikat uden nedetid ved at lægge de nye filer på plads og bede tjenesten om en graceful reload i stedet for en restart. En reload starter nye worker-processer med det nye certifikat, mens eksisterende forbindelser får lov at afslutte på de gamle. nginx (nginx -s reload) og Apache (apachectl graceful) understøtter det indbygget. Bag en load balancer roterer du én node ad gangen; i Kubernetes opdaterer du den Secret der monteres i pod'en.

Reload vs restart — den afgørende forskel

En restart dræber processen og åbner den igen: alle aktive TLS-forbindelser afbrydes, og der er et kort vindue hvor porten ikke lytter. En reload (graceful) beder masterprocessen om at starte nye workers med den nye konfiguration og certifikat, mens de gamle workers håndterer igangværende forbindelser færdigt. Brugerne mærker intet.

nginx: graceful reload

Læg fullchain og nøgle på plads, test konfigurationen, og send reload-signalet:

# Verificér at konfiguration og certifikater er gyldige FØR reload
sudo nginx -t

# Graceful reload — nye workers med nyt certifikat, gamle drænes
sudo nginx -s reload
# (svarer til: sudo systemctl reload nginx)

Springer du nginx -t over og certifikatfilen er korrupt, fejler reload'en og den gamle proces kører videre — irriterende, men ikke et udfald. Verificér altid bagefter at det nye certifikat faktisk serveres. Se den fulde TLS-opsætning på nginx.

Apache: graceful

# Tjek syntaks først
sudo apachectl configtest

# Graceful: afslut igangværende requests, genindlæs derefter
sudo apachectl graceful
# (svarer til: sudo systemctl reload apache2 / httpd)

Apache's graceful lader hver child-proces afslutte sit aktuelle request før den genindlæses med det nye certifikat. Detaljer i guiden til TLS på Apache.

Bag en load balancer: rolling rotation

Når TLS termineres på en pulje af backends, roterer du dem én ad gangen for at undgå at tage hele tjenesten ned:

Tag node 1 ud af load balancerens pulje (drain).
Læg det nye certifikat på og reload tjenesten på node 1.
Verificér at node 1 serverer det nye certifikat korrekt.
Sæt node 1 tilbage i puljen, og gentag for node 2, 3 …

Termineres TLS derimod på selve load balanceren (offloading), opdaterer du certifikatet ét sted — men vær opmærksom på hvordan rotationen sker på netop den platform; se offloading vs passthrough vs bridging.

Kubernetes: opdatér en Secret, ikke en fil

I Kubernetes ligger certifikatet i en TLS-Secret. Med cert-manager opdateres den automatisk ved fornyelse. Ingress-controllere (fx ingress-nginx) opdager ændringen og genindlæser uden restart. For pods der monterer secret'en som en volume, propageres den nye fil typisk inden for omkring et minut — men en applikation der læser certifikatet ind i hukommelsen ved opstart skal genindlæses:

# Se certifikatet i en TLS-secret
kubectl get secret example-tls -o jsonpath='{.data.tls\.crt}' \
  | base64 -d | openssl x509 -noout -dates

# Rullende genstart hvis appen cacher certifikatet ved opstart
kubectl rollout restart deployment/web -n web

Bruger I mTLS mellem services, se mTLS i Kubernetes.

Den klassiske fælde: fornyet, men aldrig reloadet

Den hyppigste årsag til at et "fornyet" certifikat alligevel udløber for brugerne, er at tjenesten aldrig blev reloadet — den kører stadig det gamle certifikat fra hukommelsen. ACME-klienter har derfor en deploy hook:

# certbot: kør reload kun når et certifikat faktisk blev fornyet
sudo certbot renew --deploy-hook "systemctl reload nginx"

Sådan bekræfter CertControl at rotationen lykkedes

Selve rotationen er én ting; at bekræfte udefra at det nye certifikat faktisk serveres er en anden. CertControl scanner endpointet efter rotationen og ser den nye udløbsdato, det rigtige serienummer og den fulde kæde — så I opdager med det samme hvis en node i puljen, en ingress eller en cachende app stadig kører det gamle certifikat.

Ofte stillede spørgsmål

Hvad er forskellen på reload og restart?

En restart dræber og genstarter processen og afbryder alle aktive forbindelser. En reload (graceful) starter nye worker-processer med det nye certifikat, mens gamle forbindelser afsluttes pænt. Til certifikat-rotation bruger du altid reload.

Mister jeg aktive forbindelser ved nginx -s reload?

Nej. nginx starter nye workers med det nye certifikat og lader de gamle håndtere igangværende forbindelser færdigt, før de lukkes. Eksisterende sessioner brydes ikke.

Hvordan roterer jeg certifikater bag en load balancer?

Termineres TLS på backends, roterer du dem én ad gangen (drain, opdatér, reload, verificér, sæt tilbage). Termineres TLS på selve load balanceren, opdaterer du certifikatet ét sted ifølge platformens metode.

Skal jeg genstarte pods i Kubernetes efter en fornyelse?

Kun hvis applikationen læser certifikatet ind i hukommelsen ved opstart. Ingress-controllere genindlæser automatisk når TLS-secret'en ændres; volume-monterede secrets opdateres typisk inden for et minut.

Hvorfor udløber mit certifikat selvom jeg fornyede det?

Næsten altid fordi tjenesten ikke blev reloadet og stadig serverer det gamle certifikat fra hukommelsen. Brug en deploy hook (fx certbot --deploy-hook) der reloader automatisk efter en fornyelse.

Se platformen Book demo