Erneuerung des Zertifikats auf Apache mit CertSecure Manager

Kurz gesagt: Die Erneuerung eines Apache-Zertifikats mit CertSecure Manager bedeutet, ein TLS-Zertifikat über CertSecure Manager zu generieren oder neu zu registrieren, die signierte PFX-Datei herunterzuladen, den privaten Schlüssel und das Zertifikat mit OpenSSL zu extrahieren und beide Dateien auf dem Apache-Server bereitzustellen, bevor der Dienst neu gestartet wird, um die Änderung anzuwenden. Dieser Prozess, der manuell auf Hunderten von Servern durchgeführt wird, ist die Hauptursache für vermeidbare Zertifikatsausfälle.

Apache ist nach wie vor einer der am weitesten verbreiteten Webserver in Unternehmensumgebungen, und jede von ihm betriebene Website benötigt ein gültiges und korrekt installiertes TLS-Zertifikat. Dieser Leitfaden beschreibt den gesamten Erneuerungsprozess mit CertSecure Manager, der Zertifikatslebenszyklusmanagement-Plattform (CLM) von Encryption Consulting, und erläutert die Voraussetzungen, Rollback-Schritte, Fehlerbehandlung und Erfolgsmetriken, die ein PKI-, Sicherheits-, Plattform- oder Compliance-Team für den sicheren und skalierbaren Betrieb benötigt.

Voraussetzungen und Kurzcheckliste

Bitte prüfen Sie die folgenden Punkte, bevor Sie mit der Verlängerung beginnen. Das Fehlen eines dieser Punkte ist die häufigste Ursache für eine fehlgeschlagene oder verzögerte Verlängerung.

Checkliste der Voraussetzungen

• Aktives CertSecure Manager-Konto mit Registrierungsberechtigungen und Zugriff auf die Zielzertifizierungsstelle und die Zertifikatsvorlage
• Administrativer Zugriff oder sudo-Zugriff auf den Ziel-Apache-Server
• OpenSSL muss auf dem Rechner installiert sein, der zum Extrahieren des Schlüssels und des Zertifikats verwendet wurde (Version 1.1.1 oder höher; Version 3.x wird unterstützt). -legacy Flagge für PKCS#12-Kompatibilität)
• Kenntnis des bei der Zertifikatserstellung festgelegten PFX-Exportpassworts
• Aktuelle Apache Virtual Host-Konfiguration, die die bestehende SSLCertificateFile und SSLCertificateKeyFile Pfade
• Ein Wartungsfenster oder eine Zeit mit geringem Datenverkehr, da Apache neu gestartet werden muss, um das neue Zertifikat zu laden.
• Erstellen Sie eine Sicherungskopie der aktuellen Zertifikats- und Schlüsseldateien, bevor Sie diese überschreiben.

Tabelle der Voraussetzungen für die Umsetzung

Voraussetzung	Maßnahmen vor der Verlängerung	Eigentümer
CertSecure Manager-Zugriff	Bestätigen Sie die Registrierungsrolle und die Zuordnung von CA/Vorlage.	PKI-Team
Apache-Serverzugriff	Überprüfen Sie die sudo-/Administrator-Anmeldeinformationen und den SSH-Zugriff.	Plattform-Team
OpenSSL-Verfügbarkeit	Version und Unterstützung für ältere Anbieter bestätigen	Plattform-Team
Vorhandene Konfigurationspfade	Suchen Sie SSLCertificateFile und SSLCertificateKeyFile in der VHost-Konfiguration.	Plattform-Team
Sicherungskopie	Kopieren Sie die aktuellen .crt- und .key-Dateien an einen Rollback-Speicherort.	Plattform-Team
Fenster ändern	Neustart während einer verkehrsarmen Zeit planen	Sicherheits-/Änderungsmanagement
Compliance-Aufzeichnung	Protokollierung der Erneuerung im Zertifikatsinventar/CBOM für den Prüfpfad	Compliance-Team

Zertifikatsverwaltung mit CertSecure Manager

CertSecure Manager ist die Plattform für das Zertifikatslebenszyklusmanagement (CLM) von Encryption Consulting. Sie adressiert die zentrale Herausforderung von Unternehmen bei der Verwaltung ihrer PKI: die schiere Anzahl an Zertifikaten in der gesamten Infrastruktur. Von der Zertifikatserkennung und -erneuerung bis hin zur Durchsetzung unternehmensweiter Ausstellungsrichtlinien – alles ist möglich. Integrationen mit ServiceNow und Microsoft Teams unterstützen Benachrichtigungen und Workflows für das Incident-Management, sodass die Benachrichtigung über bevorstehende Zertifikatsabläufe nicht mehr von der Erinnerung an Tabellenkalkulationen abhängt.

CertSecure Manager trennt Benutzerdaten nach Abteilung und Rolle. Administratoren definieren Richtlinien und weisen Rollen zu, und Benutzer können nur die Aktionen ausführen, die ihnen durch ihre Berechtigungen erlaubt sind. Dadurch bleiben Zertifikatsvorgänge auch in großen Teams nachvollziehbar.

Dank einer Hochverfügbarkeitsarchitektur (HA) integrieren die Connector-Clients von CertSecure Manager alle öffentlichen und privaten Zertifizierungsstellen in einer zentralen Benutzeroberfläche. Die Workflows des Erneuerungsagenten unterstützen Apache, Tomcat, nginx und Load Balancer wie F5 und stellen erneuerte Zertifikate automatisch auf den unterstützten Endpunkten bereit. Diese Automatisierung schließt auch die Lücke, die die in diesem Leitfaden beschriebenen manuellen Schritte aufzeigen: Jeder der unten aufgeführten manuellen Schritte wird durch den Erneuerungsagenten von CertSecure Manager für unterstützte Apache-Bereitstellungen eliminiert.

Das Zertifikatslebenszyklusmanagement endet nicht mit TLS. Das gleiche Problem der Erkennung und Inventarisierung betrifft alle kryptografischen Assets in einer Umgebung. Hier kommt die kryptografische Stückliste (CBOM) ins Spiel. Encryption Consultings CBOM Secure erweitert die Zertifikatserkennung auf ein vollständiges Krypto-Asset-Inventar. Der CBOM-Inventar-zu-Intelligenz- Leitfaden beschreibt, wie dieses Inventar in konkrete Krypto-Agilität umgesetzt wird.

Schritt-für-Schritt-Anleitung zur Erneuerung eines Zertifikats auf Apache

Es gibt zwei unterstützte Möglichkeiten, ein Zertifikat für eine auf Apache gehostete Website zu erneuern. Erstens: Generieren Sie eine neue Zertifikatsignierungsanforderung (CSR) im CertSecure Manager. Dabei werden ein neuer privater Schlüssel und eine CSR mit dem Domainnamen, dem Organisationsnamen und weiteren Subjektdetails erstellt und anschließend zur Validierung und Ausstellung an eine Zertifizierungsstelle (CA) übermittelt. Zweitens: Registrieren Sie sich direkt mit einer bereits vorhandenen CSR. In diesem Fall wird die CSR-Generierung übersprungen und die bestehende CSR direkt an die CA übermittelt.

CertSecure Manager automatisiert die arbeitsintensiven Teile dieses Beschaffungsprozesses und reduziert die folgenden manuellen Schritte auf die Konfiguration und Bereitstellung auf der Apache-Seite.

Schritt 1: Generieren Sie das Zertifikat im CertSecure Manager.

Melden Sie sich bei CertSecure Manager an und navigieren Sie im linken Menü unter „Registrierung“ zu „Zertifikat generieren“ . Wählen Sie die entsprechende Zertifizierungsstelle, die Zertifikatvorlage, die SAN-Attribute und alle weiteren erforderlichen Felder aus und klicken Sie anschließend auf „Zertifikat generieren“.

Erwartetes Ergebnis: Im Anmeldeinventar erscheint eine neue Anmeldeaufgabe mit dem Status „ausstehend“ oder „ausgestellt“.

Schritt 2: Laden Sie das Zertifikat aus dem Teilnehmerverzeichnis herunter

Navigieren Sie zur Zertifikatsverwaltung und suchen Sie das Zertifikat anhand seiner Registrierungs-ID (prüfen Sie die Aufgaben, falls es nicht sofort sichtbar ist). Laden Sie die PFX-Datei herunter und übertragen Sie sie auf den Apache-Server oder auf die Workstation, mit der Sie die Dateien vorbereiten.

Erwartetes Ergebnis: a .pfx Datei, die das Zertifikat, seine Kette und den privaten Schlüssel enthält und durch das Exportpasswort geschützt ist, das Sie bei der Registrierung festgelegt haben.

Schritt 3: Extrahieren Sie den privaten Schlüssel und das Zertifikat mit OpenSSL

Apache benötigt den privaten Schlüssel und das Zertifikat als separate PEM-Dateien, nicht als kombinierte PFX-Datei. Extrahieren Sie zuerst den privaten Schlüssel:

Dieser Befehl erzeugt einen verschlüsselten privaten Schlüssel. Für einen unverschlüsselten Schlüssel fügen Sie Folgendes hinzu: -nodes:

OpenSSL fordert Sie zur Eingabe des PFX-Exportpassworts auf, das beim Generieren des Zertifikats festgelegt wurde. Extrahieren Sie anschließend das Zertifikat selbst, entweder mit OpenSSL oder durch Umbenennen der Zertifikatsdatei in eine PFX-Datei. .pem Erweiterung:

Erwartetes Ergebnis: zwei Dateien, key.pem und certificate.pem, bereit zum Einsatz.

Häufiger Fehler: auf OpenSSL 3.x, wobei ausgelassen wird -legacy kann einen „MAC-Verifizierungsfehler“ verursachen, wenn die PFX-Datei mit der älteren RC2/3DES-Verschlüsselung generiert wurde. Hinzufügen -legacy Lädt den Legacy-Provider und löst ihn auf.

Schritt 4: Zertifikat und Schlüssel auf dem Apache-Server bereitstellen

Ort certificate.pem und key.pem im selben Pfad, in dem das aktuelle Zertifikat und der Schlüssel für die Website gespeichert sind, und zwar entsprechend den Dateinamen und Berechtigungen, die Apache bereits erwartet (typischerweise referenziert durch SSLCertificateFile und SSLCertificateKeyFile (in der VHost-Konfiguration). Sichern Sie die vorherigen Dateien, bevor Sie sie überschreiben.

Erwartetes Ergebnis: Die VHost-Konfiguration verweist auf das neue Zertifikat und den neuen Schlüssel, und die Dateiberechtigungen stimmen mit den vorherigen Dateien überein (üblicherweise 600 (für den privaten Schlüssel, der dem Apache-Dienstbenutzer gehört).

Schritt 5: Apache neu starten und überprüfen

Überprüfen Sie die Konfiguration vor dem Neustart:

Wenn der Test erfolgreich ist, starten Sie den Dienst neu:

Prüfen Sie, ob das neue Zertifikat aktiv ist und überprüfen Sie sein Ablaufdatum:

Erwartetes Ergebnis: apachectl configtest Gibt „Syntax OK“ zurück, die Website wird ohne Zertifikatswarnung geladen, und der Ausdruck notAfter Das Datum entspricht der Gültigkeitsdauer des neuen Zertifikats.

Operativer Arbeitsablauf vor und nach der Operation

Praktikum	Manueller Prozess (Vorher)	Mit CertSecure Manager Automation (Nachher)
Bewertung	Tabellenkalkulation zur Nachverfolgung, da kann man leicht ein Zertifikat übersehen	Zentralisierte Bestandsverwaltung über alle verbundenen Zertifizierungsstellen hinweg
Anmeldung zur Pilotenausbildung	Manuelle CSR-Erstellung und -Einreichung pro Zertifikat	Richtliniengesteuerte Registrierung über CertSecure Manager
Schlüssel-/Zertifikatsextraktion	Manuelle OpenSSL-Befehle pro Server	Wird vom Erneuerungsagenten für unterstützte Server, einschließlich Apache, abgewickelt.
Einsatz	Manuelle Dateiplatzierung und Berechtigungsprüfungen	Automatisierte Bereitstellung über einen Erneuerungsagenten
Wiederaufnahme	Manuell geplant und ausgeführt	Koordiniert als Teil des automatisierten Arbeitsablaufs
Alarmieren	Ad-hoc-Erinnerungen oder keine	ServiceNow/Teams-Benachrichtigungen bei Ablauf und Fehlern
Audit-Trail	Manuell gewartet, oft unvollständig	Automatische Protokollierung im CertSecure Manager und im CBOM-Inventar

Eigentümer- und Aktionsmatrix

Team	Verantwortlichkeiten in diesem Arbeitsablauf	Schlüsselaktion
PKI-Team	Besitzt CA-Beziehungen, Vorlagen und die Anmelderichtlinie	Konfigurieren Sie CertSecure Manager-Vorlagen und genehmigen Sie den Registrierungsbereich.
Sicherheits Team	Verantwortlich für die Risikobewertung und die Reaktion auf Vorfälle bei Zertifizierungsfehlern.	Schwellenwerte für Ablaufbenachrichtigungen festlegen und Ausfallanalysen überprüfen
Plattform-/Infrastrukturteam	Besitzt die Apache-Server und die Bereitstellungsausführung.	Bereitstellungs-, Neustart- und Verifizierungsschritte ausführen oder automatisieren.
Compliance-Team	Besitzt Prüfnachweise für Kontrollen des Zertifikatslebenszyklus.	Bestätigen Sie, dass Erneuerungsereignisse im Inventar/CBOM für die Prüfung protokolliert werden.

Rollback-Anleitung

Falls das neue Zertifikat einen Ausfall oder eine Fehlkonfiguration verursacht, führen Sie ein Rollback mit der in Schritt 4 erstellten Sicherung durch:

1. Stellen Sie den vorherigen Zustand wieder her certificate.pem und key.pem von der Sicherung zu den ursprünglichen Dateipfaden.
2. Stellen Sie sicher, dass die Dateibesitzverhältnisse und Berechtigungen dem Zustand vor der Änderung entsprechen (typischerweise 600 für den privaten Schlüssel).
3. Führen Sie apachectl configtest Um sicherzustellen, dass die Konfiguration gültig ist, muss vor dem Neustart geprüft werden.
4. Starten Sie Apache neu und überprüfen Sie erneut, ob die Website mit dem wiederhergestellten Zertifikat geladen wird.
5. Untersuchen Sie die Fehlerursache (abgelaufene Kette, nicht übereinstimmender Schlüssel, falsches SAN), bevor Sie die Erneuerung erneut versuchen.
6. Protokollieren Sie das Rollback-Ereignis im Zertifikatsinventar, damit der Prüfpfad widerspiegelt, was tatsächlich geschehen ist.

Häufige Fehler und wie man sie vermeidet

Fehler	Wahrscheinliche Ursache	Fixieren
„MAC-Verifizierungsfehler: Ungültiges Passwort?“ während der PKCS#12-Extraktion	OpenSSL 3.x verwendet standardmäßig einen Provider, der die ältere Verschlüsselungsmethode von PFX nicht unterstützt.	Fügen Sie -legacy Flagge an den OpenSSL-Befehl
Apache startet nach der Bereitstellung nicht.	Nicht übereinstimmendes Zertifikat und privater Schlüssel oder falscher Dateipfad in der VHost-Konfiguration	Verify SSLCertificateFile/SSLCertificateKeyFile Pfade und bestätigen Sie, dass der Schlüssel mit dem Zertifikat übereinstimmt openssl x509 -noout -modulus und openssl rsa -noout -modulus
Der Browser zeigt weiterhin das alte Zertifikat an.	Apache wurde nicht neu gestartet, oder ein vorgeschalteter Caching-Proxy/CDN verwendet noch das alte Zertifikat.	Prüfen Sie, ob der Neustart abgeschlossen ist, und leeren Sie den CDN-/Proxy-Cache.
Das Zertifikat läuft erneut früher als erwartet ab.	Missverständnis bezüglich der Gültigkeitsdauer im Zusammenhang mit dem schrumpfenden Zeitplan des CA/B-Forums	Bestätigen Sie die Gültigkeitsdauer des ausgestellten Dokuments anhand der aktuellen Phase des CA/B-Forums (200/100/47 Tage) anstatt von der vorherigen Standarddauer von 398 Tagen auszugehen.

Zu verfolgende Erfolgsmetriken

• Ausfallzeiten im Zusammenhang mit Zertifikaten pro Quartal (Ziel: null, Vergleichswert mit den 45 % der Unternehmen, die in der DigiCert-Umfrage von 2025 mindestens einen solchen Vorfall gemeldet haben)
• Prozentsatz der vor Ablauf abgeschlossenen Verlängerungen im Vergleich zu danach (Ziel: 100 % vorher)
• Mittlere Erneuerungszeit pro Zertifikat, manuell versus automatisiert
• Anzahl der Zertifikate mit automatisierter Verlängerung im Vergleich zur manuellen Nachverfolgung
• Reduzierung der manuellen Verlängerungstickets im Vergleich zum Vorquartal
• Prüfungsfeststellungen im Zusammenhang mit abgelaufenen oder falsch konfigurierten Zertifikaten (Ziel: null)

Warum dies für das Zertifikatslebenszyklusmanagement in Unternehmen wichtig ist

Ein einziges abgelaufenes Zertifikat auf einem produktiven Apache-Server kann eine Kundenwebsite lahmlegen – und das ist keine Seltenheit. Laut der DigiCert Trust Pulse Survey vom Juli 2025 verzeichneten 45 % der Unternehmen im vergangenen Jahr zertifikatsbedingte Ausfallzeiten, und 37.5 % dieser Ausfälle waren direkt auf abgelaufene Zertifikate zurückzuführen ( DigiCert, 2. Juli 2025 ). Manuelle Erneuerungsprozesse wie der oben beschriebene sind zwar notwendig, aber für die heutigen Zertifikatsmengen in den meisten Unternehmen nicht skalierbar.

Unsere Empfehlung: Teams sollten die manuellen Schritte in diesem Leitfaden als dokumentierte Ausweichlösung und Schulungsreferenz betrachten, nicht als Standardbetriebsmodell. Jedes Unternehmen, das Apache in großem Umfang einsetzt, sollte die Zertifikatserneuerung auf einen automatisierten CLM-Workflow umstellen. Dies dient sowohl der Vermeidung des oben genannten Ausfallrisikos als auch der Tatsache, dass sich die Gültigkeitsdauer von Zertifikaten stetig verkürzt, wodurch eine manuelle Erneuerung unabhängig von der Disziplin des Teams nicht mehr praktikabel ist.

Verbindung zur 47-tägigen TLS-Zertifikatbereitschaft

Die von Sectigo initiierte und im April 2025 verabschiedete CA/B-Forum-Abstimmung SC-081v3 reduziert die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate schrittweise von 398 Tagen auf 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029 ( Sectigo, 14. April 2025 ). Bei einem 47-tägigen Ablauf müsste ein manueller Erneuerungsprozess, wie er in dieser Anleitung beschrieben ist, etwa achtmal pro Jahr und Zertifikat auf jeder Apache-Instanz in der Umgebung durchgeführt werden.

Dies ist dasselbe Problem der Krypto-Agilität wie bei der Post-Quanten-Migration: In beiden Fällen ist es erforderlich, genau zu wissen, welche Zertifikate und kryptografischen Assets existieren, um sie schnell verwalten zu können. CBOM Secure von Encryption Consulting ermöglicht diese Zertifikatserkennung und die Inventarisierung von Krypto-Assets, und das PQC Center of Excellence sowie die PQC- Vorbereitungsprogramme übertragen diese Vorgehensweise auf die Migration quantensicherer Algorithmen. Die Automatisierung der Apache-Zertifikatserneuerung durch CertSecure Manager bereitet Sie direkt auf den 47-tägigen Endpunkt dieses Zeitplans vor.

Was macht man als nächstes

Für PKI-Teams

Prüfen Sie, welche Apache-Server noch auf manuelle Erneuerung angewiesen sind, und stellen Sie sicher, dass die CertSecure Manager-Vorlagen und CA-Verbindungen alle diese Server abdecken.

Für Sicherheitsteams

Setzen Sie die Schwellenwerte für die Ablaufbenachrichtigung deutlich vor dem 47-Tage-Endpunkt und überprüfen Sie die Zertifikats-bezogenen Vorfälle der letzten vier Quartale anhand der oben genannten Erfolgsmetriken.

Für Plattformteams

Testen Sie den Erneuerungsagenten von CertSecure Manager auf einer nicht kritischen Apache-Instanz, bevor Sie ihn flächendeckend einführen, und dokumentieren Sie das Rollback-Verfahren zusammen mit dem Standard-Runbook.

Für Compliance-Teams

Bestätigungserneuerungs- und Rollback-Ereignisse werden im Zertifikatsinventar erfasst, sodass Prüfnachweise für die Lebenszykluskontrollen automatisch generiert und nicht nachträglich rekonstruiert werden müssen.

Fazit

Die Erneuerung eines Zertifikats auf Apache mit CertSecure Manager ist unkompliziert, sobald die oben beschriebenen Schritte zur Registrierung, Extraktion und Bereitstellung dokumentiert und geübt wurden. Da die Gültigkeitsdauer von Zertifikaten jedoch auf 47 Tage sinkt und das Zertifikatsvolumen stetig wächst, ist die manuelle Ausführung dieser Schritte langfristig nicht mehr praktikabel. Nutzen Sie diese Anleitung als Referenz für den Prozess und die Erneuerungsautomatisierung von CertSecure Manager als Weg zu einem sicheren Betrieb in großem Umfang. Wie derselbe Workflow auf anderen Servertypen funktioniert, erfahren Sie in unserem Leitfaden zur Erneuerung und zum Widerruf von Zertifikaten in Microsoft PKI.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Artikel „Zertifikatserneuerung für Apache mit CertSecure Manager“?

Die Erneuerung eines Apache-Zertifikats umfasst das Generieren oder Registrieren eines Zertifikats im CertSecure Manager, das Herunterladen der PFX-Datei, das Extrahieren von Schlüssel und Zertifikat mit OpenSSL, die Bereitstellung beider auf dem Server und den Neustart von Apache. Dieser manuelle Prozess funktioniert zwar, ist aber nicht skalierbar. Daher automatisiert der Erneuerungsagent des CertSecure Managers diesen Vorgang für unterstützte Apache-Bereitstellungen.

Warum ist das für das Zertifikatslebenszyklusmanagement in Unternehmen von Bedeutung?

Zertifikatsausfälle sind häufig und kostspielig. Laut der DigiCert Trust Pulse Survey vom Juli 2025 verzeichneten 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten aufgrund von Zertifikaten, wobei 37.5 % der Vorfälle auf abgelaufene Zertifikate zurückzuführen waren. Bei Apache-Installationen im Unternehmensmaßstab verstärkt sich dieses Risiko, da eine einzige versäumte Verlängerung eine Produktionsumgebung lahmlegen kann.

Welche Teams sind für die Umsetzung dieser Vorgaben verantwortlich?

Vier Teams teilen sich typischerweise die Verantwortung: Das PKI-Team ist für die Beziehungen zu Zertifizierungsstellen und die Registrierungsvorlagen zuständig, das Sicherheitsteam für die Alarmierungsschwellenwerte und die Überprüfung von Vorfällen, das Plattformteam führt die Bereitstellung und Neustarts durch, und das Compliance-Team stellt sicher, dass Erneuerungsereignisse zu Prüfungszwecken erfasst werden.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Die manuelle Erneuerung erhöht das Risiko verpasster Ablaufdaten, nicht übereinstimmender Schlüssel und Zertifikate, fehlerhafter Dateiberechtigungen und unvollständiger Prüfprotokolle. Da sich die Gültigkeitsdauern im Rahmen des gestaffelten Zeitplans des CA/B-Forums verkürzen, steigt die Häufigkeit der erforderlichen manuellen Erneuerungen pro Zertifikat, wodurch sich die Wahrscheinlichkeit menschlicher Fehler bei jedem Schritt vervielfacht.

Wie kann Automatisierung das Risiko von Zertifikatsausfällen verringern?

Der Erneuerungs-Workflow von CertSecure Manager eliminiert die manuellen Schritte zum Extrahieren, Bereitstellen und Neustarten von Zertifikaten für unterstützte Server, einschließlich Apache, und ersetzt die Ad-hoc-Überwachung durch eine zentrale Benachrichtigung über den Ablauf von Zertifikaten dank Integrationen wie ServiceNow und Microsoft Teams. Dadurch wird die Zeitspanne zwischen dem Fälligkeitsdatum eines Zertifikats und der tatsächlichen Reaktion darauf verkürzt.

Welche Kennzahlen sollten die Teams nach der Implementierung verfolgen?

Erfassen Sie pro Quartal die Ausfallzeiten im Zusammenhang mit Zertifikaten, den Prozentsatz der vor bzw. nach Ablauf abgeschlossenen Verlängerungen, die durchschnittliche Verlängerungszeit, die Anzahl der automatisiert bzw. manuell verwalteten Zertifikate, die Reduzierung der manuellen Verlängerungstickets sowie alle Prüfungsfeststellungen im Zusammenhang mit abgelaufenen oder falsch konfigurierten Zertifikaten.

Wie hängt das mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammen?

Die Abstimmung im CA/B Forum SC-081v3 sieht eine schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate vor: auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage im März 2029. Bei einem 47-tägigen Rhythmus ist eine manuelle Erneuerung nicht mehr praktikabel, weshalb die in diesem Leitfaden beschriebene Automatisierung eine direkte Voraussetzung für die Einhaltung des immer kürzer werdenden Gültigkeitszeitraums ist.

Wie sollte dies in Multi-Cloud- oder Hybrid-PKI-Umgebungen gehandhabt werden?

Multi-Cloud- und Hybridumgebungen sollten die gesamte Zertifikatsregistrierung und -erneuerung – unabhängig vom Ausführungsort der Apache-Instanz – über eine zentrale CLM-Plattform wie CertSecure Manager abwickeln, anstatt jede Cloud- oder On-Premises-Umgebung separat zu verwalten. Dadurch bleiben CA-Beziehungen, Vorlagen und Audit-Trails umgebungsübergreifend konsistent und nicht plattformspezifisch fragmentiert.

Welche Voraussetzungen müssen vor der Implementierung erfüllt sein?

Die Teams benötigen Zugriff auf die CertSecure Manager-Registrierung, administrative Zugriffsrechte auf den Apache-Server, eine installierte OpenSSL-Bibliothek mit Unterstützung für ältere Anbieter, die aktuellen vHost-Konfigurationspfade, das PFX-Exportpasswort, ein geplantes Wartungsfenster für den Neustart sowie eine Sicherung der vorhandenen Zertifikats- und Schlüsseldateien.

Welche Screenshots oder Konfigurationsbeispiele sollten beigefügt werden?

Die Dokumentation sollte den Bildschirm „Zertifikat generieren“ des CertSecure Managers, die Ansicht „Registrierungsinventar“, die zum Auffinden und Herunterladen der PFX-Datei verwendet wird, die Terminalausgabe für jeden OpenSSL-Extraktionsbefehl sowie die relevanten Apache-Vhost-Konfigurationszeilen, die auf die Pfade der Zertifikats- und Schlüsseldateien verweisen, enthalten.