Wenn Ihr Gerät eine verschlüsselte Verbindung über SSL bzw. TLS zu einem Server der Hochschule herstellt, überprüft es, ob die Verbindung wirklich zum korrekten (authentischen) Server hergestellt wurde. Sie wollen schließlich nicht Ihre Zugangsdaten zu HSM-Diensten an irgendjemanden aushändigen, der sich lediglich als HSM ausgibt. Auch möchten Sie sicherlich nicht, dass Ihre Daten bei der Übertragung zwischen Ihrem Gerät und dem Server mitgelesen oder manipuliert werden.
Als Beispiel weist ein Server seine Authentizität über sein Zertifikat (Serverzertifikat) nach. Dieses enthält den öffentlichen Schlüssel (public key) des Dienstes und ist von einer vertrauenswürdigen Stammzertifizierungsstelle (certification authority, CA) unterschrieben (signiert / verifiziert). Über Ihr Betriebssystem sind bereits einige, geläufige CAs vorkonfiguriert, die eine reibungslose Verwendung sowie Updates ermöglichen. Nach der Validierung des Zertifikats wird es genutzt, um die Vertraulichkeit der übertragenen Daten über Verschlüsselung sowie deren Integrität über Prüfsummen sicherzustellen.
Dieses Prinzip kann auch auf E-Mails und Dokumente mit Client-Zertifikaten sowie auf Software bzw. Quellcode mit Code-Signing-Zertifikaten erweitert werden. Das digitale Signieren von E-Mails, Dokumenten und Software sowie die Verschlüsselung von E-Mails wird somit ermöglicht.
HTTPS
(1) erfolgt und, dass die Second-Level-Domain exakt hs-schmalkalden.de
und nicht etwa hs-schmalka1den.de
(Das zwei L ist eine Eins) lautet! Domains mit Schreibfehlern zu registrieren und mit Zertifikaten zu versehen, ist ein beliebtes Mittel, um falsches Vertrauen zu erzeugen und infolgedessen Zugangsdaten abzugreifen! Zusätzlich können Sie daher über das Schloss-Symbol
(3) in Ihrem Webbrowser die Zertifizierungsstelle (4) überprüfen. Seriöse Websites der Hochschule sind immer von GEANT Vereniging
oder Sectigo Limited
und nicht etwa von Let's Encrypt
o.Ä. verifiziert. Fügen Sie bitte im Zweifelsfall keine Sicherheitsausnahme in Ihrem Webbrowser hinzu, sondern kontaktieren Sie das Rechenzentrum unter pki@hs-schmalkalden.de!
Damit die Signatur einer CA unter dem Public Key überprüft werden kann, muss der öffentliche Schlüssel der CA auf Ihrem Gerät als vertrauenswürdige Stammzertifizierungsstelle (trusted CA) konfiguriert sein. Da sich die vorkonfigurierten CAs zwischen Betriebssystemen bzw. einzelnen Betriebssystemversionen unterscheiden können, sind manchmal Anpassungen erforderlich.
Auf technischer Ebene basieren Zertifikate auf asymmetrischer Kryptografie. D.h. sie bestehen u.A. aus einem s.g. Schlüsselpaar, welches sich aus einem öffentlichen und einem privaten Schlüssel zusammensetzt. Der öffentliche Schlüssel ist - wie sein Name bereits vermuten lässt - öffentlich für jeden zugänglich und dient der Verschlüsselung von Daten. Die damit verschlüsselten Daten können ausschließlich mit dem passenden privaten Schlüssel entschlüsselt werden. Zwei Parteien, die verschlüsselt kommunizieren wollen, können sich dies folglich gegenseitig ermöglichen, indem sie beide ihre öffentlichen Schlüssel untereinander austauschen. Der damit verschlüsselte Datenverkehr kann ausschließlich vom richtigen Empfänger entschlüsselt werden, da nur dieser den jeweils passenden privaten Schlüssel besitzt. Dies setzt natürlich vorraus, dass beide Kommunikationspartner dem öffentlichen Schlüssel des jeweils anderen vertrauen. Dies wird im Fall von Zertifikaten über die Signierung durch die CAs sichergestellt.
Im Falle der Client-Server-Kommunikation mit Transportverschlüsselung (TLS) funktioniert dies ein wenig abgewandelt. Da Ihr Browser kein Zertifikat besitzt, wird beim Aufruf einer Website über HTTPS lediglich der öffentliche Schlüssel des Serverzertifikats genutzt, um einen symmetrischen Schlüssel mit dem Server auszuhandeln, der anschließend den Verkehr verschlüsselt. Ein symmetrischer Schlüssel ist im Gegensatz zu einem asymmetrischen beiden Kommunikationspartnern bekannt. Hier finden Sie weitere Informationen dazu.