Webserver & Dienste

TLS-Zertifikate automatisieren, bevor die kurzen Laufzeiten dich einholen

Mit sinkenden Laufzeiten ist manuelle Zertifikatsverwaltung endgültig erledigt. Wer ACME nicht automatisiert, tauscht künftig alle paar Wochen von Hand, und genau dabei passieren die Ausfälle.

6 Kapitel mit allen Befehlen
Administrator konfiguriert einen Webserver am Laptop
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum manuelles Zertifikatsmanagement gerade kippt

Solange ein Zertifikat ein Jahr oder länger galt, war der Kalendereintrag ein akzeptables Verfahren. Jemand hat einmal im Jahr einen CSR erzeugt, die Datei per Ticket bei der CA eingereicht, das Ergebnis auf die Webserver kopiert und neu geladen. Mit 200 Tagen wird daraus ein halbjährlicher Pflichttermin, mit 47 Tagen ein Vorgang, der etwa achtmal im Jahr auf jedem betroffenen System ansteht. Bei zwanzig Hostnamen, verteilt auf Reverse Proxies, Mailserver, interne Portale und ein paar Appliances, ist das keine Fleißaufgabe mehr, sondern ein Ausfallrisiko.

In der Praxis scheitert es selten am Ausstellen selbst. Es scheitert daran, dass niemand vollständig weiß, wo überall Zertifikate liegen. Das gleiche Zertifikat steckt in /etc/nginx/ssl, im Java-Keystore der Anwendung, im HAProxy-PEM mit angehängtem Private Key, im Postfix und in der Firmware eines Load Balancers, der sich nur über eine Weboberfläche befüllen lässt. Die Erneuerung läuft dann durch, aber der Dienst hält das alte Zertifikat weiter im Speicher, weil der Reload fehlt.

Typische Fehler sind schnell aufgezählt: certbot renew läuft, aber der deploy-hook wurde nie geschrieben. Die HTTP-01-Challenge bricht, weil ein Redirect von HTTP auf HTTPS auch /.well-known/acme-challenge/ erfasst. Die DNS-01-Challenge scheitert an einem API-Token mit zu weiten Rechten oder an einer zu hohen TTL. Der Cronjob läuft als falscher Benutzer und darf den Private Key nicht lesen. Und das Monitoring meldet den Ablauf erst, wenn die Nutzer schon anrufen.

Miniatur-Szene: Webserver-Turm mit umkreisendem Globus, ein- und ausgehende Anfragepfeile, Zertifikatskarte
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Der Weg vom manuellen Zertifikat zur automatischen Erneuerung

  1. 01 Bestand und Ablaufdaten erfassen
  2. 02 ACME-Client und Challenge festlegen
  3. 03 Erneuerung per systemd-Timer
  4. 04 Deploy-Hook mit Reload je Dienst
  5. 05 Ablauf-Monitoring mit Schwellwert
  6. 06 Ausrollen über Konfigurationsmanagement
Was du mitnimmst

So sieht eine tragfähige Automatisierung aus

Das Ziel ist ein Ablauf, der ohne menschlichen Eingriff funktioniert und trotzdem nachvollziehbar bleibt. Die folgenden Punkte beschreiben die Bausteine, in der Reihenfolge, in der du sie sinnvoll angehst.

Bestand aufnehmen und Verantwortlichkeiten klären

Erfasse jeden Endpunkt mit Hostname, Aussteller, Ablaufdatum, Speicherort und Reload-Kommando. Ein Skript, das mit openssl s_client -connect host:443 und openssl x509 -noout -enddate über eine Liste läuft, liefert dir in einer Stunde mehr Klarheit als jede Wiki-Seite. Trenne dabei sauber zwischen öffentlich vertrauenswürdigen Zertifikaten und internen, denn nur erstere sind von den verkürzten Laufzeiten betroffen.

ACME-Client und Challenge-Typ bewusst wählen

Certbot ist der verbreitetste Client und in allen gängigen Distributionen paketiert, acme.sh kommt als Shell-Skript ohne Python-Abhängigkeiten aus und lässt sich auf Appliances und in schlanken Containern leichter unterbringen. Für einzelne Webserver reicht HTTP-01, für Wildcards und für Systeme ohne Port 80 aus dem Internet brauchst du DNS-01 mit einem Provider-Hook. Wenn deine DNS-Zone das hergibt, ist ein delegierter CNAME auf eine eigene Acme-Zone der sauberste Weg, weil das API-Token dann nur diese eine Zone ändern darf.

Erneuerung über systemd-Timer statt Cron fahren

Der certbot.timer beziehungsweise ein eigener Timer mit RandomizedDelaySec verteilt die Anfragen und vermeidet, dass alle Systeme zur vollen Stunde gleichzeitig bei der CA anklopfen. Persistent=true holt verpasste Läufe nach einem Reboot nach. Mit systemctl list-timers und journalctl -u certbot-renew siehst du jederzeit, wann zuletzt erneuert wurde, und du bekommst über OnFailure eine echte Fehlermeldung statt einer verschluckten Cron-Mail.

Deploy-Hooks schreiben, die den Dienst wirklich neu laden

Ein erneuertes Zertifikat auf der Platte nützt nichts, solange der Prozess das alte im Speicher hält. Hinterlege pro Dienst einen Hook, der die Dateien an den Zielort bringt, Besitzer und Modus setzt und dann nginx -s reload, apachectl graceful oder systemctl reload postfix ausführt. Wichtig ist ein vorgeschalteter Konfigurationstest wie nginx -t, damit ein Fehler nicht erst beim Reload auffällt. Für Java-Anwendungen gehört die Umwandlung in PKCS#12 mit openssl pkcs12 -export in denselben Hook.

Ablauf aktiv überwachen statt auf Mails der CA zu vertrauen

Prüfe die Restlaufzeit an dem Punkt, an dem der Client sie sieht, also über eine TLS-Verbindung zum Endpunkt und nicht über die Datei im Dateisystem. Der check_http-Check von Nagios oder Naemon kann das mit -C, Prometheus liefert es über den Blackbox Exporter als probe_ssl_earliest_cert_expiry, Zabbix bringt einen eigenen Item-Typ mit. Setz die Warnschwelle deutlich vor dem Ablauf, bei 47-Tage-Zertifikaten sind zehn bis vierzehn Tage ein brauchbarer Wert.

Interne CA und Konfigurationsmanagement mitdenken

Für interne Dienste, die nie ein öffentliches Zertifikat brauchen, ist eine eigene CA mit ACME-Schnittstelle wie step-ca oder eine Microsoft-CA mit automatischer Enrollment-Strecke oft der ruhigere Weg. Die Verteilung von Hooks, Timern und Trust-Stores gehört anschließend in Ansible oder ein vergleichbares Werkzeug, damit ein neu ausgerollter Host die Automatisierung von Anfang an mitbringt und nicht nachträglich von Hand nachgerüstet wird.

Tutorial

Von der Bestandsaufnahme bis zum überwachten Deploy-Hook

Zuerst findest du heraus, welche Zertifikate es überhaupt gibt, denn genau die vergessenen laufen ab. Danach legst du Client und Challenge fest, baust die Erneuerung als systemd-Timer, schreibst den Hook, der den Dienst wirklich neu lädt, und überwachst am Ende das Ergebnis von außen.

01

Bestand automatisiert erfassen

Die Zertifikate, die dich nachts wecken, stehen in keiner Liste. Solche Zertifikate sitzen im Monitoring-Agenten, im internen Wiki und auf dem Gerät, das seit Jahren niemand angefasst hat.

Ablaufdaten aller Hosts einsammeln
while read -r host; do
  ende=$(openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate | cut -d= -f2)
  printf '%-40s %s\n' "$host" "${ende:-KEINE ANTWORT}"
done < hosts.txt

# Dienste mit STARTTLS gehören genauso auf die Liste
openssl s_client -connect mail.example.com:25 -starttls smtp </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject

-servername ist Pflicht, sobald mehrere virtuelle Hosts hinter einer Adresse liegen. Ohne SNI bekommst du das Standardzertifikat des Servers und wunderst dich über den falschen Namen.

Lokal abgelegte Zertifikate finden
sudo find /etc /opt /srv -type f \( -name '*.pem' -o -name '*.crt' -o -name '*.cer' \) \
  -exec sh -c 'openssl x509 -noout -subject -enddate -in "$1" 2>/dev/null \
    && echo "    Datei: $1"' _ {} \;

Der Fund ist regelmäßig größer als erwartet. Trage jedes gefundene Zertifikat mit Ablaufdatum, verantwortlicher Person und Erneuerungsweg in eine Liste ein, bevor du mit der Automatisierung anfängst.

02

Client und Challenge bewusst festlegen

Die Challenge entscheidet, welche Systeme du überhaupt automatisieren kannst. Damit ist die Challenge die eigentliche Weichenstellung, der Client ist Geschmackssache.

Challenge-Typen im Vergleich

TypBrauchtPasst fürFällt aus bei
HTTP-01Port 80 von außen erreichbar, Pfad /.well-known/acme-challenge/Öffentliche WebserverWildcards und Systeme ohne öffentlichen Port 80
DNS-01API-Zugang zum DNS-AnbieterWildcards, interne Systeme, Dienste ohne WebserverDNS-Zonen, die nur per Ticket geändert werden
TLS-ALPN-01Port 443, der Dienst muss den Handshake selbst übernehmenUmgebungen, in denen Port 80 geschlossen bleibtVorgeschaltete Proxys, die TLS terminieren
/etc/nginx/snippets/acme.conf, ein Challenge-Pfad für alle vHosts
location ^~ /.well-known/acme-challenge/ {
    root /var/www/acme;
    default_type "text/plain";
}

Mit ^~ gewinnt dieser Block gegen reguläre Ausdrücke, die sonst Anfragen an ein Backend weiterreichen. Binde das Snippet in jeden vHost ein, dann brauchst du je Domain nichts Eigenes mehr.

Ausstellung mit certbot und mit acme.sh
sudo mkdir -p /var/www/acme
sudo certbot certonly --webroot -w /var/www/acme \
  -d example.com -d www.example.com \
  --key-type ecdsa --agree-tos -m ssl@example.com --no-eff-email
sudo certbot certificates

# Wildcard geht nur über DNS-01
acme.sh --issue --dns dns_cf --server letsencrypt \
  -d intern.example.com -d '*.intern.example.com' --keylength ec-256

Die Zugangsdaten für die DNS-API übergibst du als Umgebungsvariable, acme.sh merkt sie sich für die Erneuerung. Lege dafür ein eigenes Token an, niemals den Hauptzugang des Kontos.

03

Erneuerung über systemd-Timer fahren

Die Erneuerung läuft zweimal täglich, nicht monatlich. Der Client entscheidet selbst, ob es Zeit ist, und du gewinnst dadurch viele Versuche, bevor es eng wird.

Prüfen, was schon läuft
systemctl list-timers 'certbot*' --all
systemctl cat certbot.timer
sudo certbot renew --dry-run

# Bei acme.sh liegt der Aufruf standardmäßig in der Crontab des Benutzers
crontab -l | grep acme

Die Paketvarianten von certbot bringen den Timer meist mit. Prüfe trotzdem, ob er aktiv ist. Ein installierter, aber nie aktivierter Timer ist die häufigste Ursache für abgelaufene Zertifikate auf Systemen, die eigentlich automatisiert sind.

Eigener Timer, wenn du den Ablauf selbst steuerst
# /etc/systemd/system/acme-renew.service
[Unit]
Description=ACME-Zertifikate erneuern
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet

# /etc/systemd/system/acme-renew.timer
[Unit]
Description=Prueft zweimal taeglich auf faellige Erneuerungen

[Timer]
OnCalendar=*-*-* 03,15:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target

RandomizedDelaySec verteilt die Anfragen und verhindert, dass alle deine Server zur selben Sekunde bei der CA anklopfen. Persistent=true holt einen Lauf nach, wenn die Maschine zur geplanten Zeit aus war. Aktiviert wird der Timer, nicht der Service.

Erneuert wird erst, wenn ein Schwellwert der Restlaufzeit unterschritten ist. Bei kürzeren Zertifikatslaufzeiten rückt dieser Punkt entsprechend näher heran, und aktuelle Clients fragen zusätzlich die Erneuerungsempfehlung der CA ab. Deshalb ist der zweimal tägliche Lauf kein Übereifer, sondern die Voraussetzung dafür, dass eine gescheiterte Erneuerung noch dutzende Male wiederholt werden kann, bevor jemand etwas merkt.

04

Deploy-Hooks, die den Dienst wirklich neu laden

Die häufigste Ursache für ein abgelaufenes Zertifikat auf einem automatisierten System: Die Datei ist neu, der Prozess hält die alte Version im Speicher.

/etc/letsencrypt/renewal-hooks/deploy/10-reload.sh
#!/bin/sh
set -eu

case "$RENEWED_LINEAGE" in
  */www.example.com)
    systemctl reload nginx
    ;;
  */mail.example.com)
    install -o root -g dovecot -m 0640 "$RENEWED_LINEAGE/privkey.pem"   /etc/dovecot/tls/privkey.pem
    install -o root -g root    -m 0644 "$RENEWED_LINEAGE/fullchain.pem" /etc/dovecot/tls/fullchain.pem
    systemctl reload dovecot postfix
    ;;
  */lb.example.com)
    cat "$RENEWED_LINEAGE/fullchain.pem" "$RENEWED_LINEAGE/privkey.pem" \
      > /etc/haproxy/certs/example.pem
    chmod 0600 /etc/haproxy/certs/example.pem
    systemctl reload haproxy
    ;;
esac

$RENEWED_LINEAGE zeigt auf das Verzeichnis unter /etc/letsencrypt/live/, das gerade erneuert wurde. Vergiss chmod +x nicht, ein nicht ausführbarer Hook wird stillschweigend übergangen.

Der Unterschied zwischen den Hook-Arten ist wichtig: Ein deploy-Hook läuft ausschließlich nach einer tatsächlichen Erneuerung, ein post-Hook nach jedem Versuch. Wer den Neustart in den post-Hook legt, lädt seine Dienste zweimal täglich ohne Grund neu.

Hook testen, ohne auf die Erneuerung zu warten
sudo chmod 0755 /etc/letsencrypt/renewal-hooks/deploy/10-reload.sh
sudo certbot renew --force-renewal --cert-name www.example.com
sudo journalctl -u nginx --since '-5 min'

--force-renewal zieht ein neues Zertifikat, auch wenn das alte noch lange gültig ist. Nutze das sparsam, denn die Ausstellungsgrenzen der CA gelten pro Zeitraum und Domain.

05

Ablauf von außen überwachen

Die Erinnerungsmail der CA ist kein Monitoring. Let's Encrypt hat den Versand solcher Ablaufhinweise eingestellt, und bei kurzen Laufzeiten wäre er ohnehin zu spät.

Zwei Prüfungen, die du brauchst
# 1. Die Datei auf der Platte: Exit-Code 1 bei weniger als 21 Tagen Restlaufzeit
openssl x509 -checkend $((21*86400)) -noout \
  -in /etc/letsencrypt/live/www.example.com/cert.pem \
  || echo 'Erneuerung überfällig'

# 2. Der laufende Dienst, von außen betrachtet
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -dates -issuer

Die zweite Prüfung ist die wichtigere. Die Datei kann längst erneuert sein, während der Prozess weiter das alte Zertifikat ausliefert. Genau dieser Fall entsteht bei einem fehlenden oder fehlerhaften Deploy-Hook.

Alarmregel mit Blackbox-Exporter
(probe_ssl_earliest_cert_expiry - time()) / 86400 < 14

Der Blackbox-Exporter prüft von außen und misst damit genau das, was Besucher sehen. Ergänze eine zweite Regel auf die Zeit seit dem letzten erfolgreichen Erneuerungslauf, dann fällt dir ein defekter Timer auf, bevor das Zertifikat knapp wird.

Damit der Alarm im Ernstfall hilft

  • Schwellwert bei 14 bis 21 Tagen, nicht bei drei.Du brauchst Zeit für Urlaub, Wochenende und eine Fehlersuche. Ein Alarm drei Tage vor Ablauf ist bereits ein Vorfall.
  • Von außen messen, nicht nur auf dem Server selbst.Nur so bemerkst du falsch ausgelieferte Ketten, vergessene Reloads und einen Proxy, der noch ein altes Zertifikat hält.
  • Alle TLS-Ports aufnehmen, nicht nur 443.Mailserver, LDAP, Datenbanken und Management-Oberflächen haben eigene Zertifikate. Genau die fehlen im Monitoring und laufen deshalb zuerst ab.
  • Auch die Zwischenzertifikate der Kette prüfen.Fehlt das Intermediate in der ausgelieferten Kette, funktioniert der Browser trotzdem, aber Java-Clients und Kommandozeilenwerkzeuge brechen mit Zertifikatsfehlern ab.
06

Interne Namen und Geräte ohne ACME

Für Hostnamen, die es öffentlich nicht gibt, stellt keine öffentliche CA ein Zertifikat aus. Der Weg führt über eine eigene CA, die selbst ACME spricht.

Interne CA mit ACME-Endpunkt
step ca init --name "Beispiel GmbH Interne CA" \
  --dns ca.intern.example.com --address :443
step ca provisioner add acme --type ACME

# Ab hier funktioniert derselbe Client wie im Internet
sudo certbot certonly --standalone \
  --server https://ca.intern.example.com/acme/acme/directory \
  -d monitoring.intern.example.com

Der Vorteil ist die Einheitlichkeit: dieselben Clients, dieselben Hooks, dieselben Timer für innen und außen. Halte die Laufzeit intern kurz, denn eine Automatisierung, die nur alle zwei Jahre läuft, ist beim nächsten Mal kaputt.

Wurzelzertifikat auf den Clients verankern
# Debian/Ubuntu
sudo cp intern-root.crt /usr/local/share/ca-certificates/intern-root.crt
sudo update-ca-certificates

# RHEL/Rocky/Alma
sudo cp intern-root.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

# Kontrolle
openssl s_client -connect monitoring.intern.example.com:443 </dev/null 2>/dev/null | head -20

Rolle das Wurzelzertifikat über dein Konfigurationsmanagement aus, nicht von Hand. Ein Server, dem es fehlt, meldet Zertifikatsfehler, die wie ein Problem der Gegenstelle aussehen.

Für Geräte, die kein ACME können, bleibt der zentrale Weg: Zertifikat auf einem Automatisierungsserver ausstellen und per Ansible oder über die Verwaltungsschnittstelle des Geräts einspielen. Wo auch das nicht geht, gehört ein Reverse Proxy davor, der die TLS-Verbindung übernimmt. Das Gerät spricht dann intern unverschlüsselt oder mit einem langlebigen internen Zertifikat, und die kurze Laufzeit nach außen verwaltet der Proxy.

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Passender Lernpfad

Karrierepfad

Linux Webserver Administrator

In diesem Lernpfad baust du Schritt für Schritt das Know-how auf, um Linux-basierte Webserver sicher, stabil und effizient zu betreiben. Du lernst, wie du typische Webserver-Dienste installierst, konfigurierst und im Alltag zuverlässig administrierst, von der ersten Bereitstellung bis zum laufenden Betrieb. Im Senior Level lernst du das notwendige Wissen was über die reine Webserver Administration hinausgeht. 

Gut zu wissen

Häufige Fragen zu TLS-Automatisierung mit ACME

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Ab wann gelten welche maximalen Laufzeiten für TLS-Zertifikate?
Die Verkürzung erfolgt in mehreren Stufen. Seit dem 15. März 2026 liegt die Obergrenze bei 200 Tagen, in der nächsten Stufe sinkt sie auf 100 Tage und in der letzten Stufe im Jahr 2029 auf 47 Tage. Betroffen sind öffentlich vertrauenswürdige Zertifikate, also alles, dem Browser und Betriebssysteme ohne eigenen Trust-Store-Eingriff vertrauen sollen. Zertifikate aus einer internen CA sind davon nicht erfasst, dort legst du die Laufzeit selbst fest.
Certbot oder acme.sh, was passt besser?
Beide sprechen dasselbe ACME-Protokoll, der Unterschied liegt in der Integration. Certbot ist in Python geschrieben, in den Repositories von Debian, Ubuntu, RHEL und SUSE vorhanden und bringt Plugins für Apache und NGINX mit, die die Konfiguration selbst anpassen können. acme.sh ist ein reines Shell-Skript ohne nennenswerte Abhängigkeiten, läuft dadurch auch auf minimalen Systemen und deckt mit seinen DNS-Hooks sehr viele Provider ab. Wenn du ohnehin Distributionspakete bevorzugst, nimm Certbot, wenn du schlanke oder ungewöhnliche Systeme betreust, ist acme.sh meist der pragmatischere Weg.
Wie teste ich, ob die automatische Erneuerung wirklich funktioniert?
Mit certbot renew --dry-run läuft der komplette Vorgang gegen die Staging-Umgebung der CA, inklusive Challenge, ohne dass Rate Limits verbraucht oder Zertifikate ausgestellt werden. Der Test deckt allerdings nicht ab, ob dein Deploy-Hook den Dienst korrekt neu lädt, deshalb solltest du den Hook zusätzlich einmal von Hand ausführen und danach mit openssl s_client -connect host:443 prüfen, welches Zertifikat der Server tatsächlich ausliefert.
Warum schlägt die HTTP-01-Challenge fehl, obwohl der Webserver läuft?
Der häufigste Grund ist ein pauschaler Redirect von HTTP auf HTTPS, der auch den Pfad /.well-known/acme-challenge/ erfasst. Nimm diesen Pfad im Server-Block explizit vom Redirect aus. Weitere typische Ursachen sind eine Firewall oder ein WAF vor dem System, das Port 80 nur intern erlaubt, ein DNS-Eintrag, der auf einen anderen Host als den erneuernden zeigt, und Berechtigungen im Webroot, die den ACME-Client die Challenge-Datei nicht schreiben lassen.
Was mache ich mit Systemen, die keinen ACME-Client unterstützen?
Bei Appliances und Geräten ohne Shell-Zugriff läuft die Erneuerung auf einem zentralen Host, der das Zertifikat anschließend über die Management-API oder per SCP auf das Zielsystem schiebt und dort einen Reload auslöst. Wo es gar keine Schnittstelle gibt, ist ein vorgelagerter Reverse Proxy meist die bessere Antwort: Die TLS-Terminierung passiert dann auf einem System, das du automatisieren kannst, und die Appliance bleibt hinter dem Proxy.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Erwartungen wurden erfüllt. Angekündigte Themen in hinreichender Tiefe bearbeitet. Zudem gutes Zeitmanagement.
Rückmeldung aus dem Kurs „Source Code Management und CI / CD (DO4)“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Zertifikatsautomatisierung im Kurs durchspielen

Wenn du ACME, Deploy-Hooks und Monitoring nicht nebenbei im Produktivbetrieb erarbeiten willst, üben wir das mit dir an laufenden Systemen. In der NGINX Webserver Administration und in Apache Webserver einrichten und administrieren unter Linux richtest du TLS-Terminierung und automatische Erneuerung selbst ein, der Linux Security Intensivkurs ordnet das Ganze in Schlüsselverwaltung, interne CA und Härtung ein. Alle Kurse gibt es als Präsenztermin und Live-Online, auf Wunsch auch als Inhouse-Schulung mit deiner Umgebung als Ausgangspunkt. Melde dich, dann klären wir gemeinsam, welcher Kurs zu deinem Stand passt.