Zertifikate und SSH quantensicher machen: Ein Fahrplan für die IT
Bei SSH ist der Schlüsselaustausch längst quantensicher, bei Zertifikaten beginnt die Umstellung erst. Was IT-Abteilungen jetzt konkret tun können.
- Aktuelle SSH-Versionen handeln den Schlüsselaustausch seit Jahren standardmäßig hybrid und quantensicher aus; Altgeräte sind die Lücke.
- Für Zertifikate mit Post-Quanten-Signaturen gibt es seit Oktober 2025 einen IETF-Standard; im öffentlichen Web dauert die Umstellung noch.
- Der wichtigste Schritt ist ein Inventar aller Schlüssel und Zertifikate, mit Laufzeiten und Verantwortlichen.
Wer sich in den vergangenen Monaten mit einem aktuellen SSH-Client an einem älteren Server angemeldet hat, hat sie vielleicht gesehen: eine Warnung, dass die Verbindung keinen Post-Quanten-Schlüsselaustausch nutzt. Sie ist ein guter Anlass, sich zwei Grundpfeiler der IT anzusehen, die beide auf Kryptografie beruhen, die heute als angreifbar durch künftige Quantencomputer gilt. Wer Zertifikate und SSH quantensicher machen will, steht dabei an zwei sehr unterschiedlichen Punkten.
SSH: Der Schlüsselaustausch ist schon weit
Die am weitesten verbreitete freie SSH-Implementierung nutzt bereits seit Version 9.0 aus dem Jahr 2022 standardmäßig einen hybriden Schlüsselaustausch, also ein klassisches und ein Post-Quanten-Verfahren zusammen. Seit Version 10.0 (April 2025) ist die Standardeinstellung ein hybrides Verfahren mit dem von NIST standardisierten Post-Quanten-Teil. Seit Version 10.1 (Oktober 2025) warnt der Client, wenn eine Verbindung ohne Post-Quanten-Schlüsselaustausch zustande kommt (Hinweise des Projekts).
Für die meisten Unternehmen heißt das: Wer Server und Clients aktuell hält, hat den wichtigsten Teil schon erledigt. Die Lücken liegen woanders:
- Netzwerkgeräte und Appliances mit eingebauten, oft alten SSH-Servern: Switches, Firewalls, Speichersysteme, Steuerungen in der Produktion.
- Eingebettete Clients in Automatisierungswerkzeugen, Dateiübertragungsprogrammen und Skripten mit fest eingestellten Verfahren.
- Server mit veralteten Betriebssystemen, die keine aktuellen Pakete mehr erhalten.
Anders sieht es bei den Schlüsseln für Anmeldung und Serverprüfung aus. Sie sind weiterhin klassisch; Post-Quanten-Signaturen für SSH werden noch standardisiert. Das ist vertretbar, weil eine Anmeldung nicht rückwirkend gefälscht werden kann. Die Schlüssel müssen aber umgestellt sein, bevor leistungsfähige Quantencomputer verfügbar sind. Warum Signaturen anders zu bewerten sind als Verschlüsselung, erklärt unser Beitrag zu Post-Quanten-Signaturen und Standards.
Zertifikate: Der Standard ist da, das Ökosystem noch nicht
Zertifikate bestätigen, dass ein Server, eine Person oder eine Software echt ist. Die Signaturen darin beruhen heute fast ausnahmslos auf klassischen Verfahren. Seit Oktober 2025 gibt es mit RFC 9881 einen IETF-Standard, der festlegt, wie Post-Quanten-Signaturen nach FIPS 204 in X.509-Zertifikaten und Sperrlisten verwendet werden (RFC 9881).
Das macht den Weg frei für private Zertifizierungsstellen: interne Dienste, Geräteidentitäten, VPN, Signatur von Software. Hier haben Sie Aussteller und Prüfer selbst in der Hand und können früh testen.
Im öffentlichen Web dauert es länger. Post-Quanten-Signaturen sind deutlich größer als heutige; bei Zertifikatsketten mit mehreren Signaturen und Transparenznachweisen würde jeder Verbindungsaufbau spürbar schwerer. Browserhersteller und die IETF arbeiten deshalb an einem kompakteren Zertifikatsformat, das erst in den kommenden Jahren breit verfügbar sein soll. Für Betreiber von Webseiten heißt das: Die hybride Schlüsselvereinbarung in TLS ist bereits Standard (siehe Quantensicheres TLS), bei öffentlichen Zertifikaten heißt es vorbereiten, nicht vorpreschen.
Merksatz: Bei SSH ist die Hauptaufgabe Aufräumen, bei Zertifikaten Vorbereiten. In beiden Fällen beginnt alles mit einem Inventar.
Zertifikate und SSH quantensicher: der Fahrplan
- Inventar anlegen: alle SSH-Server und -Clients mit Version, alle Zertifikate mit Aussteller, Verfahren, Laufzeit und verantwortlicher Person. Eine solche Übersicht über eingesetzte Kryptografie verlangen Prüfer zunehmend.
- SSH aktualisieren: Server und Clients auf aktuelle Versionen bringen; Geräte ohne Post-Quanten-Schlüsselaustausch auflisten, mit Herstellern sprechen oder Ersatz planen.
- Kurze Laufzeiten und Automatisierung: Wer Zertifikate automatisch erneuert, kann später auch das Verfahren automatisch wechseln. Handgepflegte Zertifikate mit mehrjähriger Laufzeit sind das größte Hindernis.
- Private PKI testen: eine Test-Zertifizierungsstelle mit Post-Quanten-Signaturen nach RFC 9881 aufsetzen und prüfen, welche Systeme die Zertifikate verarbeiten.
- Hardware einbeziehen: Hardware-Sicherheitsmodule, Chipkarten und Token haben lange Beschaffungszyklen. Unterstützung für die neuen Verfahren jetzt in Ausschreibungen aufnehmen.
- Fristen kennen: Das BSI sieht klassische asymmetrische Verfahren allein nur noch bis Ende 2031 vor, für besonders schutzbedürftige Anwendungen bis Ende 2030 (BSI TR-02102). Den europäischen Zeitplan fasst unser Beitrag zum EU-Fahrplan zusammen.
Daten schützen, während die Infrastruktur umzieht
Die Umstellung von SSH-Schlüsseln und Zertifikaten zieht sich über Jahre. In dieser Zeit liegen vertrauliche Dokumente weiter auf Servern, in Postfächern und Backups. Sie lassen sich unabhängig von der Infrastruktur schützen, indem sie vor dem Speichern oder Versenden Ende-zu-Ende verschlüsselt werden.
PQVault in der Übergangszeit
PQVault Files verschlüsselt Dateien direkt auf dem Rechner, mit NIST-standardisierten Post-Quanten-Verfahren in hybrider Form, und lässt Sie den Zugriff später zurückholen. Für eigene Anwendungen und interne Dienste bietet das PQVault SDK dieselben Bausteine, krypto-agil aufgebaut. Mehr Szenarien für Betreiber finden Sie unter Digitale Infrastruktur & Rechenzentren.
PQVault ist ein Produkt der QuantiCor Security GmbH aus Darmstadt — Spezialist für Post-Quanten-Kryptografie.PQVault is a product of QuantiCor Security GmbH, Darmstadt — specialists in post-quantum cryptography. Mehr über QuantiCor SecurityMore about QuantiCor Security

