Verschlüsselung: Wie sie funktioniert, wie sicher sie ist und worauf es heute ankommt

Verschlüsselung begegnet uns häufig im Zusammenhang mit HTTPS und SSL-/TLS-Zertifikaten. Doch sie reicht wesentlich weiter: Unternehmen müssen nicht nur Verbindungen zu Websites schützen, sondern auch gespeicherte Daten, E-Mails, Backups, mobile Endgeräte, Datenbanken, Cloud-Anwendungen, Software und die Kommunikation zwischen Maschinen.

SSL-/TLS-Zertifikate sind dabei ein wichtiger Baustein. Sie unterstützen die Authentisierung von Kommunikationspartnern und ermöglichen den Aufbau geschützter Verbindungen. Eine umfassende Verschlüsselungsstrategie ersetzen sie jedoch nicht. Ein korrekt eingerichtetes TLS-Zertifikat schützt beispielsweise weder eine unverschlüsselte Datenbank noch ein offen zugängliches Backup oder einen kompromittierten privaten Schlüssel.

Wie sicher Verschlüsselung tatsächlich ist, hängt deshalb nicht allein vom verwendeten Algorithmus ab. Ebenso entscheidend sind die Schlüsselverwaltung, die konkrete Implementierung, aktuelle Protokolle, sichere Endgeräte und kontrollierte Zertifikatsprozesse. Dieser Beitrag erklärt die wichtigsten Grundlagen, Verfahren und Anwendungsbereiche – und zeigt, worauf Unternehmen heute sowie mit Blick auf kürzere Zertifikatslaufzeiten und Post-Quanten-Kryptografie achten sollten.

Das Wichtigste zur Verschlüsselung in Kürze:

• Verschlüsselung ist mehr als HTTPS: Sie schützt Daten bei der Übertragung, bei der Speicherung und – abhängig vom Verfahren – über den gesamten Kommunikationsweg hinweg.
• Unterschiedliche Schutzziele benötigen unterschiedliche Verfahren: Verschlüsselung sorgt in erster Linie für Vertraulichkeit. Hashfunktionen, digitale Signaturen und Zertifikate unterstützen zusätzlich Integrität, Authentizität und Nachweisbarkeit.
• Aktuelle Algorithmen allein reichen nicht aus: Sichere Schlüssel, korrekt konfigurierte Systeme, kontrollierte Zugriffsrechte und geregelte Lebenszyklen sind ebenso wichtig.
• Digitale Zertifikate sind nicht auf Websites beschränkt: Neben SSL-/TLS-Zertifikaten gibt es unter anderem S/MIME-, Code-Signing-, Signatur-, Client- und Gerätezertifikate.
• Unternehmen müssen Krypto-Agilität aufbauen: Kürzere Zertifikatslaufzeiten und die bevorstehende Migration zu Post-Quanten-Verfahren erhöhen den Bedarf an Inventarisierung, Automatisierung und austauschbaren kryptografischen Komponenten.

Was ist Verschlüsselung und wie funktioniert sie?

Verschlüsselung bezeichnet die Umwandlung lesbarer Informationen in eine Form, die für unbefugte Personen nicht verständlich sein soll. Aus dem ursprünglichen Klartext entsteht mithilfe eines kryptografischen Verfahrens und eines Schlüssels ein verschlüsselter Text, das sogenannte Chiffrat.

Wer über den passenden Schlüssel verfügt, kann die Informationen wieder entschlüsseln. Ohne diesen Schlüssel soll es praktisch nicht möglich sein, den Klartext wiederherzustellen. Wie belastbar dieser Schutz ist, hängt unter anderem vom eingesetzten Verfahren, von der Schlüssellänge, von der Implementierung und vom Schutz des Schlüsselmaterials ab.

Verschlüsselung kann Kommunikationsverbindungen, Dateien, Datenbanken, Datenträger oder einzelne Nachrichten schützen. Entscheidend ist daher nicht nur, ob verschlüsselt wird, sondern auch, welche Daten, an welcher Stelle und gegen welche Risiken geschützt werden sollen.

Welche Schutzziele Verschlüsselung unterstützt

Verschlüsselung dient in erster Linie der Vertraulichkeit. Sie soll verhindern, dass Unbefugte Informationen lesen können. Für sichere digitale Kommunikation sind jedoch weitere Schutzziele relevant:

• Integrität: Veränderungen an Daten sollen erkennbar sein.
• Authentizität: Die Identität eines Absenders, Servers, Geräts oder Herausgebers soll überprüfbar sein.
• Nachweisbarkeit: In bestimmten Anwendungsfällen soll nachvollziehbar sein, wer eine Erklärung abgegeben oder ein Dokument signiert hat.

Verschlüsselung allein erfüllt diese Ziele nicht automatisch. Deshalb wird sie häufig mit Hashfunktionen, digitalen Signaturen, Message Authentication Codes und digitalen Zertifikaten kombiniert.

Symmetrische und asymmetrische Verschlüsselung

Verschlüsselung basiert grundsätzlich auf zwei Ansätzen: der symmetrischen und der asymmetrischen Verschlüsselung.

Bei der symmetrischen Verschlüsselung verwenden Sender und Empfänger denselben geheimen Schlüssel. Da diese Verfahren vergleichsweise effizient arbeiten, eignen sie sich unter anderem für große Datenmengen, Datenträger, Dateien, Backups und laufende Netzwerkverbindungen. Entscheidend ist, dass der gemeinsame Schlüssel sicher verteilt und gespeichert wird.

Die asymmetrische Kryptografie arbeitet mit einem öffentlichen und einem privaten Schlüssel. Der öffentliche Schlüssel darf verteilt werden, während der private Schlüssel geschützt bleiben muss. Je nach Verfahren können damit Daten geschützt, gemeinsame Geheimnisse vereinbart oder digitale Signaturen erzeugt und geprüft werden.

In der Praxis werden beide Ansätze häufig kombiniert: Asymmetrische Kryptografie unterstützt die Authentisierung oder die sichere Vereinbarung eines gemeinsamen Geheimnisses. Die eigentlichen Nutzdaten werden anschließend effizient mit einem symmetrischen Verfahren verschlüsselt.

Verschlüsselung, Hashing und digitale Signaturen

Hashfunktionen und digitale Signaturen werden häufig gemeinsam mit Verschlüsselung eingesetzt, erfüllen jedoch andere Aufgaben.

Eine Hashfunktion berechnet aus Daten einen Prüfwert fester Länge. Bereits kleine Änderungen an den Ausgangsdaten sollen zu einem deutlich anderen Hashwert führen. Hashfunktionen dienen unter anderem der Integritätsprüfung und sind nicht für eine spätere Entschlüsselung vorgesehen.

Digitale Signaturen verbinden einen solchen Prüfwert mit einem privaten Signaturschlüssel. Mit dem zugehörigen öffentlichen Schlüssel kann geprüft werden, ob die Signatur gültig ist und ob die signierten Daten nachträglich verändert wurden.

Digitale Zertifikate ordnen öffentliche Schlüssel einer überprüften Identität oder einem festgelegten Einsatzzweck zu. Auf dieser Grundlage entsteht Digital Trust durch Zertifikate und Public Key Infrastructure.

Warum Verschlüsselung nicht automatisch Sicherheit garantiert

Auch ein mathematisch starkes Verfahren kann seine Schutzwirkung verlieren, wenn Schlüssel unzureichend geschützt, Systeme falsch konfiguriert oder Endgeräte kompromittiert sind. Verschlüsselung muss deshalb in ein Sicherheitskonzept eingebettet sein, das auch Implementierung, Berechtigungen, Schlüsselmanagement und den kontrollierten Austausch veralteter Verfahren berücksichtigt.

Verschlüsselung ist mehr als SSL und TLS

Viele Menschen verbinden Verschlüsselung vor allem mit HTTPS und SSL-/TLS-Zertifikaten. Diese sind ein wichtiger Bestandteil sicherer digitaler Kommunikation, decken jedoch nur einen bestimmten Anwendungsbereich ab: den Aufbau authentisierter und verschlüsselter Verbindungen zwischen Kommunikationspartnern. Unternehmen müssen darüber hinaus auch gespeicherte und verarbeitete Informationen absichern.

Daten bei der Übertragung, Speicherung und Verarbeitung

Eine wirksame Verschlüsselungsstrategie betrachtet den gesamten Lebenszyklus schützenswerter Informationen. Dabei werden drei Datenzustände unterschieden: Data in Transit, Data at Rest und Data in Use. Ein TLS-Zertifikat kann beispielsweise die Verbindung zwischen Browser und Webserver schützen, verschlüsselt aber nicht automatisch die dahinterliegende Datenbank oder ein gespeichertes Backup.

Datenzustand	Bedeutung	Typische Schutzmaßnahmen	Grenzen
Data in Transit	Daten werden zwischen Systemen, Anwendungen, Benutzern oder Geräten übertragen.	TLS, VPN oder DTLS	Transportverschlüsselung schützt nur den abgesicherten Verbindungsabschnitt.
Data at Rest	Daten liegen beispielsweise in Dateien, Datenbanken, Backups oder Cloud-Speichern.	Festplatten-, Datei-, Datenbank- oder Backup-Verschlüsselung	Die Schutzwirkung hängt wesentlich vom sicheren Schlüsselmanagement ab.
Data in Use	Daten werden von einer Anwendung oder einem System verarbeitet.	Zugriffskontrollen, Isolation und geschützte Ausführungsumgebungen	Die Daten können während der Verarbeitung zeitweise im Klartext vorliegen.

Verschlüsselung kann zudem auf unterschiedlichen Ebenen ansetzen – vom vollständigen Datenträger über einzelne Dateien und Datenbanken bis zu besonders sensiblen Datenfeldern. Welche Ebene geeignet ist, hängt vom Schutzbedarf, den Zugriffsanforderungen und den eingesetzten Anwendungen ab.

Transportverschlüsselung und Ende-zu-Ende-Verschlüsselung

Transportverschlüsselung schützt jeweils die Verbindung zwischen zwei Systemen. Auf den beteiligten Endpunkten kann der Inhalt jedoch entschlüsselt und verarbeitet werden. Bei einer E-Mail können daher mehrere einzeln geschützte Transportabschnitte bestehen, ohne dass die Nachricht über den gesamten Weg ausschließlich für Absender und Empfänger lesbar bleibt.

Bei einer Ende-zu-Ende-Verschlüsselung wird der Inhalt dagegen auf dem Gerät des Absenders verschlüsselt und erst beim vorgesehenen Empfänger wieder entschlüsselt. Zwischenstationen sollen nicht über die dafür erforderlichen Schlüssel verfügen.

Typische Einsatzbereiche sind verschlüsselte Messenger, Dateiübertragungen oder E-Mails mit S/MIME beziehungsweise OpenPGP. Auch Ende-zu-Ende-Verschlüsselung schützt jedoch nicht automatisch vor kompromittierten Endgeräten. Schadsoftware kann Inhalte erfassen, bevor sie verschlüsselt oder nachdem sie entschlüsselt wurden.

Mehrschichtiger Schutz statt einzelner Lösung

Keine einzelne Maßnahme schützt Daten in allen Zuständen. Unternehmen sollten Transport-, Speicher- und Ende-zu-Ende-Verschlüsselung deshalb mit sicherer Authentisierung, Zugriffskontrollen und kontrolliertem Schlüsselmanagement zu einem mehrschichtigen Schutzkonzept verbinden.

Welche kryptografischen Verfahren gelten heute als zeitgemäß?

Moderne Sicherheitssysteme kombinieren unterschiedliche kryptografische Bausteine. Dazu gehören symmetrische Verfahren für die Verschlüsselung großer Datenmengen, Public-Key-Verfahren für Schlüsseleinigung und digitale Signaturen, Hashfunktionen sowie Protokolle wie Transport Layer Security (TLS).

Welches Verfahren geeignet ist, hängt von seiner Aufgabe, der erforderlichen Schutzdauer und der eingesetzten Systemumgebung ab. Die Technische Richtlinie BSI TR-02102-1 des Bundesamts für Sicherheit in der Informationstechnik (BSI) bietet hierfür eine regelmäßig aktualisierte Orientierung.

Für die Verschlüsselung von Nutzdaten kommen häufig der Advanced Encryption Standard im Galois/Counter Mode (AES-GCM) und ChaCha20-Poly1305 zum Einsatz. Beide gehören zu den AEAD-Verfahren. AEAD steht für Authenticated Encryption with Associated Data und verbindet Verschlüsselung mit einem Schutz vor unbemerkten Veränderungen.

<

Verfahren	Typische Aufgabe	Einordnung
AES-GCM und ChaCha20-Poly1305	Symmetrische Verschlüsselung und Integritätsschutz	Zeitgemäße AEAD-Verfahren bei korrekter Implementierung
X25519	Vereinbarung gemeinsamer Sitzungsschlüssel	Zeitgemäß in unterstützten Protokollen
Digitale Signaturen; RSA je nach Einsatz auch für bestimmte Verschlüsselungsanwendungen	Digitale Signaturen sowie je nach Verfahren weitere Public-Key-Funktionen	RSA ist weiterhin verbreitet; ECDSA und Ed25519 sind moderne Signaturverfahren
SHA-2 und SHA-3	Kryptografisches Hashing	Zeitgemäß; MD5 und SHA-1 sollten nicht für neue Sicherheitsanwendungen eingesetzt werden
ML-KEM, ML-DSA und SLH-DSA	Post-Quanten-Schlüsselkapselung und digitale Signaturen	Standardisierte Verfahren für die schrittweise PQC-Migration
TLS 1.3	Geschützte Netzwerkkommunikation	Aktuelle TLS-Version, die mehrere kryptografische Verfahren kombiniert

Der Algorithmus allein entscheidet jedoch nicht über die Sicherheit. Ebenso wichtig sind eine korrekte Implementierung, sichere Zufallswerte, geeignete Parameter, geschützte Schlüssel und aktuelle kryptografische Bibliotheken.

Warum Schlüsselmanagement über die Sicherheit entscheidet

Kryptografische Verfahren können nur so sicher sein wie die Schlüssel, auf denen sie beruhen. Wird ein privater oder symmetrischer Schlüssel entwendet, unberechtigt kopiert, versehentlich gelöscht oder zu lange verwendet, kann selbst ein moderner Algorithmus seine Schutzwirkung verlieren.

Schlüsselmanagement umfasst deshalb den gesamten Lebenszyklus kryptografischer Schlüssel: von ihrer sicheren Erzeugung und Speicherung über die kontrollierte Nutzung und Rotation bis zur Sperrung und Vernichtung. Neben technischen Schutzmaßnahmen sind dafür klare Zuständigkeiten, geregelte Berechtigungen und vorbereitete Notfallprozesse erforderlich.

Unternehmen sollten jederzeit wissen, welche Schlüssel existieren, wo sie eingesetzt werden und wer für sie verantwortlich ist. Zertifikatsmanagement und Schlüsselmanagement müssen dabei aufeinander abgestimmt werden, sind aber nicht identisch: Ein Zertifikat enthält den öffentlichen Schlüssel, während der zugehörige private Schlüssel separat geschützt werden muss.

Besteht der Verdacht auf eine Kompromittierung, darf der betroffene Schlüssel nicht länger als vertrauenswürdig gelten. Welche Schritte dann erforderlich sind, erläutert unser Beitrag zum Umgang mit einem kompromittierten privaten Schlüssel.

Digitale Zertifikate sind mehr als SSL-/TLS-Zertifikate

Digitale Zertifikate werden häufig mit HTTPS und der Absicherung von Websites gleichgesetzt. Sie können jedoch ebenso E-Mail-Absender, Softwarehersteller, unterzeichnende Personen, Benutzer, Geräte und technische Dienste authentisieren.

Ein digitales Zertifikat verbindet einen öffentlichen Schlüssel mit einer Identität oder einem festgelegten Einsatzzweck. Das Zertifikat selbst ist weder ein Verschlüsselungsalgorithmus noch ein geheimer Schlüssel. Der zugehörige private Schlüssel muss getrennt davon geschützt werden.

Welche Zertifikatsart erfüllt welchen Zweck?

Zertifikatsart	Primäre Aufgabe	Typischer Einsatz	Grenzen
SSL-/TLS-Zertifikat	Server oder Domain authentisieren	Websites, APIs, Mailserver und mTLS	Verschlüsselt keine gespeicherten Daten und garantiert nicht die Seriosität eines Angebots.
S/MIME-Zertifikat	E-Mails signieren und verschlüsseln	Vertrauliche Unternehmenskommunikation	Schützt keine kompromittierten Endgeräte.
Code-Signing-Zertifikat	Herkunft und Integrität von Code überprüfbar machen	Software, Skripte, Treiber und Updates	Verschlüsselt den Code nicht und garantiert keine Schadfreiheit.
Signaturzertifikat	Digitale Signaturen einer Identität zuordnen	Verträge, Freigaben und digitale Dokumente	Verschlüsselt den Dokumentinhalt nicht automatisch.
Client-, Geräte- oder Maschinenzertifikat	Benutzer, Anwendungen und technische Systeme authentisieren	VPN, APIs, mTLS, IoT und interne Dienste	Ersetzt keine Berechtigungsprüfung und schützt keine unsicheren Endgeräte.

Client-, Geräte- und Maschinenzertifikate

Bei Mutual TLS (mTLS) weisen sich beide Kommunikationspartner mit Zertifikaten aus. Server- und Client-Zertifikate erfüllen dabei unterschiedliche Aufgaben und sollten entsprechend getrennte Zertifikatsprofile verwenden. Diese Trennung unterschiedlicher Zertifikatszwecke gewinnt zunehmend an Bedeutung. Weitere technische Hintergründe bietet unser Beitrag zu den Änderungen an der Client-Authentifizierungs-EKU.

Geräte- und Maschinenzertifikate geben Cloud-Workloads, internen Diensten, Produktionssystemen und IoT-Geräten überprüfbare Identitäten. Mit der Zahl solcher Maschinenidentitäten wächst auch der Aufwand für Ausstellung, Erneuerung und Widerruf. Bei langlebigen Geräten müssen Zertifikate über den gesamten Lebenszyklus verwaltet werden, wie unser Beitrag zur IoT-Sicherheit mit Zertifikaten und PKI zeigt.

Zertifikate können außerdem einen Baustein von Zero-Trust-Architekturen bilden. Sie liefern überprüfbare Identitätsinformationen; ob eine Identität auf eine Ressource zugreifen darf, muss jedoch weiterhin durch geeignete Richtlinien und Berechtigungen entschieden werden.

Unternehmen sollten daher nicht nur ihre öffentlich erreichbaren TLS-Zertifikate kennen. Auch S/MIME-, Code-Signing-, Signatur-, Client- und Maschinenzertifikate gehören in die Inventarisierungs- und Sicherheitsprozesse. Ihre Vertrauenswürdigkeit hängt von einer korrekten Ausstellung, geschützten privaten Schlüsseln und einem kontrollierten Lebenszyklus ab.

Wie SSL-/TLS-Zertifikate verschlüsselte Kommunikation ermöglichen

SSL-/TLS-Zertifikate gehören zu den bekanntesten Anwendungen moderner Kryptografie. Sie unterstützen die Authentisierung eines Servers und ermöglichen den Aufbau einer verschlüsselten Verbindung zwischen Kommunikationspartnern.

Das Zertifikat verschlüsselt die übertragenen Daten dabei nicht selbst. Es enthält unter anderem den öffentlichen Schlüssel und Informationen zur geprüften Identität beziehungsweise Domain. Das TLS-Protokoll nutzt diese Angaben beim Verbindungsaufbau, um den Kommunikationspartner zu authentisieren und gemeinsame Sitzungsschlüssel zu etablieren.

Die eigentlichen Nutzdaten werden anschließend mit einem effizienten symmetrischen Verfahren verschlüsselt. Zertifikat, Public-Key-Kryptografie, symmetrische Verschlüsselung und TLS übernehmen damit unterschiedliche, aufeinander abgestimmte Aufgaben.

SSL, TLS und HTTPS: Was ist der Unterschied?

Secure Sockets Layer (SSL) bezeichnet ältere Protokollversionen für geschützte Netzwerkverbindungen. Diese gelten heute als überholt. Der technische Nachfolger ist Transport Layer Security (TLS).

Der Begriff „SSL-Zertifikat“ wird im allgemeinen Sprachgebrauch dennoch weiterhin verwendet. Technisch handelt es sich um X.509-Zertifikate, die innerhalb einer TLS-Verbindung eingesetzt werden.

HTTPS steht für Hypertext Transfer Protocol Secure und bezeichnet die Übertragung von HTTP innerhalb eines geschützten TLS-Kanals. Vereinfacht gilt:

• TLS ist das kryptografische Kommunikationsprotokoll.
• Das TLS-Zertifikat unterstützt die Authentisierung und den sicheren Verbindungsaufbau.
• HTTPS bezeichnet HTTP-Kommunikation über TLS.

TLS ist nicht auf Websites beschränkt. Das Protokoll wird auch für Schnittstellen, E-Mail-Transport, Datenbankverbindungen, Cloud-Dienste und die Kommunikation zwischen Maschinen eingesetzt. Die aktuelle Protokollversion ist TLS 1.3.

Zertifizierungsstellen und die Vertrauenskette

Öffentlich vertrauenswürdige TLS-Zertifikate basieren auf einer Public Key Infrastructure (PKI). Zertifizierungsstellen – auch Certification Authorities (CA) genannt – prüfen Zertifikatsanträge und bestätigen die Zuordnung eines öffentlichen Schlüssels zu einer Domain oder Organisation.

Die Vertrauenskette besteht typischerweise aus drei Ebenen:

• Root-Zertifikat: der in Browsern, Betriebssystemen oder Anwendungen hinterlegte Vertrauensanker,
• Intermediate-Zertifikat: eine untergeordnete Zertifizierungsstelle, die Zertifikate ausstellt,
• Serverzertifikat: das für eine Domain oder einen Dienst ausgestellte Zertifikat.

Beim Verbindungsaufbau prüft der Client unter anderem, ob das Zertifikat zum aufgerufenen Hostnamen passt, gültig ist und auf einen anerkannten Vertrauensanker zurückgeführt werden kann. Dadurch wird es Angreifern erschwert, sich mit einem eigenen Zertifikat als legitimer Server auszugeben.

Was Zertifikat und Browseranzeige aussagen

Eine erfolgreiche HTTPS-Verbindung bestätigt, dass zwischen dem Browser und dem aufgerufenen Host ein geschützter Kommunikationskanal aufgebaut und das Zertifikat erfolgreich geprüft wurde. Sie garantiert jedoch nicht, dass die Website seriös, frei von Schadsoftware oder sicher konfiguriert ist. Auch Phishing-Websites können ein gültiges Domainzertifikat besitzen.

TLS-Zertifikate unterscheiden sich außerdem nach dem Umfang der Identitätsprüfung:

• Domain Validation (DV): Prüfung der Kontrolle über die Domain,
• Organization Validation (OV): zusätzliche Prüfung der Organisation,
• Extended Validation (EV): erweiterte Organisationsprüfung nach Vorgaben des CA/Browser Forums.

Die Validierungsstufe verändert nicht automatisch die Stärke der TLS-Verschlüsselung. Die Unterschiede betreffen vor allem den Umfang der geprüften Identitätsinformationen. Auch die früher mit EV-Zertifikaten verbundene grüne Adressleiste ist heute kein geeignetes Auswahlkriterium mehr.

Verschlüsselung nach DSGVO und NIS2

Art. 32 der Datenschutz-Grundverordnung (DSGVO) nennt die Pseudonymisierung und Verschlüsselung personenbezogener Daten ausdrücklich als mögliche technische Maßnahmen. Welche Maßnahmen erforderlich sind, hängt vom Risiko, vom Stand der Technik und von der konkreten Verarbeitung ab.

Daraus folgt keine pauschale Vorgabe, sämtliche personenbezogenen Daten mit demselben Verfahren zu verschlüsseln. Für Webformulare, Kundenportale oder Schnittstellen, über die personenbezogene Daten übertragen werden, gehört eine angemessene Transportverschlüsselung jedoch regelmäßig zu den grundlegenden Schutzmaßnahmen.

Auch die NIS2-Richtlinie nennt Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung als Bestandteil des Cybersicherheitsrisikomanagements. Verschlüsselung ist dabei Teil eines umfassenden Maßnahmenpakets, das unter anderem Risikoanalyse, Zugriffskontrolle, Incident Management und die Sicherheit der Lieferkette umfasst.

Ein gültiges TLS-Zertifikat allein belegt daher weder eine vollständige DSGVO-Konformität noch die Erfüllung aller NIS2-Anforderungen. Eine angemessen konfigurierte Transportverschlüsselung ist jedoch ein wichtiger Baustein der technischen Absicherung.

Von 200 auf 100 und 47 Tage: TLS-Zertifikate werden kurzlebiger

Die maximale Laufzeit öffentlich vertrauenswürdiger TLS-Serverzertifikate wird stufenweise verkürzt:

Ausstellungszeitraum	Maximale Zertifikatslaufzeit
ab 15. März 2026	200 Tage
ab 15. März 2027	100 Tage
ab 15. März 2029	47 Tage

Parallel verkürzen sich die Zeiträume, in denen bereits geprüfte Domain- und IP-Adressdaten für eine erneute Zertifikatsausstellung verwendet werden dürfen. Ab dem 15. März 2029 beträgt dieser Zeitraum nur noch zehn Tage.

Der Stufenplan gilt ausschließlich für öffentlich vertrauenswürdige TLS-Serverzertifikate. Für andere Zertifikatsarten bestehen eigene Vorgaben: Bei Code-Signing-Zertifikaten wurde die maximale Laufzeit für Ausstellungen ab dem 1. März 2026 beispielsweise von 39 Monaten auf 460 Tage reduziert. Weitere Einzelheiten erläutert unser Beitrag zur verkürzten Gültigkeitsdauer von Code-Signing-Zertifikaten. Auch für öffentlich vertrauenswürdige S/MIME-Zertifikate gelten profilspezifische Höchstlaufzeiten und weiterentwickelte Anforderungen, die wir im Beitrag zu den veränderten Gültigkeitsvorgaben für S/MIME-Zertifikate zusammenfassen.

Kürzere Laufzeiten begrenzen den Zeitraum, in dem veraltete oder fehlerhaft ausgestellte Zertifikate genutzt werden können. Gleichzeitig steigt die Zahl der notwendigen Erneuerungen deutlich. Einen ausführlichen Überblick über die einzelnen Stufen und ihre betrieblichen Folgen bietet unser Beitrag zu den kürzeren Laufzeiten von SSL-/TLS-Zertifikaten.

Warum Automatisierung und Certificate Lifecycle Management wichtiger werden

Je kürzer Zertifikate gültig sind, desto häufiger müssen sie validiert, ausgestellt, verteilt und überprüft werden. Manuelle Prozesse mit Kalendererinnerungen, E-Mails und Einzeltickets werden dadurch zunehmend fehleranfällig.

Das Automated Certificate Management Environment (ACME) ist ein standardisiertes Protokoll, mit dem sich unter anderem Domainvalidierung, Zertifikatsanforderung, Ausstellung und Erneuerung automatisieren lassen.

ACME allein schafft jedoch keine vollständige Übersicht über alle Zertifikate, Verantwortlichen und Risiken eines Unternehmens. Certificate Lifecycle Management (CLM) betrachtet deshalb den gesamten Zertifikatslebenszyklus. Dazu gehören:

• Discovery und Inventarisierung,
• Anforderung und Genehmigung,
• Ausstellung und Bereitstellung,
• Überwachung von Laufzeiten und Konfigurationen,
• Erneuerung und Rotation,
• Widerruf und Stilllegung.

ACME und CLM erfüllen damit unterschiedliche, aber ergänzende Aufgaben: ACME automatisiert technische Abläufe, während CLM Transparenz, Governance und Kontrolle über den gesamten Bestand schafft.

Wie Unternehmen diese Prozesse aufbauen können, erläutert unser Grundlagenbeitrag zum Certificate Lifecycle Management.

Die verkürzten Zertifikatslaufzeiten sind deshalb nicht nur eine organisatorische Mehrbelastung. Sie sind ein Anlass, Zertifikatsmanagement als automatisierten und überprüfbaren Sicherheitsprozess aufzubauen.

Warum Hintertüren die Sicherheit von Verschlüsselung schwächen

Starke Verschlüsselung schützt private Kommunikation, Geschäftsgeheimnisse, personenbezogene Daten und kritische Infrastrukturen. Gleichzeitig erschwert sie unter bestimmten Umständen den Zugriff von Strafverfolgungs- und Sicherheitsbehörden auf Kommunikationsinhalte. Wird deshalb ein zusätzlicher Zugang für Dritte geschaffen, verändert sich die Sicherheitsarchitektur: Es entsteht ein weiterer Mechanismus, der geschützt, kontrolliert und dauerhaft sicher betrieben werden muss.

Als Hintertür oder Backdoor gilt ein absichtlich eingebauter Zugangsweg, etwa über zentral hinterlegte Schlüssel oder besondere Entschlüsselungsschnittstellen. Client-Side-Scanning ist technisch keine klassische Hintertür, verändert das Vertraulichkeitsversprechen aber ebenfalls, weil Inhalte auf dem Endgerät vor der Verschlüsselung oder nach der Entschlüsselung analysiert werden. Beide Ansätze schaffen zusätzliche Risiken, etwa durch gestohlene Berechtigungen, Fehlklassifikationen oder den Missbrauch ursprünglich begrenzter Zugriffsmöglichkeiten.

Der 2015 bekannt gewordene FREAK-Angriff zeigte zudem, dass bewusst geschwächte Kryptografie lange in Systemen fortbestehen und später zur allgemeinen Angriffsfläche werden kann. FREAK, Client-Side-Scanning und kryptografische Hintertüren sind technisch nicht gleichzusetzen. Sie verdeutlichen jedoch, dass zusätzliche Zugriffswege und Sondermechanismen die Sicherheit verschlüsselter Kommunikation nachhaltig schwächen können.

Post-Quanten-Kryptografie: Warum Unternehmen jetzt handeln sollten

Leistungsfähige Quantencomputer könnten langfristig einen Teil der heute verbreiteten Public-Key-Kryptografie gefährden. Betroffen wären insbesondere RSA und Verfahren auf Basis elliptischer Kurven. Noch ist nicht absehbar, wann ein kryptografisch relevanter Quantencomputer verfügbar sein wird. Die Ablösung tief in Anwendungen, Geräten, Zertifikaten und Protokollen verankerter Verfahren kann jedoch viele Jahre dauern.

„Harvest now, decrypt later“ gefährdet langfristig vertrauliche Daten

Beim sogenannten Harvest now, decrypt later zeichnen Angreifer verschlüsselte Kommunikation bereits heute auf, um sie später mit leistungsfähigeren technischen Mitteln zu entschlüsseln. Das Risiko betrifft vor allem Informationen, die über viele Jahre vertraulich bleiben müssen – etwa Geschäftsgeheimnisse, Forschungs-, Gesundheits- oder strategische Unternehmensdaten.

Entscheidend ist daher nicht nur, wann geeignete Quantencomputer verfügbar sein könnten. Unternehmen müssen auch berücksichtigen, wie lange ihre Daten geschützt bleiben müssen und wie viel Zeit die Umstellung betroffener Systeme benötigt.

Post-Quanten-Standards und hybride Verfahren

Das National Institute of Standards and Technology (NIST) veröffentlichte 2024 mit ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), ML-DSA (Module-Lattice-Based Digital Signature Algorithm) und SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) die ersten finalen Standards für Post-Quanten-Kryptografie. Sie sind für die Etablierung gemeinsamer Geheimnisse beziehungsweise für digitale Signaturen vorgesehen und können grundsätzlich auf klassischer Hardware eingesetzt werden.

Während der Übergangsphase kommen teilweise hybride Verfahren zum Einsatz. Sie kombinieren klassische Kryptografie mit einem Post-Quanten-Verfahren. Dadurch soll die Verbindung geschützt bleiben, solange mindestens einer der verwendeten Bausteine sicher ist. Ob solche Verfahren produktiv eingesetzt werden können, hängt unter anderem von der Unterstützung durch Anwendungen, Clients, Server und kryptografische Bibliotheken ab.

Krypto-Agilität schafft die Voraussetzung für den Wechsel

Die PQC-Migration ist nicht nur eine Frage neuer Algorithmen. Unternehmen müssen kryptografische Verfahren, Schlüsseltypen, Zertifikate und Parameter kontrolliert austauschen können, ohne den Geschäftsbetrieb zu unterbrechen. Diese Fähigkeit wird als Krypto-Agilität bezeichnet.

Voraussetzung dafür ist ein Überblick über die eingesetzte Kryptografie. Ein Zertifikatsinventar allein genügt nicht: Auch Algorithmen, Schlüssel, Protokolle, Bibliotheken, Anwendungen, Geräte und externe Abhängigkeiten müssen berücksichtigt werden. Besonders kritisch sind fest einprogrammierte Verfahren, nicht aktualisierbare Geräte und unbekannte kryptografische Komponenten in Legacy-Systemen.

Unternehmen sollten daher zunächst ermitteln, wo gefährdete Verfahren eingesetzt werden, welche Daten langfristig geschützt bleiben müssen und welche Systeme sich später kontrolliert umstellen lassen. Diese Bestandsaufnahme bildet die Grundlage, um den Migrationsbedarf zu priorisieren und spätere Verfahrenswechsel kontrolliert vorzubereiten.

Weitere technische und organisatorische Hintergründe finden Sie in unserem Grundlagenbeitrag zur Post-Quanten-Kryptografie. Einen Überblick über wichtige Entwicklungsschritte bietet außerdem unsere PQC-Timeline.

Der wichtigste erste Schritt ist nicht der sofortige Austausch aller Verfahren, sondern Transparenz. Wer heute weiß, welche Kryptografie eingesetzt wird und welche Abhängigkeiten bestehen, kann die spätere Migration gezielt priorisieren und vorbereiten.

Verschlüsselung als kontinuierliche Sicherheitsaufgabe

Verschlüsselung ist kein einzelnes Produkt und keine einmalige technische Maßnahme. Sie entsteht aus dem Zusammenspiel geeigneter Algorithmen, sicherer Protokolle, geschützter Schlüssel, vertrauenswürdiger Zertifikate und klar geregelter Prozesse.

Unternehmen müssen dabei den gesamten Lebenszyklus ihrer Daten betrachten. Informationen benötigen während der Übertragung, bei der Speicherung und während der Verarbeitung unterschiedliche Schutzmaßnahmen. SSL-/TLS-Zertifikate sichern wichtige Kommunikationswege ab, ersetzen jedoch weder Speicherverschlüsselung noch Ende-zu-Ende-Verfahren, Zugriffskontrollen oder ein belastbares Schlüsselmanagement.

Gleichzeitig verändern sich die Rahmenbedingungen. Kürzere Zertifikatslaufzeiten erhöhen den Automatisierungsbedarf, neue regulatorische Anforderungen rücken Kryptografie stärker in den Fokus, und die Post-Quanten-Kryptografie erfordert eine langfristige Migrationsplanung. Unternehmen sollten deshalb nicht nur prüfen, welche Verfahren heute eingesetzt werden, sondern auch, wie schnell sie Zertifikate, Schlüssel und Algorithmen künftig austauschen können.

Der wichtigste Ausgangspunkt ist Transparenz: Welche Daten müssen geschützt werden? Welche Zertifikate und Schlüssel sind im Einsatz? Wo werden veraltete Verfahren verwendet? Welche Systeme lassen sich automatisieren und welche Abhängigkeiten erschweren einen späteren Wechsel?

Wer diese Fragen systematisch beantwortet, schafft die Grundlage für eine belastbare Verschlüsselungsstrategie. Entscheidend ist dabei nicht, überall möglichst viele kryptografische Verfahren einzusetzen, sondern für jeden Anwendungsfall den passenden Schutz zu wählen und ihn über den gesamten Lebenszyklus zuverlässig zu betreiben.

Mit Lösungen für Certificate Lifecycle Management (CLM), ACME-basierte Zertifikatsautomatisierung sowie Public-Key-Infrastrukturen (PKI) und Managed PKI (MPKI) helfen wir Unternehmen, den Grundstein für kontrollierte, skalierbare und zunehmend automatisierte Zertifikatsprozesse zu legen. So lassen sich Zertifikate und digitale Identitäten zentral verwalten, Laufzeiten zuverlässiger überwachen und Erneuerungen sicher in bestehende IT-Umgebungen integrieren.