PKI-Anwendungsfälle: HTTPS, S/MIME und Codesignierung

Public Key Infrastructure (PKI) ist das unsichtbare Rückgrat sicherer digitaler Kommunikation. Die Zertifikate und CAs, mit denen Sie sich beschäftigt haben, werden täglich in Dutzenden realer Szenarien eingesetzt. Die Security+-Prüfung testet Ihre Fähigkeit, PKI-Anwendungsfälle zu erkennen, den passenden Zertifikatstyp für den jeweiligen Fall zu verstehen und den Schutz zu bestimmen, den PKI in diesem Kontext bietet. Die drei wichtigsten Anwendungsfälle in der Prüfung sind HTTPS/TLS (Websicherheit), S/MIME (E-Mail-Sicherheit) und Code Signing (Softwareintegrität).

HTTPS (HTTP über TLS) ist der sichtbarste PKI-Anwendungsfall. Wenn Sie eine Verbindung zu https://bank.com herstellen, führt Ihr Browser folgende Schritte aus: (1) Er empfängt das TLS-Zertifikat des Servers, (2) überprüft, dass die Zertifikatskette zu einer vertrauenswürdigen Root-CA führt, (3) vergleicht den Hostnamen mit den SAN-Feldern, (4) prüft, dass das Zertifikat nicht widerrufen wurde, und (5) verwendet den öffentlichen Schlüssel für einen Diffie-Hellman-Schlüsselaustausch, um eine verschlüsselte Sitzung einzurichten. Das Vorhängeschloss-Symbol im Browser zeigt an, dass alle diese Prüfungen erfolgreich waren. Ein fehlendes oder ungültiges Zertifikat führt zu einer Browserwarnung, die die meisten Benutzer davon abhält, fortzufahren.

S/MIME (Secure/Multipurpose Internet Mail Extensions) verwendet PKI-Zertifikate, um zwei Sicherheitsdienste für E-Mails bereitzustellen. Verschlüsselung: Der Absender verschlüsselt den E-Mail-Inhalt mit dem öffentlichen Schlüssel des Empfängers, sodass nur der Empfänger ihn entschlüsseln kann. Dadurch bleibt die Vertraulichkeit auch dann geschützt, wenn die E-Mail während der Übertragung abgefangen oder auf einem kompromittierten Server gespeichert wird. Digitale Signaturen: Der Absender signiert mit seinem privaten Schlüssel. Dadurch kann der Empfänger überprüfen, dass die E-Mail tatsächlich vom Absender stammt und nicht verändert wurde – dies schützt die Integrität und gewährleistet die Nichtabstreitbarkeit. Für S/MIME benötigt jeder Benutzer ein eigenes, von einer CA ausgestelltes Zertifikat.

Code Signing verwendet PKI, um Software – ausführbare Dateien, Skripte, Treiber und Installationsprogramme – digital zu signieren. So können Benutzer überprüfen, dass die Software von einem vertrauenswürdigen Herausgeber stammt und nicht manipuliert wurde. Der Softwareanbieter signiert seinen Code mit einem privaten Schlüssel aus einem von einer vertrauenswürdigen CA ausgestellten Code-Signing-Zertifikat. Wenn ein Benutzer die Software ausführt, überprüft das Betriebssystem die Signatur mithilfe des öffentlichen Schlüssels des Anbieters aus der Zertifikatskette. Windows SmartScreen, macOS Gatekeeper sowie die App-Stores von iOS und Android stützen sich auf Code Signing, um die Herkunft von Software festzustellen. Nicht signierte Software wird möglicherweise blockiert oder löst Sicherheitswarnungen aus.

Die Authentifizierung mit Clientzertifikaten, auch als Mutual TLS oder mTLS bezeichnet, erweitert das standardmäßige TLS-Modell, indem auch der Client ein Zertifikat vorlegen muss. Bei standardmäßigem TLS wird nur der Server per Zertifikat authentifiziert; bei mTLS authentifizieren sich beide Parteien gegenseitig. Dieses Verfahren wird eingesetzt für: VPN-Authentifizierung (Smartcards oder Clientzertifikate anstelle von Passwörtern), API-Authentifizierung (Authentifizierung zwischen Maschinen, bei der der Client ein Dienst und kein Mensch ist) und privilegierten Administratorzugriff (Administratoren müssen Hardware-Token mit eingebetteten Zertifikaten verwenden).

SSH verwendet Public-Key-Kryptografie für zwei Zwecke: Serverauthentifizierung und Clientauthentifizierung. Serverauthentifizierung: Wenn Sie erstmals eine Verbindung zu einem SSH-Server herstellen, präsentiert dieser seinen Hostschlüssel (öffentlichen Schlüssel). Ihr SSH-Client speichert ihn in ~/.ssh/known_hosts. Bei späteren Verbindungen warnt SSH Sie, wenn sich der Hostschlüssel geändert hat, da dies auf einen MITM-Angriff oder eine erneute Einrichtung des Servers hindeuten kann. Clientauthentifizierung: Anstelle von Passwörtern verwenden Administratoren Schlüsselpaare – der öffentliche Schlüssel wird in authorized_keys auf dem Server hinterlegt, und der private Schlüssel, der niemals übertragen wird, weist die Identität nach. SSH-Hostschlüssel unterscheiden sich von PKI-Zertifikaten, erfüllen jedoch dieselbe Vertrauensfunktion.

PKI ermöglicht in vielen Rechtsordnungen rechtsverbindliche digitale Dokumentensignaturen. Signaturen für Adobe-PDFs, DocuSign und staatliche Systeme für elektronische Signaturen verwenden sämtlich PKI-Zertifikate zum Signieren von Dokumenten. Eine wichtige Ergänzung zur Dokumentensignatur ist das Setzen von Zeitstempeln: Eine Trusted Timestamp Authority (TSA) signiert den Hash des Dokuments mit einem vertrauenswürdigen Zeitstempel und weist damit nach, dass das Dokument zu einem bestimmten Zeitpunkt existiert hat. Zeitstempel sind auch für Code Signing unverzichtbar: Ohne Zeitstempel werden Codesignaturen ungültig, sobald das Signaturzertifikat abläuft – selbst bei Software, die bereits vor dem Ablaufdatum verteilt wurde.

Mit der zunehmenden Verbreitung von IoT-Geräten bietet PKI eine Möglichkeit, Geräte in großem Maßstab zu authentifizieren. Jedes Gerät wird während der Herstellung mit einem eindeutigen Zertifikat ausgestattet (ein Prozess, der als Bereitstellung der Geräteidentität bezeichnet wird). Dadurch können Server einzelne Geräte anhand ihrer Zertifikate authentifizieren. Dies ermöglicht beispielsweise, dass ein intelligenter Zähler seine Identität gegenüber dem Server des Versorgungsunternehmens nachweist, ein medizinisches Gerät sich gegenüber einem Krankenhausnetzwerk authentifiziert oder eine Fahrzeugflotte sich gegenüber dem Backend des Herstellers authentifiziert. IoT-PKI muss Millionen von Geräten mit begrenzten Ressourcen verwalten. Dies fördert den Einsatz von ECC-Zertifikaten, da diese klein sind und schnell verifiziert werden können.

Zertifikatbasierte VPN-Authentifizierung ist deutlich sicherer als eine passwortbasierte VPN-Authentifizierung. Jeder VPN-Benutzer bzw. jedes VPN-Gerät erhält ein Clientzertifikat von der internen CA der Organisation. Beim Verbindungsaufbau überprüft das VPN-Gateway das Clientzertifikat und stellt dabei sicher, dass es von der vertrauenswürdigen internen CA ausgestellt wurde, noch gültig ist und nicht über CRL/OCSP widerrufen wurde. Wenn ein Mitarbeiter das Unternehmen verlässt, verhindert der Widerruf seines Zertifikats sofort den VPN-Zugriff – zuverlässiger, als darauf zu hoffen, dass er sein Passwort nicht an andere weitergegeben hat.

Sicherheitsexperten müssen häufige Zertifikatsfehler diagnostizieren können. Zertifikat abgelaufen: Das notAfter-Datum ist überschritten – erneuern Sie das Zertifikat. Hostname stimmt nicht überein: Der SAN des Zertifikats stimmt nicht mit dem angeforderten Hostnamen überein – überprüfen Sie CNs und SANs; möglicherweise benötigen Sie ein Wildcard- oder Multi-SAN-Zertifikat. Selbstsigniertes Zertifikat: Keine CA bürgt für dieses Zertifikat – fügen Sie es dem lokalen Truststore hinzu oder ersetzen Sie es durch ein von einer CA signiertes Zertifikat. Unvollständige Zertifikatskette: Das Zwischenzertifikat der CA wird vom Server nicht bereitgestellt – konfigurieren Sie den Server so, dass er die vollständige Kette sendet. Zertifikat widerrufen: CRL oder OCSP weist den Widerruf aus – eine sofortige Reaktion auf eine Schlüsselkompromittierung ist erforderlich.

Zwei Zertifikatstypen können mehrere Hostnamen abdecken. Ein Wildcard-Zertifikat gilt für alle Subdomains der ersten Ebene einer Domain: *.example.com deckt www.example.com, mail.example.com und api.example.com ab, jedoch NICHT sub.api.example.com (zwei Ebenen). Ein Zertifikat und ein privater Schlüssel für alle Dienste sind praktisch, aber riskant, wenn der Schlüssel kompromittiert wird, da dann alle Dienste betroffen sind. Ein Multi-SAN-Zertifikat führt mehrere konkrete Domains ausdrücklich in der SAN-Erweiterung auf, beispielsweise example.com, www.example.com und api.example.com. Diese Lösung ist granularer, erfordert aber eine Aktualisierung des Zertifikats, wenn neue Domains hinzukommen.

Testen Sie Ihr Verständnis der Konzepte aus CompTIA Security+ (SY0-701) in dieser Lektion.

In dieser Lektion haben Sie gelernt: HTTPS/TLS verwendet Serverzertifikate, um Webdatenverkehr zu verschlüsseln und Server zu authentifizieren; S/MIME-Zertifikate ermöglichen das Signieren und Verschlüsseln von E-Mails; Code-Signing-Zertifikate weisen die Integrität der Software und die Identität des Herausgebers nach; und Clientzertifikate ermöglichen die gegenseitige Authentifizierung für VPNs und APIs. Als Nächstes sehen wir uns Passwortrichtlinien und Multi-Faktor-Authentifizierung an.