Öffentlicher Schlüssel (Public-Key)

Öffentlicher Schlüssel (Public-Key)

Der öffentliche Schlüssel (englisch Public Key) ist der frei verteilbare Teil eines asymmetrischen Schlüsselpaars. Bei SSL/TLS steht er im Zertifikat und belegt im SSL/TLS-Handshake, dass der Server den zugehörigen privaten Schlüssel besitzt. Je nach Verfahren dient er zum Prüfen von Signaturen (RSA, ECDSA) oder zum Verschlüsseln, etwa bei E-Mail-Zertifikaten (S/MIME).

Wie hängen öffentlicher und privater Schlüssel zusammen?

Beide Schlüssel entstehen gemeinsam und sind mathematisch verbunden. Was der öffentliche Schlüssel verschlüsselt, entschlüsselt nur der private; was der private signiert, prüft der öffentliche. Die gängigen Verfahren sind RSA (seit 1977) und ECDSA auf elliptischen Kurven; ECDSA selbst kann nur signieren, nicht verschlüsseln.

Aus dem öffentlichen Schlüssel lässt sich der private nicht berechnen: Bei RSA mit 2048 Bit müsste man dafür eine 617-stellige Zahl in ihre Primfaktoren zerlegen, das schafft kein heutiger Computer.

In einem Zertifikat nach dem Standard X.509 steht der öffentliche Schlüssel im Feld SubjectPublicKeyInfo (RFC 5280). Die Zertifizierungsstelle (CA) signiert mit ihrem eigenen privaten Schlüssel das ganze Zertifikat, also Ihren öffentlichen Schlüssel, die Domain, die Laufzeit und die Erweiterungen. So bindet sie Ihren öffentlichen Schlüssel an die geprüfte Domain.

Wie entsteht der öffentliche Schlüssel eines SSL-Zertifikats?

Das Schlüsselpaar erzeugen Sie selbst auf dem Server, zum Beispiel mit OpenSSL, oder Ihr Hosting-Anbieter übernimmt das. Der Ablauf hat drei Schritte:

1. Der Server erzeugt privaten und öffentlichen Schlüssel.


2. Der öffentliche Schlüssel wandert zusammen mit Domain und Firmendaten in den CSR (Certificate Signing Request, den Zertifikatsantrag), der mit dem privaten Schlüssel signiert wird.


3. Die Zertifizierungsstelle prüft die Domain, signiert mit ihrem eigenen privaten Schlüssel das Zertifikat, das Ihren öffentlichen Schlüssel und die geprüften Angaben enthält, und liefert es zurück.

Der private Schlüssel verlässt den Server dabei nie. Erzeugen Sie bei jeder Erneuerung ein neues Schlüsselpaar; ein unbemerkt kopierter alter Schlüssel passt dann nicht zum neuen Zertifikat. Ein typischer OpenSSL-Befehl für Schlüssel und CSR:

openssl req -new -newkey rsa:2048 -nodes -keyout ihre-domain.key -out ihre-domain.csr

Nicht jedes Schlüsselpaar liegt auf einem Webserver: Bei E-Mail-Zertifikaten (S/MIME) entsteht es meist im Browser, im Mailprogramm oder bei der Zertifizierungsstelle, und der private Schlüssel kommt auf jedes Gerät, das verschlüsselte E-Mails lesen soll. Bei Code-Signing-Zertifikaten muss der private Schlüssel seit Juni 2023 auf einem Hardware-Token oder in einem Hardware-Sicherheitsmodul (HSM, auch als Cloud-Dienst) liegen, nicht als Datei auf einem Server.

Welche Rolle spielt der öffentliche Schlüssel im SSL/TLS-Handshake?

In TLS 1.3 dient der öffentliche Schlüssel nur noch der Identitätsprüfung, nicht dem Schlüsselaustausch. Der Browser prüft mit ihm die Signatur, die der Server über die bisherigen Handshake-Nachrichten bildet (Nachricht CertificateVerify). Stimmt sie, hat der Server bewiesen, dass er den privaten Schlüssel besitzt.

Den Sitzungsschlüssel für die Datenverschlüsselung (meist mit AES) vereinbaren Browser und Server per ECDHE, einem Diffie-Hellman-Verfahren über elliptische Kurven. Sofern der Server es unterstützt, kombinieren Chrome, Edge, Firefox und Safari das Verfahren seit 2024/2025 standardmäßig mit ML-KEM, einem Post-Quanten-Verfahren, das auch Quantencomputern standhalten soll (Stand Oktober 2026).

Der Vorteil heißt Forward Secrecy: Wird der private Schlüssel später gestohlen, bleiben aufgezeichnete Verbindungen unlesbar. Den älteren RSA-Schlüsseltransport, bei dem der Browser den Sitzungsschlüssel mit dem öffentlichen Schlüssel des Servers verschlüsselte, hat RFC 8446 gestrichen; in TLS 1.2 ist er noch möglich, aber nicht mehr empfohlen.

Welche Schlüsseltypen und -längen sind erlaubt?

Die Baseline Requirements, das Regelwerk des CA/Browser-Forums aus Browserherstellern und Zertifizierungsstellen (Version 2.3.1, Stand Oktober 2026), lassen nur RSA ab 2048 Bit und ECDSA auf den Kurven P-256, P-384 und P-521 zu. Die Tabelle zeigt für jeden Typ das Sicherheitsniveau: Es gibt an, wie viel Aufwand ein Angriff kostet, ausgedrückt als Länge eines gleich starken symmetrischen Schlüssels wie bei AES (NIST SP 800-57, Empfehlung des US-Normungsinstituts NIST).

Schlüsseltyp	Länge	Sicherheitsniveau	Einordnung
RSA	2048 Bit	112 Bit	verbreiteter Standard
RSA	3072 Bit	128 Bit	vom BSI empfohlen
RSA	4096 Bit	über 128 Bit	langsamerer Handshake
ECDSA	P-256	128 Bit	schneller Handshake, alle aktuellen Browser
ECDSA	P-384	192 Bit	höhere Sicherheit, alle aktuellen Browser
ECDSA	P-521	256 Bit	erlaubt, aber von Chrome und Edge nicht unterstützt

Ein ECDSA-Schlüssel auf P-256 ist mit 256 Bit achtmal kürzer als RSA 2048 und bietet trotzdem mehr Sicherheit.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt für RSA mindestens 3000 Bit (TR-02102-1). Mittelfristig lösen Post-Quanten-Verfahren RSA und ECDSA ab; mehr zur Einordnung der Schlüssellängen unter Verschlüsselungstiefe.

Fazit

Der öffentliche Schlüssel ist der sichtbare Teil Ihres Zertifikats: Er darf überall hin, der private Schlüssel nirgendwohin. Für die Bestellung erzeugen Sie oder Ihr Hosting-Anbieter das Schlüsselpaar, bei jeder Erneuerung neu, und reichen nur den CSR ein; RSA 2048 Bit ist der verbreitete Standard, ECDSA P-256 die schnellere Alternative mit mehr Sicherheit.

Glossar-Einträge mit "O"

• Öffentlicher Schlüssel (Public-Key)
• Organization-Validation (OV)

Weitere Glossar-Einträge »