Voraussetzung

Prinzip

Generieren eines Schlüsselpaares einen privkey-s und einen pubkey-s.
Den Pubkey-s schickt man nun an einen Zertifizierungsstelle (inkclusive FQDN durch X.509).
Diese bildet nun einen Hashwert hash-s
hash wird nun mit dem privkey-ca verschlüsselt,
Das Teil nennt man nun signature-s
diese wird an den pubkey-s angehängt
Man nennt dies nun certifkat-s und
Es wird zum Server zurück geschickt
Man baut dies dann in seinen Websever ein
CA erstellen
Certificate Request erstellen
CA signiert den Request
Einbauen von Zertifikaten
Anzeigen und überprüfen von Zertifikaten

Zuerst verschlüsselt der Client einen Zufallswert mit dem öffentlichen Schlüssel des Servers.
Dies schickt er zum Server, dieser entschlüsselt dies, mit seinem privaten Schlüssel und schickt diesen zurück.
Wenn beide Werte gleich sind, ist der Client sicher, das der Server den Privat Key hat.
Client greift auf den Server über den Domain Name zu.
Server schickt nun das certifikat-s zum Client
Client teilt nun dieses wieder auf in pubkey-s und signature-s
Bildet einen hash aus dem pubkey-s genau wie vorher in der Zertifizierungsstelle.
signature-s wieder mit dem pubkey-ca verschlüsseln haben wir wieder den orginal hash-s
wenn beide gleich sind, ist die Authentifizierung erfolgreich ...

Die Kommunikation beginnt mit der asynchronen Authentifizierung, bei der der Server ein digitales Zertifikat an den Client schickt um sich selbst zu authentifizieren.

Nach der Authentifizierung erfolgt der Diffie-Hellman-Schlüsselaustausch, bei dem Client und Server einen gemeinsamen geheimen Sitzungsschlüssel vereinbaren.

Der vereinbarte geheime Sitzungsschlüssel wird dann verwendet, um die tatsächlichen Daten synchron mit einem symmetrischen Verschlüsselungsalgorithmus zu verschlüsseln.

Um die Integrität der übertragenen Daten zu gewährleisten, wird ein kryptografischer Hash-Wert verwendet. Der Empfänger kann diesen Hash-Wert überprüfen, um sicherzustellen, dass die Daten während der Übertragung nicht manipuliert wurden.