Geplanter Wechsel ohne Betriebsunterbrechung
Ein kontrollierter Zertifikatswechsel beginnt mit einem vollständigen Überblick über die vorhandene Siegelinfrastruktur. Unternehmen müssen wissen, welche Systeme den privaten Schlüssel verwenden, wo das Zertifikat hinterlegt ist und welche Anwendungen die erzeugten Siegel prüfen.
Zur Bestandsaufnahme gehören beispielsweise:
- Hardware Security Modules und andere Siegelerstellungseinheiten,
- zentrale Signatur- oder Siegelserver,
- Dokumentenmanagement- und Archivsysteme,
- ERP-, CRM- und Abrechnungssysteme,
- Fachanwendungen und automatisierte Workflows,
- Validierungsdienste,
- Zertifikats- und Vertrauensspeicher,
- Schnittstellen zu Kunden, Behörden und Geschäftspartnern,
- Monitoring-, Protokollierungs- und Notfallsysteme.
Auf dieser Grundlage sollte ein verbindlicher Wechselplan erstellt werden. Er legt fest, wann das neue Schlüsselpaar erzeugt oder bereitgestellt wird, wer die Freigabe erteilt, ab welchem Zeitpunkt neue Dokumente mit dem neuen Zertifikat versiegelt werden und wann der bisherige Schlüssel deaktiviert wird.
Eine kurze Parallelbetriebsphase kann sinnvoll sein. Dabei bleibt die bisherige Infrastruktur zunächst für klar definierte Prozesse verfügbar, während das neue Zertifikat bereits getestet wird. Für jeden Prozess muss eindeutig festgelegt sein, welches Zertifikat ab welchem Zeitpunkt verwendet wird.
Vor der produktiven Aktivierung sollten mindestens folgende Punkte geprüft werden:
- Ist die Zertifikatskette vollständig und korrekt?
- Stimmen Name und Identität der juristischen Person?
- Enthält das Zertifikat die benötigten Verwendungszwecke und Erweiterungen?
- Wird das neue Zertifikat von der Siegelerstellungseinheit korrekt verwendet?
- Funktionieren PAdES-, XAdES-, CAdES- oder ASiC-Prozesse wie vorgesehen?
- Können interne und externe Validierungssysteme die neuen Siegel prüfen?
- Sind Statusinformationen über OCSP oder Sperrlisten erreichbar?
- Funktionieren Zeitstempel und Langzeitvalidierungsdaten?
- Sind Rollback- und Notfallverfahren dokumentiert?
Besonders problematisch sind Anwendungen, in denen Zertifikate fest im Programmcode, in Konfigurationsdateien oder in nicht dokumentierten Truststores hinterlegt wurden. Solche Abhängigkeiten führen beim Zertifikatswechsel häufig zu Ausfällen. Zertifikatsinformationen sollten deshalb zentral verwaltet und über kontrollierte Konfigurationsprozesse verteilt werden.
Auch externe Empfänger müssen berücksichtigt werden. Manche Systeme vertrauen ausschließlich einer bestimmten Zertifikatskette, einem bekannten Aussteller oder einem zuvor registrierten Zertifikatsfingerabdruck. In solchen Fällen muss der Empfänger rechtzeitig über den Wechsel informiert werden.
Bei qualifizierten elektronischen Siegeln sollte die Validierung den Status des qualifizierten Vertrauensdiensteanbieters und die einschlägigen europäischen Vertrauenslisten berücksichtigen.
