SSL-Zertifikate mit 47 Tagen Laufzeit: Erneuerung automatisieren, bevor sie nervt

/01SSL-Zertifikat-Laufzeit: was sich ändert und was nicht

Umgangssprachlich heißt es weiter SSL-Zertifikat, technisch ist es ein TLS-Serverzertifikat: Es bestätigt, dass ein Server für einen bestimmten Namen sprechen darf, und liefert den öffentlichen Schlüssel für den verschlüsselten Verbindungsaufbau. Was sich ändert, ist nicht die Verschlüsselung, sondern die Frist, nach der ein Zertifikat neu ausgestellt werden muss. Die Regeln dafür setzt das CA/Browser Forum, ein Zusammenschluss aus Zertifizierungsstellen und Browser-Herstellern, in seinen Baseline Requirements. Was dort steht, gilt für jedes öffentlich vertrauenswürdige Zertifikat, egal ob es von Let's Encrypt kommt oder von einer kommerziellen Zertifizierungsstelle für viel Geld gekauft wurde.

Was sich nicht ändert: Interne Zertifikate aus einer eigenen Zertifizierungsstelle, etwa einer Windows-PKI im Active Directory, fallen nicht unter diese Regeln. Auch Client-Zertifikate, Code-Signing und S/MIME sind ein anderes Thema. Es geht ausschließlich um die Zertifikate, mit denen Browser, Mail-Clients und Programme öffentlich erreichbare Server prüfen: Webseiten, Webmail, VPN-Portale, Remote-Desktop-Gateways, APIs.

Ehrlich: Für die Sicherheit ist die Verkürzung ein Gewinn. Ein kompromittierter Schlüssel ist kürzer nutzbar, und Validierungsdaten, die vor Monaten gegolten haben, dürfen nicht mehr ewig wiederverwendet werden. Für den Betrieb ist sie zunächst Arbeit. Eine Aufgabe, die einmal im Jahr anfiel und zur Not mit einer Kalendernotiz erledigt wurde, fällt künftig so oft an, dass Handarbeit nicht mehr trägt. Das ist keine Formsache, sondern eine Umstellung der Arbeitsweise: weg vom Zertifikat als Datei, die jemand einspielt, hin zur Zertifikatsverwaltung als Prozess, der von selbst läuft und nur bei Fehlern jemanden braucht.

/02Der Stufenplan bis 47 Tage

Beschlossen wurde die Verkürzung mit dem Ballot SC-081. Die Abstimmung fiel deutlich aus: 25 Zertifizierungsstellen stimmten mit Ja, keine mit Nein, fünf enthielten sich; auf Seite der Zertifikatsnutzer stimmten Apple, Google, Microsoft und Mozilla geschlossen zu. Seit Mai 2025 steht der Plan in den Baseline Requirements, aktuell in Version 2.3.1 vom 4. Oktober 2026. Er hat zwei Stellschrauben: die maximale Laufzeit eines Zertifikats und die Frist, wie lange eine einmal geprüfte Domain-Validierung für neue Zertifikate wiederverwendet werden darf.

Die Tabelle nennt die harten Obergrenzen. Die Regeln selbst sind einen Tag strenger formuliert: Ein Zertifikat ab dem 15.03.2029 soll nicht länger als 46 Tage gelten und darf nicht länger als 47 Tage gelten. Wer kauft, bekommt also eher die kürzere Zahl.

Unterschätzt wird meist die zweite Spalte. Bei einem gekauften Zertifikat prüft die Zertifizierungsstelle einmal, dass Sie die Domain kontrollieren, und stützt spätere Ausstellungen auf diese Prüfung. Ab dem 15.03.2029 darf sie dafür nur noch Daten verwenden, die höchstens zehn Tage alt sind. Damit verschwindet der Trick, bei dem einmal im Jahr jemand eine Bestätigungsmail anklickt und danach monatelang Zertifikate nachbestellt werden. Die Domain-Validierung wird Teil jeder Erneuerung, und genau das kann ACME von Haus aus.

Ein weiterer Stichtag betrifft das ACME-Konto selbst: Ab dem 15.03.2027 müssen Zertifizierungsstellen die CAA-Parameter accounturi und validationmethods nach RFC 8657 auswerten. Damit können Sie im DNS festlegen, dass für Ihre Domain nur ein bestimmtes ACME-Konto und nur bestimmte Validierungsmethoden Zertifikate bekommen. Das ist ein echter Sicherheitsgewinn, hat aber eine Kehrseite, die in Abschnitt 08 zur Sprache kommt.

/03Let's Encrypt heute: Profile, 90 und 45 Tage

Let's Encrypt geht schneller als die Mindestvorgaben. Die Zertifizierungsstelle arbeitet mit sogenannten Profilen, die ein ACME-Client beim Auftrag auswählen kann. Wer nichts angibt, bekommt das Standardprofil classic.

Parallel verkürzt Let's Encrypt die Wiederverwendung von Autorisierungen: heute 30 Tage, ab dem 10.02.2027 zehn Tage, ab dem 16.02.2028 nur noch sieben Stunden. Praktisch bedeutet das, dass jede Erneuerung ihre Challenge wieder erfolgreich bestehen muss. Ein Client, der nur deshalb funktioniert, weil eine alte Autorisierung noch gültig war, fällt dann auf.

Zwei Änderungen aus dem Jahr 2025 haben den Betrieb ebenfalls verschoben. Am 04.06.2025 hat Let's Encrypt die Hinweismails vor dem Ablauf eingestellt; die Begründung nennt ausdrücklich, dass inzwischen die meisten Kunden zuverlässig automatisiert erneuern, und den Datenschutz, weil dafür Millionen Mailadressen vorgehalten werden mussten. Wer sich bisher auf diese Mail als letzte Warnung verlassen hat, hat seit über einem Jahr keine mehr. Außerdem enthalten Zertifikate seit dem 07.05.2025 keine OCSP-Adresse mehr, und am 06.08.2025 wurden die OCSP-Responder abgeschaltet. Kurze Laufzeiten ersetzen in dieser Logik einen Teil der Sperrprüfung: Ein Zertifikat, das nach wenigen Wochen ohnehin abläuft, muss seltener aktiv gesperrt werden.

Für die Planung heißt das: Wer heute ein Let's-Encrypt-Zertifikat ohne Profilwunsch bezieht, hat bis Februar 2027 noch 90 Tage Spielraum. Wer seine Automatik schon jetzt gegen 45 Tage testen will, stellt einzelne Systeme bewusst auf tlsserver um und sieht, ob Erneuerung, Neuladen der Dienste und Überwachung im kürzeren Takt mitkommen.

/04ACME in Kürze: Konto, Auftrag, Challenge

ACME, das Automatic Certificate Management Environment, ist seit März 2019 als RFC 8555 standardisiert. Es beschreibt, wie ein Programm ohne menschliches Zutun ein Zertifikat beantragt, die Kontrolle über die Domain nachweist und das fertige Zertifikat abholt. Let's Encrypt hat das Verfahren groß gemacht, inzwischen sprechen es auch kommerzielle Zertifizierungsstellen. Der Ablauf hat vier Teile.

• Konto: Der Client erzeugt ein Schlüsselpaar und registriert damit ein ACME-Konto bei der Zertifizierungsstelle. Alle weiteren Anfragen signiert er mit diesem Kontoschlüssel. Das Konto ist damit selbst ein Geheimnis, das wie ein SSH-Schlüssel behandelt werden muss.
• Auftrag: Der Client bestellt ein Zertifikat für einen oder mehrere Namen. Die Zertifizierungsstelle antwortet mit einer Autorisierung je Name und den Challenges, die sie dafür akzeptiert.
• Challenge: Der Client weist die Kontrolle nach, entweder über eine Datei unter /.well-known/acme-challenge/ auf dem Webserver (HTTP-01) oder über einen TXT-Eintrag unter _acme-challenge im DNS (DNS-01).
• Ausstellung: Ist die Challenge bestanden, schickt der Client eine Zertifikatsanfrage, holt das Zertifikat ab, legt es ab und lädt den Dienst neu, der es verwendet.

Der letzte Schritt wird regelmäßig vergessen. Ein Client, der ein frisches Zertifikat auf die Platte schreibt, während der Webserver weiter das alte aus dem Speicher ausliefert, hat formal erneuert und praktisch nichts erreicht. Jeder ernsthafte ACME-Client hat deshalb einen Haken für das Nachladen: bei Certbot --deploy-hook, bei acme.sh --reloadcmd, bei win-acme Installationsskripte.

Welcher Client wohin gehört

Die rechte Spalte zeigt schon das Kernproblem: Viele Werkzeuge rechnen mit festen Tageszahlen, die für 90-Tage-Zertifikate gewählt wurden. Ein 45-Tage-Zertifikat, das ein Client nach Voreinstellung erst nach 55 Tagen anfasst, wäre längst abgelaufen. win-acme fängt das über die Untergrenze und ARI ab, andere Konfigurationen tun das nicht. Bevor ein System auf kürzere Laufzeiten wechselt, gehört deshalb jeder Client auf seine Erneuerungsschwelle geprüft.

/05DNS-01 oder HTTP-01: die richtige Validierung

Die Wahl der Challenge entscheidet mehr über den Betrieb als die Wahl des Clients. Let's Encrypt bietet drei Verfahren an, und jedes hat eine harte Grenze.

HTTP-01

Der Client legt eine Datei auf dem Webserver ab, die Zertifizierungsstelle ruft sie ab. Das funktioniert laut Let's Encrypt ausschließlich über Port 80, und es kann keine Wildcard-Zertifikate ausstellen. Der Vorteil: Es braucht keinen Zugriff auf das DNS. Der Nachteil: Der Server muss von außen auf Port 80 erreichbar sein, und zwar unter genau dem Namen, für den das Zertifikat gilt. Für interne Dienste scheidet HTTP-01 damit aus. Hinter einem Load Balancer mit mehreren Knoten muss die Challenge-Datei auf dem Knoten liegen, den die Prüfung gerade trifft, oder zentral beantwortet werden.

DNS-01

Der Client setzt einen TXT-Eintrag unter _acme-challenge.<name>. Das geht für Wildcards, für interne Namen, die in einer öffentlichen Zone stehen, und für Server, die gar nicht von außen erreichbar sind. Der Preis: Der Client braucht Schreibrechte auf das DNS, meist über die API des DNS-Anbieters. Let's Encrypt schreibt dazu nüchtern, dass API-Zugangsdaten auf dem Webserver ein Risiko sind. In der Praxis heißt das: Zugangsdaten so eng schneiden, wie der DNS-Anbieter es zulässt, idealerweise nur auf die eine Zone, und die Zertifikate auf einem zentralen System holen statt auf jedem Webserver einzeln.

# acme.sh mit DNS-01 über die Cloudflare-API (Werte sind Platzhalter)
export CF_Token="<api-token-nur-fuer-diese-zone>"
export CF_Account_ID="<account-id>"
acme.sh --issue --server letsencrypt --dns dns_cf -d example.de -d '*.example.de'

# Zertifikat an nginx übergeben und den Dienst neu laden
acme.sh --install-cert -d example.de \
  --key-file       /etc/nginx/tls/example.de.key \
  --fullchain-file /etc/nginx/tls/example.de.pem \
  --reloadcmd      "systemctl reload nginx"

Zwei Details aus der acme.sh-Dokumentation sind betriebsrelevant. Erstens speichert acme.sh die verwendeten Zugangsdaten in ~/.acme.sh/account.conf, damit spätere Erneuerungen ohne erneuten Export laufen. Diese Datei ist damit so schützenswert wie der API-Token selbst. Zweitens ist ZeroSSL die voreingestellte Zertifizierungsstelle; wer Let's Encrypt will, gibt --server letsencrypt an oder stellt die Standard-CA um. Ohne diesen Hinweis landen Zertifikate bei einem anderen Anbieter, als im Betriebshandbuch steht.

TLS-ALPN-01

Die dritte Variante prüft über Port 443 mit einem eigenen ALPN-Protokoll. Sie hilft, wenn Port 80 nicht offen sein darf, kann aber ebenfalls keine Wildcards. Unterstützt wird sie vor allem von Reverse Proxies, die den TLS-Handshake selbst steuern.

/06ACME Renewal Information: die CA bestimmt den Zeitpunkt

Bisher entscheidet jeder Client selbst, wann er erneuert: nach einer festen Zahl von Tagen oder bei einem Anteil der Restlaufzeit. ACME Renewal Information, seit Juni 2025 als RFC 9773 standardisiert, dreht das um. Die Zertifizierungsstelle veröffentlicht für jedes Zertifikat ein empfohlenes Erneuerungsfenster, das suggestedWindow mit Anfangs- und Endzeitpunkt. Der Client fragt dieses Fenster regelmäßig ab und richtet sich danach. Wie oft er nachfragt, steuert der Server über den Header Retry-After.

Das hat drei handfeste Vorteile. Erstens verschiebt sich der Erneuerungszeitpunkt automatisch, wenn sich Laufzeiten ändern; feste Tageszahlen in Skripten verlieren ihre Bedeutung. Zweitens kann die Zertifizierungsstelle bei einer Massensperrung, etwa nach einem Fehler in ihrer Ausstellung, das Fenster vorziehen und so eine vorzeitige Erneuerung auslösen, bevor Zertifikate gesperrt werden. Drittens nimmt Let's Encrypt Erneuerungen, die über ARI koordiniert sind, ausdrücklich von allen Rate Limits aus.

Let's Encrypt empfiehlt in der Ankündigung der 45-Tage-Zertifikate genau das: ARI nutzen oder, wo der Client es nicht kann, nach etwa zwei Dritteln der Laufzeit erneuern. Ob ein bestimmter Client ARI unterstützt, steht in seiner Dokumentation; bei win-acme ist es voreingestellt und lässt sich nur bewusst abschalten. Bei anderen Clients lohnt der Blick in die Versionshinweise, bevor man sich darauf verlässt.

# Certbot: Erneuerung zweimal täglich anstoßen, Dienst nur bei echter Erneuerung neu laden
# /etc/cron.d/certbot  (wo kein systemd-Timer vorinstalliert ist)
0 0,12 * * * root certbot renew -q --deploy-hook "systemctl reload haproxy"

# Restlaufzeit von außen prüfen, unabhängig vom Client
echo | openssl s_client -connect portal.example.de:443 -servername portal.example.de 2>/dev/null \
  | openssl x509 -noout -enddate

Die letzte Zeile im Beispiel ist die wichtigste. Sie prüft, was der Dienst tatsächlich ausliefert, nicht was in einem Verzeichnis liegt. Genau diese Sicht von außen gehört in die Überwachung, siehe Abschnitt 08.

/07Zentrale Terminierung am Reverse Proxy

Die meisten Unternehmen haben nicht ein Zertifikat, sondern zwanzig oder fünfzig, verteilt über Webserver, Portale, Fachanwendungen und Appliances. Jedes System einzeln zu automatisieren, vervielfacht die Fehlerquellen. Der saubere Weg ist, TLS an wenigen Stellen zu terminieren: Ein Reverse Proxy nimmt die Verbindungen von außen an, hält die Zertifikate und spricht nach innen mit den eigentlichen Diensten. Das Bild dazu: Der Reverse Proxy ist die Poststelle, die alle Briefe öffnet; die Abteilungen dahinter müssen nicht mehr jede für sich einen Schlüssel verwalten.

Traefik und Caddy

Beide bringen ACME eingebaut mit. Caddy stellt laut Dokumentation jede Seite automatisch auf HTTPS um, leitet Port 80 auf 443 um und nutzt dafür Let's Encrypt und ZeroSSL; schlägt eine Zertifizierungsstelle fehl, versucht es Caddy bei der anderen. Für nicht öffentliche Namen wie localhost erzeugt Caddy eine eigene Zertifizierungsstelle. Traefik verwaltet Zertifikate über sogenannte Certificate Resolvers, typischerweise in Docker- oder Kubernetes-Umgebungen.

# traefik.yml: Resolver mit DNS-01 (Beispiel nach Traefik-Dokumentation)
certificatesResolvers:
  hsresolver:
    acme:
      email: zertifikate@example.de
      storage: /data/acme.json
      dnsChallenge:
        provider: cloudflare

Ein Detail zeigt, warum die Laufzeitstufen auch eingebaute Automatik betreffen: Traefik beschreibt, dass es 90-Tage-Zertifikate verwaltet und 30 Tage vor Ablauf mit der Erneuerung beginnt. Für abweichende Laufzeiten gibt es die Option certificatesDuration. Wer auf ein kürzeres Profil wechselt, muss diesen Wert mitziehen, sonst passt die Schwelle nicht mehr zur Laufzeit.

HAProxy und nginx

HAProxy hat seit Version 3.2 einen eigenen ACME-Client, zunächst nur für HTTP-01; DNS-01 kam mit Version 3.3 über die Data Plane API dazu. Die Funktion ist laut Dokumentation weiterhin experimentell und muss mit expose-experimental-directives freigeschaltet werden. Für produktive Umgebungen ist der bewährte Weg deshalb noch ein externer Client wie Certbot oder acme.sh, der das Zertifikat ablegt und HAProxy per Hook neu lädt. Für nginx gilt dasselbe Muster; einen Vergleich der beiden Webserver als Terminierungspunkt finden Sie im Artikel Nginx vs. Apache.

Was zentral nicht geht

Zentrale Terminierung bedeutet, dass zwischen Proxy und Dienst eine zweite Verbindung läuft. Die sollte ebenfalls verschlüsselt sein, wenn sie über ein gemeinsames Netz geht, dann aber mit einem internen Zertifikat, das nicht den öffentlichen Laufzeitregeln unterliegt. Ein Ansatz nach Zero Trust verlangt genau das. Und manche Dienste lassen sich nicht hinter einen HTTP-Proxy stellen, weil sie andere Protokolle sprechen: SMTP mit STARTTLS am Mailserver, das RDP-Protokoll selbst, LDAPS am Domänencontroller. Diese Systeme brauchen ihre Zertifikate direkt und damit einen eigenen Automatismus.

/08Wo es hakt

ACME löst den Normalfall. Die Ausnahmen kosten in der Praxis die meiste Zeit.

Interne Dienste ohne öffentlichen DNS

Eine öffentliche Zertifizierungsstelle stellt nur für Namen aus, deren Kontrolle sie von außen prüfen kann. Ein Server unter fileserver.firma.local bekommt kein Let's-Encrypt-Zertifikat. Zwei Auswege: Interne Dienste unter einer Subdomain einer echten, öffentlich registrierten Domain benennen und per DNS-01 validieren, ohne dass der Server selbst von außen erreichbar ist. Oder für rein interne Dienste bei einer eigenen Zertifizierungsstelle bleiben, deren Stammzertifikat per Gruppenrichtlinie verteilt wird. Beides ist legitim; unsauber ist nur der Zustand dazwischen, in dem Nutzer Zertifikatswarnungen wegklicken.

Appliances ohne ACME

Drucker, USV-Karten, Storage-Oberflächen, Management-Controller von Servern: Viele Geräte nehmen ein Zertifikat nur über eine Weboberfläche per Hand an. Bei 47 Tagen Laufzeit ist das nicht mehr tragbar. Die Optionen in absteigender Reihenfolge: Hersteller-API oder Kommandozeile nutzen, die sich per Skript ansteuern lässt; die Oberfläche hinter den zentralen Reverse Proxy legen; für reine Verwaltungsoberflächen eine interne Zertifizierungsstelle verwenden. Ein Gerät, das nichts davon zulässt, gehört auf die Liste für den nächsten Austausch.

Exchange und Remote Desktop

Für Windows bringt win-acme Beispielskripte mit, die ein erneuertes Zertifikat in Exchange (ImportExchange.v2.ps1), im RD-Gateway (ImportRDGateway.ps1) und im RDP-Listener (ImportRDListener.ps1) einbinden. Das funktioniert, verlangt aber Tests, denn bei Exchange hängen mehrere Dienste am selben Zertifikat. Ein Zertifikatsfehler am Terminalserver zeigt sich übrigens selten als klare Fehlermeldung, sondern als Warnung beim Verbinden, die Anwender irgendwann wegklicken; wie solche Warnungen zu lesen sind, beschreibt der Artikel RDP „Unbekannter Herausgeber" nach dem April-Patchday.

Zertifikats-Pinning

Manche Apps, Agenten und Schnittstellenpartner prüfen nicht nur, ob ein Zertifikat gültig ist, sondern ob es genau dieses Zertifikat oder dieser Schlüssel ist. Jede Erneuerung mit neuem Schlüssel bricht dann die Verbindung. Wer pinnt, sollte auf den Schlüssel der ausstellenden Zwischenzertifizierungsstelle pinnen oder den Schlüssel bei der Erneuerung bewusst beibehalten, und muss das mit dem Partner abstimmen, bevor die Laufzeiten sinken, nicht danach.

Rate Limits

Let's Encrypt begrenzt die Ausstellung: höchstens 50 Zertifikate je registrierter Domain in sieben Tagen, höchstens fünf für exakt denselben Satz an Namen in sieben Tagen und höchstens fünf fehlgeschlagene Validierungen je Name und Konto pro Stunde. Im Normalbetrieb ist das weit weg. Gefährlich wird es bei Fehlern in der Automatik: Ein Skript, das bei jedem Lauf neu bestellt statt zu prüfen, oder ein Container, der bei jedem Neustart ein frisches Zertifikat holt, läuft in die Grenze und blockiert dann auch legitime Erneuerungen. Testläufe gehören deshalb gegen die Staging-Umgebung der Zertifizierungsstelle.

Wildcards nur mit DNS-01

Ein Wildcard-Zertifikat ist bequem, weil es alle Namen einer Ebene abdeckt. Es lässt sich aber nur über DNS-01 holen, also mit API-Zugriff auf das DNS. Und es ist ein Schlüssel für viele Dienste: Wird er auf einem schwach gesicherten System kompromittiert, betrifft das alle. Die bessere Regel ist meist ein Zertifikat je Dienst oder je Proxy, Wildcards nur dort, wo die Namen wirklich dynamisch entstehen.

Wechsel des ACME-Kontos

Wer das ACME-Konto wechselt, weil ein Server neu aufgesetzt oder ein Dienstleister getauscht wird, verliert die Autorisierungen des alten Kontos. Ab dem 15.03.2027 kommt hinzu: Steht im CAA-Eintrag der Domain ein accounturi, bekommt ein neues Konto schlicht kein Zertifikat, bis der Eintrag angepasst ist. Das ist gewollt, gehört aber in jede Übergabedokumentation und in jedes Runbook für den Serverwechsel.

Erneuert heißt nicht ausgeliefert

Seit Let's Encrypt keine Ablaufmails mehr verschickt, merkt niemand von außen, wenn eine Automatik still stehen bleibt. Die Überwachung muss deshalb die Restlaufzeit prüfen, die der Dienst wirklich ausliefert, und zwar für jeden Namen und Port. Mit Prometheus und dem Blackbox Exporter liefert die Metrik probe_ssl_earliest_cert_expiry genau diesen Wert; in Grafana oder einem anderen Monitoring wird daraus ein Alarm. Sinnvoll ist eine Schwelle, die zur Logik der Clients passt: Fällt die Restlaufzeit unter ein Drittel der Laufzeit, hätte die Erneuerung schon passiert sein müssen. Warum Überwachung vor dem Ausfall ansetzen sollte statt danach, beschreibt der Artikel Proaktives Monitoring.

/09Zertifikatsverwaltung: selbst betreiben oder abgeben

Die Technik ist frei verfügbar. Die Frage ist, wer sie betreibt, wer den Überblick über alle Zertifikate hält und wer reagiert, wenn eine Erneuerung scheitert. Eine sinnvolle Entscheidung beginnt mit einer Bestandsaufnahme: Welche Namen gibt es, wo endet TLS, welche Systeme können ACME, welche nicht?

Selbst betreiben lohnt sich, wenn

• wenige, homogene Systeme im Spiel sind, etwa zwei Linux-Webserver hinter einem Proxy, und jemand im Haus die Clients, Hooks und das Patch-Management dafür ohnehin pflegt;
• eine Container-Plattform mit Traefik oder Caddy bereits läuft, deren eingebaute Automatik die öffentlichen Namen abdeckt;
• das Monitoring steht und Restlaufzeiten schon heute von außen misst.

Abgeben lohnt sich, wenn

• die Landschaft gemischt ist: Windows mit Exchange und RDS, Linux, Proxmox, Firewall und ein paar Appliances, jeweils mit eigenem Client und eigener Schwelle;
• Wissen an einer Person hängt, die das Skript vor drei Jahren geschrieben hat;
• der Ausfall teuer ist: Ein abgelaufenes Zertifikat am Kundenportal, am Webmail oder am VPN-Zugang trifft alle Nutzer gleichzeitig, und die Wiederherstellungszeit hängt daran, ob jemand weiß, wo das Zertifikat überhaupt erneuert wird.

Ehrlich: Für einen einzelnen Webserver mit Certbot braucht niemand einen Dienstleister. Bei zwanzig Systemen mit fünf verschiedenen Mechanismen ist das Problem nicht die einzelne Erneuerung, sondern der Überblick.

HostSpezial führt die Zertifikatsverwaltung als eigene Leistung, Managed SSL (im Servicekatalog HSP-SEC-005 „SSL/TLS-Zertifikate"): Beschaffung, Installation und Management von SSL/TLS-Zertifikaten, automatische Erneuerung, Monitoring der Ablaufdaten, Let's Encrypt ebenso wie kommerzielle Zertifizierungsstellen und Wildcard-Zertifikate. In der Praxis heißt das: Wir erfassen den Bestand, bauen je System den passenden Automatismus, vom Reverse Proxy über win-acme an Exchange bis zum ACME-Plugin der Firewall, und überwachen die ausgelieferten Restlaufzeiten von außen. Wo ein Gerät keine Automatik zulässt, steht es mit Termin auf einer Liste, statt überraschend abzulaufen. Betrieben wird das als Managed Service aus Lichtenfels, mit Rechenzentrum in Coburg und Ausweichstandort Neustadt, unter einem nach ISO/IEC 27001:2024 zertifizierten Managementsystem (Zertifikat 202787).

/10Häufige Fragen