Public-Key-Infrastruktur: was die eigene Software leisten muss

Eine Public-Key-Infrastruktur stellt die digitalen Ausweise aus, an denen sich Server, Dienste und Fachanwendungen gegenseitig erkennen. Als ein deutscher Anbieter im April 2026 alle seit März 2025 ausgestellten Ausweise dieser Art mit Frist bis Montag widerrief, zählte nur eine Frage: Welche Anwendungen hängen daran? Ohne Zertifikatsmanagement beantwortet sie erst der Ausfall.
Zwei Personen halten vor sandfarbenem Hintergrund eine waagerecht gespannte Kette aus flachen weißen Gliedern, die Frau prüft das einzige gelbgrüne Glied. Sinnbild für die Vertrauenskette, die eine Anwendung Glied für Glied prüfen muss.
© KI-generiert (TenMedia)

Was eine Public-Key-Infrastruktur für Fachanwendungen heißt

Am 4. April 2026 meldete das BSI, dass D-Trust seine seit dem 15. März 2025 ausgestellten TLS-Zertifikate widerruft, wirksam am 6. April um 17 Uhr. Ein solches Zertifikat ist ein digitaler Ausweis, der die Echtheit eines Servers oder Dienstes bestätigt.

Eine Public-Key-Infrastruktur (PKI), wörtlich eine Infrastruktur für öffentliche Schlüssel, ist das Zusammenspiel aus Regeln, Stellen und Technik, mit dem eine Organisation digitale Zertifikate ausstellt, verteilt, prüft und sperrt. Jedes Zertifikat bindet einen öffentlichen Schlüssel an eine Identität, etwa einen Server, einen Dienst oder ein Gerät. Eine Zertifizierungsinstanz, die Certificate Authority oder CA, bürgt mit ihrer digitalen Unterschrift für diese Zuordnung.

Welche Zertifikate stecken in einer Fachanwendung?

Eine Public-Key-Infrastruktur kennt die Zertifikate, die sie ausgestellt hat, aber nicht deren Einsatzort. Die liegen in Konfigurationsdateien, Schlüsselspeichern und Programmcode, und dokumentiert ist ein Einsatzort nur, wenn jemand ihn aufschreibt. In einer gewachsenen Landschaft aus Software für Großunternehmen, Middleware und Endgeräten kennt keine einzelne Stelle den Gesamtbestand. Das gilt für jedes PKI-Zertifikat, gleich welcher Herkunft.

Gemeint ist dabei nicht das ISO-27001-Zertifikat, das einer Organisation ein geprüftes Managementsystem bescheinigt, sondern das kryptografische Zertifikat eines Rechners. Beide gehören ins IT-Sicherheitsmanagement, verwechselt werden sollten sie nicht. Ein X.509-Zertifikat, das Format fast aller heutigen Zertifikate, findet sich in einer Fachanwendung an diesen Stellen:

Beim D-Trust-Widerruf musste jedes davon gefunden werden, bevor es sich tauschen ließ. Welche Angaben ein Verzeichnis braucht, damit es auch im Nachweis trägt, klärt der Abschnitt zum Zertifikatsinventar.

PKI-Zertifikat prüfen: was die Anwendung selbst leisten muss

Die Public-Key-Infrastruktur stellt Zertifikate aus und sperrt sie, sie entscheidet aber nicht, was eine Anwendung damit anfängt. Ob ein PKI-Zertifikat Sicherheit schafft oder einen Ausfall auslöst, hängt an vier Fähigkeiten der Software. Sie prüft die Vertrauenskette, wertet Sperrinformationen aus, übernimmt ein neues Zertifikat im laufenden Betrieb und meldet einen Fehler, statt still abzubrechen.

Für Beschäftigte übernimmt das meist ein zentrales Identitätsmanagement, weshalb sich Fachanwendungen an ein IAM anbinden lassen. Dienste, Server und Geräte weisen sich dagegen über Zertifikate aus, und für diese Maschinenidentitäten fehlt eine vergleichbare Übersicht.

Vertrauenskette bis zur Root-CA prüfen

Wie viel ein PKI-Zertifikat wert ist, hängt an der Stelle, die es unterschrieben hat. Deshalb prüft die Anwendung eine Kette, denn das X.509-Zertifikat des Servers trägt die Unterschrift einer Zwischenstelle, deren Zertifikat wiederum von der Root-CA unterschrieben ist. Eine Anwendung, die diese Prüfung abschaltet, verschlüsselt, weiß aber nicht, mit wem. Wird die Prüfung für eine Testumgebung deaktiviert und die Einstellung in den Betrieb übernommen, bleibt die Lücke unbemerkt, weil weiter alles funktioniert.

Sperrinformationen auswerten

Ein widerrufenes Zertifikat trägt weiter sein altes Ablaufdatum und sieht aus wie ein gültiges. Die Public-Key-Infrastruktur veröffentlicht den Widerruf als Sperrliste (CRL) oder beantwortet ihn per Online-Abfrage (OCSP), ob die Fachanwendung danach fragt, hängt an ihrer Programmierung. Eine Anwendung ohne Sperrprüfung vertraut einem widerrufenen Zertifikat weiter. Umgekehrt fällt die Anwendung, die korrekt prüft, bei einem Widerruf als erste aus, weshalb Sperrprüfung und schneller Tausch zusammengehören.

Zertifikatsbasierte Authentifizierung zwischen Diensten

Zertifikate können auch die aufrufende Seite einer Verbindung ausweisen. Bei mTLS, dem gegenseitigen TLS, zeigen beide Enden ihr Zertifikat vor, bevor Daten fließen. Diese zertifikatsbasierte Authentifizierung löst den statischen Zugangsschlüssel ab, der als Zeichenkette in einer Konfigurationsdatei liegt und in der API-Sicherheit als eigenes Risiko gilt. Ein Zertifikat läuft ab, ein kopierter Schlüssel gilt, bis ihn jemand bemerkt. Kurze Laufzeiten sind hier ein Vorteil, solange die Erneuerung automatisch läuft. Im Modell der Zero-Trust-Architektur ist mTLS deshalb die Technik, mit der ein Dienst bei jedem Aufruf belegt, wer er ist.

Public-Key-Infrastruktur im Dauerbetrieb: 200, 100, 47 Tage

Das CA/Browser Forum, der Zusammenschluss von Zertifikatsanbietern und Browserherstellern, hat im April 2025 beschlossen, die Laufzeit öffentlicher TLS-Zertifikate in drei Stufen zu kürzen. Seit dem 15. März 2026 gelten höchstens 200 Tage, ab dem 15. März 2027 noch 100 und ab dem 15. März 2029 noch 47. Vorher lag die Grenze bei 398 Tagen.

Aus einer Erneuerung im Jahr werden damit rund acht. Ein Zertifikatsmanagement per Kalendereintrag trägt dann nicht mehr. Die Regeln gelten für öffentlich vertrauenswürdige Zertifikate, eine private PKI für interne Dienste legt ihre Laufzeiten selbst fest.

Zertifikatsmanagement mit dem ACME-Protokoll

Das ACME-Protokoll, standardisiert als RFC 8555, automatisiert Beantragung und Erneuerung. Ein Programm auf dem Server weist der ausstellenden Stelle nach, dass es die Domain kontrolliert, holt das neue Zertifikat und legt es ab. Bekannt wurde es durch Let’s Encrypt, inzwischen unterstützen es auch kommerzielle Anbieter. Automatisiert ist damit nur die Ausstellung, nicht die Übernahme in die Anwendung.

Reicht ACME mit Let’s Encrypt für interne Dienste?

Für Dienste, die nur im eigenen Netz laufen, in der Regel nicht. Öffentliche Anbieter stellen Zertifikate nur für Namen aus, deren Kontrolle sich von außen prüfen lässt. Außerdem wird jedes öffentlich vertrauenswürdige Zertifikat in den Certificate-Transparency-Protokollen veröffentlicht, interne Servernamen wären damit für alle einsehbar. Für den Verkehr zwischen internen Diensten ist deshalb eine eigene Public-Key-Infrastruktur mit Root-CA der übliche Weg, und auch sie kann das ACME-Protokoll sprechen.

Zertifikat erneuern, ohne die Anwendung neu zu starten

Eine Anwendung, die ihr Zertifikat nur beim Start einliest, arbeitet nach dem Tausch mit dem alten weiter, bis sie jemand neu startet. Wer Zertifikate in Fachanwendungen automatisiert erneuern will, setzt deshalb in der Software an. Sie erkennt die neue Datei, lädt sie im laufenden Betrieb und prüft vor dem Umschalten, ob Schlüssel und Kette zusammenpassen. Ein Zertifikat erneuern heißt dann, eine Datei zu ersetzen, und nicht, einen Dienst anzuhalten.

Wenn ein Zertifikat abgelaufen ist

Jedes PKI-Zertifikat trägt ein festes Ablaufdatum, das die Public-Key-Infrastruktur beim Ausstellen festlegt. Ist ein Zertifikat abgelaufen, lehnt die Gegenseite die Verbindung ab, und die Oberfläche zeigt häufig nur einen allgemeinen Verbindungsfehler. Ein Zertifikatsmanagement, das die Restlaufzeit überwacht, warnt vorher und nennt im Fehlerfall diese Angaben:

Lohnt sich eine private PKI oder ein externer Dienst?

Für alles, was von außen erreichbar ist, braucht es Zertifikate einer öffentlich anerkannten Stelle, weil Browser und Partnersysteme nur diesen vertrauen. Für interne Dienste lässt sich eine eigene PKI aufbauen oder als verwalteter Dienst beziehen. Den Ausschlag gibt weniger die Software als der Schutz der Root-CA. Mit ihrem privaten Schlüssel lassen sich beliebige Identitäten ausstellen, und eine private PKI ist nur so sicher wie seine Aufbewahrung.

Für den Eigenbetrieb spricht es, wenn diese Punkte zutreffen:

An der Anwendung ändert die Wahl wenig, denn die PKI-Integration folgt in beiden Fällen denselben Standards.

Kryptografie im NIS-2-Nachweis belegen

Artikel 21 Absatz 2 Buchstabe h der NIS-2-Richtlinie verlangt Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung. In Deutschland gilt die Pflicht seit Dezember 2025 über das BSIG für besonders wichtige und wichtige Einrichtungen. Belegen lässt sich ein solches Konzept nur, wenn die Einrichtung weiß, wo sie Kryptografie einsetzt, und diesen Einsatz steuert. Die Public-Key-Infrastruktur liefert dafür nur einen Teil, der andere steckt in den Anwendungen.

Die Vorgabe steht neben Meldepflichten und Anforderungen an die Sicherheit in der Lieferkette, die gemeinsam in der IT-Compliance einer Einrichtung zusammenlaufen. Stammen die Fachanwendungen von Dienstleistern, wird die Offenlegung ihrer Zertifikate zur Anforderung an den Lieferanten.

Zertifikatsinventar: NIS-2 fragt nach dem Konzept

Ein Konzept bleibt Papier, solange offen ist, welche Zertifikate es betrifft. Ein Zertifikatsinventar schließt diese Lücke, als Verzeichnis, das Einsatzort und Zuständigkeit festhält. Mit ihm ist auch die Frage vom Anfang beantwortet, welche Anwendungen ein Widerruf trifft. Diese Angaben gehören je PKI-Zertifikat hinein:

❗ Einsatzort mit System und Dienst
❗ Aussteller und Vertrauenskette
❗ Ablaufdatum und Laufzeit
❗ Algorithmus und Schlüssellänge
❗ zuständige Person oder Stelle
❗ Weg der Erneuerung, automatisch oder von Hand

Aktuell bleibt das Inventar nur, wenn die Anwendungen ihre Zertifikate selbst melden. Deshalb gehört diese Meldefunktion ins Zertifikatsmanagement jeder Software, die in einer regulierten Einrichtung läuft.

Post-Quanten-Kryptografie beginnt im Zertifikatsmanagement

Quantencomputer, die heutige Verfahren wie RSA brechen, gibt es noch nicht. Das BSI rät trotzdem, den Umstieg auf Post-Quanten-Kryptografie jetzt einzuleiten und besonders sensible Anwendungen bis spätestens Ende 2030 umzustellen, weil heute mitgeschnittene Daten später entschlüsselt werden könnten. Betroffen ist jede Public-Key-Infrastruktur, denn ihre Zertifikate sind mit genau diesen Verfahren unterschrieben. Die Umstellung beginnt mit der Frage, wo die alten Verfahren arbeiten, und diese Antwort liefert das Inventar. Eine Anwendung, deren Verfahren sich per Konfiguration tauschen lässt, übersteht den Wechsel ohne Neuentwicklung.

Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.

FAQs

Woran lässt sich erkennen, ob eine Fachanwendung PKI-fähig ist? keyboard_arrow_down keyboard_arrow_up
Am sichersten im Test vor der Abnahme. Eine PKI-fähige Anwendung lehnt ein abgelaufenes, ein gesperrtes und ein von fremder Stelle ausgestelltes Zertifikat ab. Sie übernimmt ein neues ohne Neustart und nennt im Protokoll, welches Zertifikat einen Fehler ausgelöst hat.
Was kostet es, Zertifikatserneuerung in Bestandssoftware nachzurüsten? keyboard_arrow_down keyboard_arrow_up
Das hängt daran, an wie vielen Stellen die Software Zertifikate einliest. Liegt das Laden an einer Stelle, bleibt die Nachrüstung überschaubar, ist es über den Code verteilt, wird ein Umbau daraus. TenMedia klärt das in einem Code-Audit und rüstet automatische Erneuerung in Individualsoftware nach.
Was passiert mit unserer Software, wenn ein Zertifikat zurückgerufen wird? keyboard_arrow_down keyboard_arrow_up
Ab dem Zeitpunkt des Widerrufs lehnt jede Gegenstelle, die den Sperrstatus prüft, Verbindungen mit diesem Zertifikat ab. Für die eigene Software beginnt dann ein Wettlauf in drei Schritten. Zuerst müssen alle Stellen gefunden werden, an denen das Zertifikat hinterlegt ist. Ohne Verzeichnis dauert dieser Schritt am längsten, weil unter Zeitdruck gesucht wird. Danach wird ein neues beantragt und eingespielt, möglichst mit einem frisch erzeugten Schlüssel statt dem alten. Zuletzt wird geprüft, ob jede Verbindung wieder steht. Wie schnell das gelingt, entscheidet nicht die Public-Key-Infrastruktur, sondern die Anwendung.