Inhalt in Kürze
- 47 Tage ab 15. März 2029 – so kurz dürfen öffentliche TLS-Zertifikate dann maximal noch laufen (CA/Browser Forum 2025). Zwischenschritte: 200 Tage ab 2026, 100 Tage ab 2027.
- Für Linux ist certbot Standard, für Windows-Umgebungen gibt es drei etablierte ACME-Clients: win-acme (kostenlos), Posh-ACME (PowerShell) und Certify the Web (GUI).
- Exchange, RDS-Gateway und LOB-IIS-Anwendungen sind die eigentlichen Fallstricke. DNS-Challenge statt HTTP-01 löst die meisten Probleme, braucht aber Konfiguration der DNS-API.
- 2 bis 4 Projekttage Aufwand bei typischen 30-80-MA-Setups. Wer bis Ende 2027 automatisiert hat, ist auf die 47-Tage-Welt vorbereitet.
Wenn Sie heute Ihr Exchange-Zertifikat alle zwölf Monate manuell erneuern, ist das mit der neuen 47-Tage-Regel ab 2029 nicht mehr praktikabel. Acht Erneuerungen pro Jahr statt einer bedeuten: Entweder Sie automatisieren, oder Sie haben jeden zweiten Monat einen IT-Brand. Die gute Nachricht: Für Linux-Admins ist das mit Let's Encrypt und certbot seit Jahren Standard. Die weniger gute Nachricht: Windows-Umgebungen mit Exchange, RDS, IIS und internen PKIs brauchen ein anderes Toolset – und sind im deutschen Mittelstand oft noch nicht umgestellt.
Was die 47-Tage-Regel konkret bedeutet
Das CA/Browser Forum hat im April 2025 dem Vorschlag von Apple zugestimmt, die maximale Laufzeit öffentlicher TLS-Zertifikate stufenweise zu reduzieren. Heise, Golem und Borncity berichten übereinstimmend:
Alle vier großen Browser-Hersteller (Apple, Google, Microsoft, Mozilla) haben zugestimmt. Das heißt: Ab dem jeweiligen Stichtag weigern sich Chrome, Safari, Edge und Firefox, Zertifikate mit längerer Laufzeit zu akzeptieren. Das gilt für öffentlich erreichbare TLS-Zertifikate – also für alle Server, die im Internet mit gültigem Zertifikat antworten müssen: Exchange-Mailserver, RDS-Gateways, Webshops, Kundenportale, API-Endpoints.
Wer bis 2029 nicht automatisiert hat, bekommt acht Zertifikats-Renewal-Termine pro Jahr pro Dienst. Bei einem mittelständischen Setup mit 10 Zertifikaten sind das 80 manuelle Erneuerungen. Das ist kein „wir gucken dann mal" – das ist ein echtes Betriebsrisiko.
Warum Windows-Umgebungen ein eigenes Thema sind
Die Linux-Welt hat das Problem 2015 gelöst: Let's Encrypt, certbot, Cron-Job. Für Webserver wie Nginx oder Apache läuft das seit Jahren ohne Probleme. In der Windows-Welt ist das komplizierter, und zwar aus drei Gründen:
- Exchange Server. Exchange nutzt ein einziges SAN-Zertifikat für mehrere Dienste: Mail.Contoso.de, Autodiscover.Contoso.de, MX-Records. Wenn das Zertifikat erneuert wird, müssen IIS-Bindings aktualisiert werden, Exchange-Services neu geladen und bei on-prem-Setups der Split-DNS beachtet werden.
- IIS mit SNI und Zentralem Zertifikatspeicher. IIS speichert Zertifikate entweder lokal oder im Central Certificate Store (CCS). Beim Renewal müssen Bindings gegebenenfalls rebuilt werden.
- Interne CAs und ADCS. Viele Mittelständler haben Active Directory Certificate Services für interne Server. ACME ist dort bis Windows Server 2022 nicht nativ dabei – Microsoft hat NDES-ACME als Preview eingebaut, produktiv ist es noch nicht verbreitet.
Wir haben in den letzten zwei Jahren bei jedem Neukunden in Hamburg mit Exchange on-prem das Thema Zertifikats-Automatisierung mit auf die Liste genommen. Das war bis jetzt eher eine Empfehlung. Ab 2027 ist es Pflicht.
Jens HagelGeschäftsführer, hagel IT-Services GmbH
Die drei ACME-Clients für Windows im Vergleich
win-acme (wacs) – der pragmatische Einstieg
win-acme ist ein kostenloser, quelloffener ACME-Client für Windows, der sich über eine interaktive Kommandozeile einrichten lässt. Nach der Erstkonfiguration läuft er als Scheduled Task und erneuert automatisch. Ideal für IIS-Bindings, Exchange (mit Plugin), RDS-Gateway. Er unterstützt HTTP-01 (Port 80 nötig) und DNS-01 (API-Zugriff auf DNS-Provider nötig).
Stärken: Kostenlos, einfaches Setup, gute Dokumentation, aktive Community. Schwächen: GUI-frei, Config pro Server, zentrale Übersicht fehlt.
Posh-ACME – die skriptbare Lösung
Posh-ACME ist ein PowerShell-Modul für ACMEv2. Es unterstützt Dutzende DNS-Provider (Cloudflare, Route 53, Azure DNS, IONOS, Hetzner) und lässt sich in jedes bestehende PowerShell-Deployment integrieren. Ideal für Admins, die ohnehin viel in PowerShell scripten.
Stärken: Maximal flexibel, automatisierbar in Pipelines, DNS-Plugins für fast jeden Provider. Schwächen: Steile Lernkurve, keine GUI, Einbindung in IIS/Exchange erfordert eigenen Install-Code.
Certify the Web – die GUI-Variante
Certify the Web ist eine grafische Anwendung mit Dashboard, Deployment-Profilen und Enterprise-Features wie zentraler Verwaltung mehrerer Server. Die Community Edition ist kostenlos für bis zu 5 Zertifikate pro Server, größere Setups erfordern eine Lizenz (ab ca. 69 Euro einmalig pro Server).
Stärken: GUI, Dashboards, Deployment-Tasks (Exchange-Service-Restart, IIS-Binding-Update), zentrale Verwaltung. Schwächen: Lizenzkosten bei Enterprise-Nutzung.
Der Vergleich im praktischen Szenario
| Szenario | Empfehlung |
|---|---|
| Einfacher IIS-Webserver mit 2-3 Domains | win-acme – kostenlos, 30 Minuten Setup |
| Exchange on-prem mit SAN-Zertifikat | win-acme mit Exchange-Plugin oder Certify the Web |
| 5+ Server zentral verwalten, IT mit wenig PowerShell-Know-how | Certify the Web – GUI, Dashboard |
| Komplexe DNS-Challenge, Wildcard-Zertifikate, skriptbasiertes Deployment | Posh-ACME – maximal flexibel |
| Interne Server ohne Internet-Erreichbarkeit | Posh-ACME + smallstep oder ADCS Auto-Enrollment |
Der Umstellungsplan – 5 Schritte
Aus unserer Praxis bei über 150 Hamburger Mittelstandskunden destilliert, für typische Setups mit Exchange, IIS und RDS:
- Bestandsaufnahme aller TLS-Zertifikate. Welche Dienste haben eigene Zertifikate? Welche teilen sich SAN-Zertifikate? Wo liegen sie (IIS, Exchange-Speicher, Apache, Nginx)? Welche CAs? Wir nehmen das meist mit PowerShell-Scripts auf: Get-ChildItem Cert:\LocalMachine\My über alle Server.
- Entscheidung CA und Validierungsmethode. Let's Encrypt ist kostenlos, hat 90-Tage-Zertifikate heute, wird auf 47 Tage umstellen. Alternativen: ZeroSSL, Sectigo, DigiCert mit ACME. Validierung: HTTP-01 braucht Port 80, DNS-01 braucht API-Zugang zum DNS-Provider. Bei Exchange empfehlen wir DNS-01.
- DNS-API einrichten. Bei Cloudflare geht das in 5 Minuten (API-Token mit Zone-Edit-Rechten). Bei Route 53 über IAM. Bei IONOS, Strato oder Hetzner über deren DNS-APIs. Diese Credentials werden später im ACME-Client hinterlegt.
- ACME-Client pro Server installieren und testen. Entweder einheitlich (z.B. überall Certify the Web) oder gemischt (win-acme für IIS, Posh-ACME für Exchange). Erste Renewal manuell triggern, Deployment-Tasks (Exchange-Service-Restart, IIS-Binding-Update) prüfen.
- Monitoring und Alerting aufsetzen. Ein Zertifikat, das kurz vor Ablauf steht, ohne dass das Renewal lief, ist das größte Risiko. Wir setzen bei unseren Managed-Kunden Monitoring-Agenten wie SSL-Checker, PRTG oder ein eigenes Python-Script, das täglich alle öffentlichen Zertifikate auf Ablauf prüft und bei < 14 Tagen Rest alarmiert.
Bei Exchange-Umgebungen lohnt sich ein Test-Renewal außerhalb Geschäftszeiten. Manchmal startet Exchange-Backend-Service nach Zertifikats-Wechsel nicht sauber, das merken wir nur bei echter Ausführung. Besser einmal am Samstagabend testen als am Montagmorgen live.
Exchange-Spezialfall: Was sonst noch schiefgeht
Exchange ist historisch gewachsen und hat drei Fallstricke, die wir bei Migrationen immer wieder sehen:
- SAN-Feld mit autodiscover. Wenn im SAN autodiscover.ihredomain.de fehlt, schmeißt Outlook beim Start Zertifikats-Warnungen. Beim Renewal darauf achten, dass alle SAN-Einträge übernommen werden.
- Split-DNS. Exchange wird intern oft über mail.internal.domain aufgerufen, extern über mail.domain.de. Wildcard oder SAN mit beiden Namen nötig – dann ist intern auch ACME-Renewal machbar.
- Hybrid-Setup mit Exchange Online. Wenn Sie Exchange Online im Hybrid-Modus mit on-prem-Server betreiben, braucht das OAuth-Zertifikat extra Aufmerksamkeit – das ist kein TLS-Zertifikat, sondern ein Trust-Zertifikat zwischen den Tenants.
Bei uns war das Thema SSL-Zertifikate immer der Moment, an dem wir alle Leuchttürme nochmal durchgeklappert haben – Exchange, IIS, VPN, das Cloud-Gateway. Jetzt läuft das per Scheduled Task, ich krieg eine Mail, dass ein Zertifikat erneuert wurde, und gut ist. Das ist der Punkt, wo Managed IT wirklich was bringt.
Die strategische Frage: On-Prem Exchange bis 2029?
Wer 2026 bei Exchange on-prem ist und die Automatisierung noch nicht aufgesetzt hat, sollte sich eine größere Frage stellen: Ist Exchange on-prem bis 2029 überhaupt noch die richtige Architektur? Microsoft hat Exchange 2019 Mainstream-Support bereits beendet, Exchange SE (Server Edition) löst ab – mit Subscription-Modell. Parallel zum Zertifikats-Thema lohnt sich oft eine Migration zu Exchange Online, wo Microsoft die Zertifikate selbst verwaltet.
Für Unternehmen, die aus regulatorischen oder technischen Gründen on-prem bleiben müssen (Gesundheitswesen, einige Finanzdienstleister), ist ACME-Automatisierung ab jetzt ein Muss. Wir begleiten beide Pfade – Migration in die Cloud oder saubere Automatisierung on-prem.
Was hagel IT Hamburger Kunden anbietet
Wir haben bei unseren Managed-IT-Kunden in Hamburg, Bremen und Kiel das Thema Zertifikats-Automatisierung standardmäßig in der Leistung enthalten. Das bedeutet konkret: Wir installieren den passenden ACME-Client, richten DNS-API-Zugänge ein, monitoren alle öffentlichen Zertifikate und greifen ein, wenn ein Renewal schiefgeht. Für Unternehmen, die keine Managed-IT haben, bieten wir die Umstellung als Festpreisprojekt – typischerweise 2-4 Tage, unabhängig davon, wer danach betreut.
Zertifikats-Automatisierung rechtzeitig aufsetzen.
30 Minuten Erstgespräch. Kostenlos. Wir schauen uns Ihre TLS-Landschaft an und entwickeln einen pragmatischen Umstellungspfad – bevor 2029 alles auf einmal kommt.
Termin buchen →
