Hypertext Transfer Protocol Secure - Versionsgeschichte

BookPen: /* growthexperiments-addlink-summary-summary:2|0|0 */

2025-04-13T15:02:55Z

Linkvorschlag-Funktion: 2 Links hinzugefügt.

← Nächstältere Version		Version vom 13. April 2025, 17:02 Uhr
Zeile 59:		Zeile 59:
	Je nach Browser und [[Betriebssystem]] liefern die Browser-Hersteller entweder eine Liste von vertrauenswürdigen Stammzertifikaten mit oder greifen auf den Zertifikatsspeicher des Betriebssystems zurück. Ob ein Wurzelzertifikat dem Browser bekannt ist, hängt somit von der Version des Browsers und des Betriebssystems ab. Die Liste der vertrauenswürdigen Wurzelzertifikate wird durch den Hersteller mit [[Softwareaktualisierung]]en auf den neuesten Stand gebracht.		Je nach Browser und [[Betriebssystem]] liefern die Browser-Hersteller entweder eine Liste von vertrauenswürdigen Stammzertifikaten mit oder greifen auf den Zertifikatsspeicher des Betriebssystems zurück. Ob ein Wurzelzertifikat dem Browser bekannt ist, hängt somit von der Version des Browsers und des Betriebssystems ab. Die Liste der vertrauenswürdigen Wurzelzertifikate wird durch den Hersteller mit [[Softwareaktualisierung]]en auf den neuesten Stand gebracht.

	Welche Wurzelzertifikate die Hersteller in ihre Zertifikatsspeicher aufnehmen, ergibt sich aus den Regelungen des [[CA/Browser Forum]]s. Die Zertifizierungsstelle muss hierbei durch einen externen [[Audit]] nachweisen, mit den Sicherheitsvorgaben konform zu sein. Da dies mit Kosten verbunden ist, stellt es eine Aufnahmehürde dar. Das in der [[Open Source\|Open-Source-Community]] verbreitete [[CAcert]], ein früher Anbieter kostenloser Zertifikate, ist eine prominente Zertifizierungsstelle, das nicht in den Browsern mitgeliefert wird. Anwender, die eine Seite mit CAcert-Zertifikat besuchen, müssen das Wurzelzertifikat händisch installieren.		Welche Wurzelzertifikate die Hersteller in ihre Zertifikatsspeicher aufnehmen, ergibt sich aus den Regelungen des [[CA/Browser Forum]]s. Die [[Zertifizierungsstelle]] muss hierbei durch einen externen [[Audit]] nachweisen, mit den Sicherheitsvorgaben konform zu sein. Da dies mit Kosten verbunden ist, stellt es eine Aufnahmehürde dar. Das in der [[Open Source\|Open-Source-Community]] verbreitete [[CAcert]], ein früher Anbieter kostenloser Zertifikate, ist eine prominente Zertifizierungsstelle, das nicht in den Browsern mitgeliefert wird. Anwender, die eine Seite mit CAcert-Zertifikat besuchen, müssen das Wurzelzertifikat händisch installieren.

	Um die Verbreitung von HTTPS zu fördern, ging Ende 2015 die gemeinnützige Zertifizierungsstelle [[Let’s Encrypt]] in Betrieb. Let’s Encrypt stellt für jeden kostenlose Zertifikate aus, die von den gängigen Browsern als vertrauenswürdig akzeptiert werden. Für die Installation und laufende Aktualisierung der Zertifikate ist eine Software auf dem Server notwendig.		Um die Verbreitung von HTTPS zu fördern, ging Ende 2015 die gemeinnützige Zertifizierungsstelle [[Let’s Encrypt]] in Betrieb. Let’s Encrypt stellt für jeden kostenlose Zertifikate aus, die von den gängigen Browsern als vertrauenswürdig akzeptiert werden. Für die Installation und laufende Aktualisierung der Zertifikate ist eine Software auf dem Server notwendig.
Zeile 114:		Zeile 114:
	* Gesamte Infrastruktur ist auf SSL umzustellen, darunter [[Loadbalancer]] und Proxies		* Gesamte Infrastruktur ist auf SSL umzustellen, darunter [[Loadbalancer]] und Proxies
	* Organisation der Zertifikate, ggf. für eine Vielzahl von Subdomains		* Organisation der Zertifikate, ggf. für eine Vielzahl von Subdomains
	* Umstellung von Code der eigenen Webanwendung, worin HTTP hart codiert ist		* Umstellung von Code der eigenen [[Webanwendung]], worin HTTP hart codiert ist
	* Umstellung von altem und Prüfung von neuem User-Code, der ggf. HTTP verwendet		* Umstellung von altem und Prüfung von neuem User-Code, der ggf. HTTP verwendet
	* Qualitätsprüfung		* Qualitätsprüfung

Windharp: Abschnittlink korrigiert

2025-02-04T09:15:24Z

Abschnittlink korrigiert

← Nächstältere Version		Version vom 4. Februar 2025, 11:15 Uhr
Zeile 69:		Zeile 69:
	Das [[Digitales Zertifikat\|digitale Zertifikat]] für [[Secure Sockets Layer\|SSL]], das die Authentifizierung ermöglicht, ist vom Server bereitzustellen: Ein Binärdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – [[Zertifizierungsstelle (Digitale Zertifikate)\|Zertifizierungsstelle]] (CA von {{enS\|certificate authority}}) ausgestellt wird, das den Server und die [[Domain (Internet)\|Domain]] eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und der Firmenname des Antragstellers geprüft.		Das [[Digitales Zertifikat\|digitale Zertifikat]] für [[Secure Sockets Layer\|SSL]], das die Authentifizierung ermöglicht, ist vom Server bereitzustellen: Ein Binärdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – [[Zertifizierungsstelle (Digitale Zertifikate)\|Zertifizierungsstelle]] (CA von {{enS\|certificate authority}}) ausgestellt wird, das den Server und die [[Domain (Internet)\|Domain]] eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und der Firmenname des Antragstellers geprüft.

	In gängigen Browsern eingetragene Zertifikate werden typischerweise zu Preisen zwischen 15 und 600 € pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind. Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus. Die etwa von <!--[[StartCom]]<ref>{{Internetquelle \|url=https://www.heise.de/security/meldung/Mozilla-vertraut-kostenlosen-StartCom-Zertifikaten-129472.html \|titel=Mozilla vertraut kostenlosen StartCom Zertifikaten \|hrsg=Heise-Online \|datum=2006-06-03 \|zugriff=2010-03-04}}<br />Vgl. dazu auch ''[[:en:Comparison of SSL certificates for web servers\|Comparison of SSL certificates for web servers]]'' in der englischsprachigen Wikipedia.</ref> oder--> [[Let’s Encrypt]] ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert. Ebenfalls kostenlose Zertifikate erstellt [[CAcert]], wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe [[#~~Vorinstallierte Zertifikate~~\|oben]]. Ein solches Zertifikat muss daher bei der [[#Client-Verarbeitung\|Client-Verarbeitung]] vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein.		In gängigen Browsern eingetragene Zertifikate werden typischerweise zu Preisen zwischen 15 und 600 € pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind. Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus. Die etwa von <!--[[StartCom]]<ref>{{Internetquelle \|url=https://www.heise.de/security/meldung/Mozilla-vertraut-kostenlosen-StartCom-Zertifikaten-129472.html \|titel=Mozilla vertraut kostenlosen StartCom Zertifikaten \|hrsg=Heise-Online \|datum=2006-06-03 \|zugriff=2010-03-04}}<br />Vgl. dazu auch ''[[:en:Comparison of SSL certificates for web servers\|Comparison of SSL certificates for web servers]]'' in der englischsprachigen Wikipedia.</ref> oder--> [[Let’s Encrypt]] ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert. Ebenfalls kostenlose Zertifikate erstellt [[CAcert]], wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe [[#Vertrauensanker\|oben]]. Ein solches Zertifikat muss daher bei der [[#Client-Verarbeitung\|Client-Verarbeitung]] vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein.

	Um veraltete oder unsicher gewordene Zertifikate für ungültig zu erklären, sind [[Zertifikatsperrliste]]n ({{enS\|certificate revocation list}}, ''CRL'') vorgesehen. Das Verfahren sieht vor, dass diese Listen regelmäßig von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden.		Um veraltete oder unsicher gewordene Zertifikate für ungültig zu erklären, sind [[Zertifikatsperrliste]]n ({{enS\|certificate revocation list}}, ''CRL'') vorgesehen. Das Verfahren sieht vor, dass diese Listen regelmäßig von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden.

Matthäus Wander: /* Verschlüsselung */ Link

2024-12-28T13:54:18Z

Verschlüsselung: Link

← Nächstältere Version		Version vom 28. Dezember 2024, 15:54 Uhr
Zeile 136:		Zeile 136:
	Da in der Regel Benutzer nicht explizit eine verschlüsselte Verbindung durch Spezifizierung des HTTPS-Protokolls (''<nowiki>https://</nowiki>'') beim Aufruf einer Webseite anfordern, kann ein Angreifer eine Verschlüsselung der Verbindung bereits vor Initialisierung unterbinden und einen [[Man-in-the-Middle-Angriff]] ausführen.<ref>{{Internetquelle \|autor=Daniel Bachfeld \|url=https://www.heise.de/security/meldung/Black-Hat-Neue-Angriffsmethoden-auf-SSL-vorgestellt-198285.html \|titel=Black Hat: Neue Angriffsmethoden auf SSL vorgestellt \|werk=[[Heise online]] Security \|datum=2009-02-19 \|abruf=2015-10-25}}</ref>		Da in der Regel Benutzer nicht explizit eine verschlüsselte Verbindung durch Spezifizierung des HTTPS-Protokolls (''<nowiki>https://</nowiki>'') beim Aufruf einer Webseite anfordern, kann ein Angreifer eine Verschlüsselung der Verbindung bereits vor Initialisierung unterbinden und einen [[Man-in-the-Middle-Angriff]] ausführen.<ref>{{Internetquelle \|autor=Daniel Bachfeld \|url=https://www.heise.de/security/meldung/Black-Hat-Neue-Angriffsmethoden-auf-SSL-vorgestellt-198285.html \|titel=Black Hat: Neue Angriffsmethoden auf SSL vorgestellt \|werk=[[Heise online]] Security \|datum=2009-02-19 \|abruf=2015-10-25}}</ref>

	Speziell zur Abwehr von Downgrade-~~Attacken~~ gegen die Verschlüsselung sowie von [[Session Hijacking]] wurde 2012 das Verfahren [[HTTP Strict Transport Security]] oder HSTS vorgestellt. Es wird durch einen HSTS-Header seitens des Servers aktiviert, worauf im Browser u. a. http- in https-URLs umgewandelt werden.		Speziell zur Abwehr von [[Downgrade-Angriff]]en gegen die Verschlüsselung sowie von [[Session Hijacking]] wurde 2012 das Verfahren [[HTTP Strict Transport Security]] oder HSTS vorgestellt. Es wird durch einen HSTS-Header seitens des Servers aktiviert, worauf im Browser u. a. http- in https-URLs umgewandelt werden.

	=== Zertifikatsystem ===		=== Zertifikatsystem ===

Matthäus Wander: /* Leistung */ Aktualisiert

2024-10-03T16:46:00Z

Leistung: Aktualisiert

← Nächstältere Version		Version vom 3. Oktober 2024, 18:46 Uhr
Zeile 120:		Zeile 120:

	=== Leistung ===		=== Leistung ===
	Beim Verbindungsaufbau handeln Client und Server im [[Transport Layer Security#TLS Handshake Protocol\|TLS-Handshake]] einen Verschlüsselungsalgorithmus aus. Hierbei besteht ein Zielkonflikt zwischen möglichst sicheren und performanten Algorithmen. Dies gilt insbesondere für den Server, da dieser für gewöhnlich mehrere Clients gleichzeitig bedient und somit einen höheren [[Datenverkehr]] als der Client verarbeitet. Früher übliche Verfahren wie die [[Blockverschlüsselung\|Blockchiffre]] [[Data Encryption Standard\|DES]] und die [[Stromverschlüsselung\|Stromchiffre]] [[RC4]] ~~boten~~ eine gute Leistung, gelten heute jedoch nicht mehr als hinreichend sicher. RC4 wird seit 2016 von den großen [[Webbrowser]]n nicht mehr unterstützt.<ref>Emil Protalinski: [https://venturebeat.com/2015/09/01/google-microsoft-and-mozilla-will-drop-rc4-support-in-chrome-edge-ie-and-firefox-next-year/ Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year], VentureBeat, 1. September 2015.</ref>		Beim Verbindungsaufbau handeln Client und Server im [[Transport Layer Security#TLS Handshake Protocol\|TLS-Handshake]] einen Verschlüsselungsalgorithmus aus. Hierbei besteht ein Zielkonflikt zwischen möglichst sicheren und performanten Algorithmen. Dies gilt insbesondere für den Server, da dieser für gewöhnlich mehrere Clients gleichzeitig bedient und somit einen höheren [[Datenverkehr]] als der Client verarbeitet. Früher übliche Verfahren wie die [[Blockverschlüsselung\|Blockchiffre]] [[Data Encryption Standard\|DES]] und die [[Stromverschlüsselung\|Stromchiffre]] [[RC4]] bieten eine gute Leistung, gelten heute jedoch nicht mehr als hinreichend sicher. RC4 wird seit 2016 von den großen [[Webbrowser]]n nicht mehr unterstützt.<ref>Emil Protalinski: [https://venturebeat.com/2015/09/01/google-microsoft-and-mozilla-will-drop-rc4-support-in-chrome-edge-ie-and-firefox-next-year/ Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year], VentureBeat, 1. September 2015.</ref>

	Zur ~~Entlastung~~ der Server-~~CPU~~ ~~werden~~ auch Hardware-~~SSL-Beschleuniger~~ ~~(''~~[[~~SSL~~ ~~accelerators]]'') angeboten:~~ PCI-Steckkarten mit speziellen, optimierten Prozessoren, die aus der ~~SSL~~-Bibliothek angesprochen werden. Daneben gibt es auch eigenständige Geräte, meist in Rack-Bauweise, die Teile des HTTP-Datenstroms automatisch verschlüsseln. Weiterhin werden Server mit programmierbaren Recheneinheiten angeboten, die mit entsprechenden SSL-Bibliotheken höhere Leistung als vergleichbar aufwendige Universal-CPUs erreichen, so die MAU (''Modular Arithmetic Unit'') von [[Sun Microsystems\|Sun]]. Diese spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und [[Mehrkernprozessor\|Multi-Core]]-Systeme der großen CPU-Hersteller Intel und AMD.<ref name="anant_ssl">[http://www.anandtech.com/show/2143/6 ''Quad Core Intel Xeon SSL Performance''] auf anandtech.com, 27. Dezember 2006.</ref>		Zur Erhöhung der Server-Performance wird auch Hardware-Beschleunigung eingesetzt. Eine Möglichkeit ist der Einsatz von [[Peripheral Component Interconnect\|PCI-Steckkarten]] mit speziellen, optimierten Prozessoren, die aus der TLS-Bibliothek angesprochen werden. Daneben gibt es auch eigenständige Geräte, meist in Rack-Bauweise, die Teile des HTTP-Datenstroms automatisch verschlüsseln. Weiterhin werden Server mit programmierbaren Recheneinheiten angeboten, die mit entsprechenden SSL-Bibliotheken höhere Leistung als vergleichbar aufwendige Universal-CPUs erreichen, so die MAU (''Modular Arithmetic Unit'') von [[Sun Microsystems\|Sun]]. Diese spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und [[Mehrkernprozessor\|Multi-Core]]-Systeme der großen CPU-Hersteller Intel und AMD.<ref name="anant_ssl">[http://www.anandtech.com/show/2143/6 ''Quad Core Intel Xeon SSL Performance''] auf anandtech.com, 27. Dezember 2006.</ref> Moderne Prozessoren enthalten mit [[AES-NI]] eine Hardware-Beschleunigung für den [[Advanced Encryption Standard\|AES-Verschlüsselungsalgorithmus]], der einen Teil der für HTTPS notwendigen Rechenoperationen ausmacht.

	2010 verursachte die Verschlüsselung beispielsweise bei [[Gmail]] weniger als 1 % der [[Prozessor]]-Last, weniger als 10 KB [[Arbeitsspeicher]]bedarf pro Verbindung und weniger als 2 % des Netzwerk-[[Datenverkehr]]s.<ref name="overclocking-ssl">{{Internetquelle \|autor=Adam Langley, Nagendra Modadugu, Wan-Teh Chang \|url=https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html \|titel=Overclocking SSL \|werk=ImperialViolet. Adam Langley’s Weblog \|datum=2010-06-25 \|sprache=en \|abruf=2014-10-23}}</ref> 10 Jahre vorher belastete der Rechenaufwand der Verschlüsselung die Server noch stark.<ref name="overclocking-ssl" />		2010 verursachte die Verschlüsselung beispielsweise bei [[Gmail]] weniger als 1 % der [[Prozessor]]-Last, weniger als 10 KB [[Arbeitsspeicher]]bedarf pro Verbindung und weniger als 2 % des Netzwerk-[[Datenverkehr]]s.<ref name="overclocking-ssl">{{Internetquelle \|autor=Adam Langley, Nagendra Modadugu, Wan-Teh Chang \|url=https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html \|titel=Overclocking SSL \|werk=ImperialViolet. Adam Langley’s Weblog \|datum=2010-06-25 \|sprache=en \|abruf=2014-10-23}}</ref> 10 Jahre vorher belastete der Rechenaufwand der Verschlüsselung die Server noch stark.<ref name="overclocking-ssl" />

Matthäus Wander: /* Leistung */ Korrigiert und aktualisiert

2024-10-03T16:38:55Z

Leistung: Korrigiert und aktualisiert

← Nächstältere Version		Version vom 3. Oktober 2024, 18:38 Uhr
Zeile 120:		Zeile 120:

	=== Leistung ===		=== Leistung ===
	Beim Verbindungsaufbau ~~legt~~ ~~der~~ Server einen Verschlüsselungsalgorithmus ~~fest~~. In ~~der~~ ~~Theorie~~ ~~soll~~ ~~sich~~ ~~der~~ ~~Server~~ ~~dabei~~ an ~~den~~ ~~Wünschen~~ ~~des~~ ~~Clients~~ ~~orientieren.~~ Um ~~Rechenzeit~~ zu ~~sparen,~~ ~~werden~~ ~~jedoch~~ ~~auf~~ ~~Servern~~ ~~mit~~ ~~hohem~~ [[Datenverkehr]] ~~bevorzugt~~ ~~[[Stromverschlüsselung\|Strom-Chiffren]]~~ ~~eingesetzt,~~ da ~~diese~~ ~~weniger~~ ~~rechenintensiv~~ ~~sind~~ ~~als~~ [[Blockverschlüsselung\|~~Block-Chiffren~~]] ~~wie~~ [[~~Advanced~~ Encryption Standard\|~~AES~~]] ~~oder~~ [[~~Camellia (Algorithmus)~~\|~~Camellia~~]]. ~~Viele~~ ~~der~~ ~~dabei~~ ~~lange~~ ~~Zeit~~ ~~genutzten~~ ~~Verfahren~~ ~~wie~~ ~~[[RC4]]~~ ~~gelten~~ als ~~unsicher~~ ~~und~~ ~~werden~~ ~~daher~~ seit 2016 von den großen [[Webbrowser]]n nicht mehr unterstützt.<ref>Emil Protalinski: [https://venturebeat.com/2015/09/01/google-microsoft-and-mozilla-will-drop-rc4-support-in-chrome-edge-ie-and-firefox-next-year/ Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year], VentureBeat, 1. September 2015.</ref>		Beim Verbindungsaufbau handeln Client und Server im [[Transport Layer Security#TLS Handshake Protocol\|TLS-Handshake]] einen Verschlüsselungsalgorithmus aus. Hierbei besteht ein Zielkonflikt zwischen möglichst sicheren und performanten Algorithmen. Dies gilt insbesondere für den Server, da dieser für gewöhnlich mehrere Clients gleichzeitig bedient und somit einen höheren [[Datenverkehr]] als der Client verarbeitet. Früher übliche Verfahren wie die [[Blockverschlüsselung\|Blockchiffre]] [[Data Encryption Standard\|DES]] und die [[Stromverschlüsselung\|Stromchiffre]] [[RC4]] boten eine gute Leistung, gelten heute jedoch nicht mehr als hinreichend sicher. RC4 wird seit 2016 von den großen [[Webbrowser]]n nicht mehr unterstützt.<ref>Emil Protalinski: [https://venturebeat.com/2015/09/01/google-microsoft-and-mozilla-will-drop-rc4-support-in-chrome-edge-ie-and-firefox-next-year/ Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year], VentureBeat, 1. September 2015.</ref>

	Zur Entlastung der Server-CPU werden auch Hardware-SSL-Beschleuniger (''[[SSL accelerators]]'') angeboten: PCI-Steckkarten mit speziellen, optimierten Prozessoren, die aus der SSL-Bibliothek angesprochen werden. Daneben gibt es auch eigenständige Geräte, meist in Rack-Bauweise, die Teile des HTTP-Datenstroms automatisch verschlüsseln. Weiterhin werden Server mit programmierbaren Recheneinheiten angeboten, die mit entsprechenden SSL-Bibliotheken höhere Leistung als vergleichbar aufwendige Universal-CPUs erreichen, so die MAU (''Modular Arithmetic Unit'') von [[Sun Microsystems\|Sun]]. Diese spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und [[Mehrkernprozessor\|Multi-Core]]-Systeme der großen CPU-Hersteller Intel und AMD.<ref name="anant_ssl">[http://www.anandtech.com/show/2143/6 ''Quad Core Intel Xeon SSL Performance''] auf anandtech.com, 27. Dezember 2006.</ref>		Zur Entlastung der Server-CPU werden auch Hardware-SSL-Beschleuniger (''[[SSL accelerators]]'') angeboten: PCI-Steckkarten mit speziellen, optimierten Prozessoren, die aus der SSL-Bibliothek angesprochen werden. Daneben gibt es auch eigenständige Geräte, meist in Rack-Bauweise, die Teile des HTTP-Datenstroms automatisch verschlüsseln. Weiterhin werden Server mit programmierbaren Recheneinheiten angeboten, die mit entsprechenden SSL-Bibliotheken höhere Leistung als vergleichbar aufwendige Universal-CPUs erreichen, so die MAU (''Modular Arithmetic Unit'') von [[Sun Microsystems\|Sun]]. Diese spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und [[Mehrkernprozessor\|Multi-Core]]-Systeme der großen CPU-Hersteller Intel und AMD.<ref name="anant_ssl">[http://www.anandtech.com/show/2143/6 ''Quad Core Intel Xeon SSL Performance''] auf anandtech.com, 27. Dezember 2006.</ref>

Aka: Tippfehler entfernt

2024-10-01T06:44:30Z

Tippfehler entfernt

← Nächstältere Version		Version vom 1. Oktober 2024, 08:44 Uhr
Zeile 17:		Zeile 17:
	\|}		\|}

	'''Hypertext Transfer Protocol Secure''' ('''HTTPS;''' {{enS}} für „sicheres Hypertext-Übertragungsprotokoll“) ist ein [[Netzwerkprotokoll]] im [[World Wide Web]], mit dem Daten abhörsicher übertragen werden können. Es stellt ein [[Verschlüsselungsprotokoll]] für die [[Transportverschlüsselung]] dar. Technisch baut HTTPS auf [[Transport Layer Security\|TLS]] auf, das ~~eine~~ eine zusätzliche Kommunikationsschicht zwischen [[Hypertext Transfer Protocol\|HTTP]] und [[Transmission Control Protocol\|TCP]] darstellt. Eine HTTPS-Adresse wird über das [[Uniform Resource Identifier#Aufbau\|URI-Schema]] „https“ identifiziert.<ref name="rfc9110" />		'''Hypertext Transfer Protocol Secure''' ('''HTTPS;''' {{enS}} für „sicheres Hypertext-Übertragungsprotokoll“) ist ein [[Netzwerkprotokoll]] im [[World Wide Web]], mit dem Daten abhörsicher übertragen werden können. Es stellt ein [[Verschlüsselungsprotokoll]] für die [[Transportverschlüsselung]] dar. Technisch baut HTTPS auf [[Transport Layer Security\|TLS]] auf, das eine zusätzliche Kommunikationsschicht zwischen [[Hypertext Transfer Protocol\|HTTP]] und [[Transmission Control Protocol\|TCP]] darstellt. Eine HTTPS-Adresse wird über das [[Uniform Resource Identifier#Aufbau\|URI-Schema]] „https“ identifiziert.<ref name="rfc9110" />

	HTTPS wurde von [[Netscape Communications\|Netscape]] entwickelt und zusammen mit [[Transport Layer Security\|SSL]] 1.0 erstmals 1994 mit deren Browser veröffentlicht. Eine formale Spezifikation wurde im Jahr 2000 als [[Request for Comments]] <nowiki>RFC 2818</nowiki> veröffentlicht.<ref name="rfc2818">{{RFC-Internet \|RFC=2818 \|Titel=HTTP Over TLS \|Datum=2000}}</ref> Diese wurde im Jahr 2022 durch den [[Internetstandard]] <nowiki>RFC 9110</nowiki> abgelöst.<ref name="rfc9110"/>		HTTPS wurde von [[Netscape Communications\|Netscape]] entwickelt und zusammen mit [[Transport Layer Security\|SSL]] 1.0 erstmals 1994 mit deren Browser veröffentlicht. Eine formale Spezifikation wurde im Jahr 2000 als [[Request for Comments]] <nowiki>RFC 2818</nowiki> veröffentlicht.<ref name="rfc2818">{{RFC-Internet \|RFC=2818 \|Titel=HTTP Over TLS \|Datum=2000}}</ref> Diese wurde im Jahr 2022 durch den [[Internetstandard]] <nowiki>RFC 9110</nowiki> abgelöst.<ref name="rfc9110"/>

109.43.112.251: /* Schreibfehler */

2024-10-01T05:13:59Z

Schreibfehler

← Nächstältere Version		Version vom 1. Oktober 2024, 07:13 Uhr
Zeile 48:		Zeile 48:
	* Serverseitig wird ausschließlich HTTPS zugelassen; eine aufgerufene HTTP-Adresse wird automatisch auf HTTPS weitergeleitet. Dies entspricht dem [[Stand der Technik]] im Internet.		* Serverseitig wird ausschließlich HTTPS zugelassen; eine aufgerufene HTTP-Adresse wird automatisch auf HTTPS weitergeleitet. Dies entspricht dem [[Stand der Technik]] im Internet.
	* Der Login wird über HTTPS erzwungen, bei dem ein [[HTTP-Cookie]] im Browser gesetzt wird, während die anderen Seitenaufrufe im Klartext gesendet werden. Dies war eine früher übliche Vorgehensweise, um sensible Informationen wie das Passwort oder Zahlungsdaten zu schützen, und ansonsten Rechenzeit zu sparen.		* Der Login wird über HTTPS erzwungen, bei dem ein [[HTTP-Cookie]] im Browser gesetzt wird, während die anderen Seitenaufrufe im Klartext gesendet werden. Dies war eine früher übliche Vorgehensweise, um sensible Informationen wie das Passwort oder Zahlungsdaten zu schützen, und ansonsten Rechenzeit zu sparen.
	* [[HTTP Strict Transport Security]] (HSTS): Der Server signalisiert beim ersten Seitenaufruf, dass der Client für alle zukünftigen Aufrufe HTTPS verwenden muss. Der Client speichert diese Information und stellt bei zukünftigen ~~Besucehn~~ immer eine Verbindung über HTTPS her. Dies entspricht dem Sicherheitsmodell [[Trust on First Use]]. Einige Browser-Hersteller liefern eine vorinstallierte Liste von HSTS-Einträgen aus, mit der der Browser auch schon beim ersten Besuch die Verwendung von HTTPS erzwingt.<ref>[https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ Preloading HSTS].</ref>		* [[HTTP Strict Transport Security]] (HSTS): Der Server signalisiert beim ersten Seitenaufruf, dass der Client für alle zukünftigen Aufrufe HTTPS verwenden muss. Der Client speichert diese Information und stellt bei zukünftigen Besuchen immer eine Verbindung über HTTPS her. Dies entspricht dem Sicherheitsmodell [[Trust on First Use]]. Einige Browser-Hersteller liefern eine vorinstallierte Liste von HSTS-Einträgen aus, mit der der Browser auch schon beim ersten Besuch die Verwendung von HTTPS erzwingt.<ref>[https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ Preloading HSTS].</ref>
	* Clientseitige Eingabe der HTTPS-Variante oder Browser-[[Plug-in]] (z. B. für [[Mozilla Firefox\|Firefox]] und [[Google Chrome\|Chrome]] „[[HTTPS Everywhere]]“), welches HTTP-Anfragen durch HTTPS-Anfragen ersetzt, bei Diensten, die beide Varianten unterstützen.		* Clientseitige Eingabe der HTTPS-Variante oder Browser-[[Plug-in]] (z. B. für [[Mozilla Firefox\|Firefox]] und [[Google Chrome\|Chrome]] „[[HTTPS Everywhere]]“), welches HTTP-Anfragen durch HTTPS-Anfragen ersetzt, bei Diensten, die beide Varianten unterstützen.
	* Seit 2020 (Version 83) kann [[Firefox]] so eingestellt werden, dass es nur HTTPS verwendet.<ref>{{Internetquelle \|url=https://support.mozilla.org/en-US/kb/https-only-prefs \|titel=HTTPS-Only Mode in Firefox \|werk=support.mozilla.org \|sprache=en \|abruf=2021-06-18}}</ref> Falls eine Website nur über das unsichere HTTP erreicht werden kann, erfolgt der Zugriff erst nach expliziter Zustimmung durch den Nutzenden.		* Seit 2020 (Version 83) kann [[Firefox]] so eingestellt werden, dass es nur HTTPS verwendet.<ref>{{Internetquelle \|url=https://support.mozilla.org/en-US/kb/https-only-prefs \|titel=HTTPS-Only Mode in Firefox \|werk=support.mozilla.org \|sprache=en \|abruf=2021-06-18}}</ref> Falls eine Website nur über das unsichere HTTP erreicht werden kann, erfolgt der Zugriff erst nach expliziter Zustimmung durch den Nutzenden.

Matthäus Wander: /* Einleitung */ präzisiert und ergänzt

2024-09-29T07:17:44Z

Einleitung: präzisiert und ergänzt

← Nächstältere Version		Version vom 29. September 2024, 09:17 Uhr
Zeile 17:		Zeile 17:
	\|}		\|}

	'''Hypertext Transfer Protocol Secure''' ('''HTTPS;''' {{enS}} für „sicheres Hypertext-Übertragungsprotokoll“) ist ein [[~~Kommunikationsprotokoll~~]] im [[World Wide Web]], mit dem Daten abhörsicher übertragen werden können. Es stellt ~~eine~~ ''Transportverschlüsselung'' dar.		'''Hypertext Transfer Protocol Secure''' ('''HTTPS;''' {{enS}} für „sicheres Hypertext-Übertragungsprotokoll“) ist ein [[Netzwerkprotokoll]] im [[World Wide Web]], mit dem Daten abhörsicher übertragen werden können. Es stellt ein [[Verschlüsselungsprotokoll]] für die [[Transportverschlüsselung]] dar. Technisch baut HTTPS auf [[Transport Layer Security\|TLS]] auf, das eine eine zusätzliche Kommunikationsschicht zwischen [[Hypertext Transfer Protocol\|HTTP]] und [[Transmission Control Protocol\|TCP]] darstellt. Eine HTTPS-Adresse wird über das [[Uniform Resource Identifier#Aufbau\|URI-Schema]] „https“ identifiziert.<ref name="rfc9110" />

	HTTPS wurde von [[Netscape Communications\|Netscape]] entwickelt und zusammen mit [[Transport Layer Security\|SSL]] 1.0 erstmals 1994 mit deren Browser veröffentlicht.		HTTPS wurde von [[Netscape Communications\|Netscape]] entwickelt und zusammen mit [[Transport Layer Security\|SSL]] 1.0 erstmals 1994 mit deren Browser veröffentlicht. Eine formale Spezifikation wurde im Jahr 2000 als [[Request for Comments]] <nowiki>RFC 2818</nowiki> veröffentlicht.<ref name="rfc2818">{{RFC-Internet \|RFC=2818 \|Titel=HTTP Over TLS \|Datum=2000}}</ref> Diese wurde im Jahr 2022 durch den [[Internetstandard]] <nowiki>RFC 9110</nowiki> abgelöst.<ref name="rfc9110"/>

	Technisch definiert wurde es als [[Uniform Resource Identifier#Aufbau\|URI-Schema]], eine zusätzliche Schicht zwischen [[Hypertext Transfer Protocol\|HTTP]] und [[Transmission Control Protocol\|TCP]]. Eine formale Spezifikation wurde im Jahr 2000 als [[Request for Comments]] <nowiki>RFC 2818</nowiki> veröffentlicht.<ref name="rfc2818">{{RFC-Internet \|RFC=2818 \|Titel=HTTP Over TLS \|Datum=2000}}</ref> Diese wurde im Jahr 2022 durch den [[Internetstandard]] <nowiki>RFC 9110</nowiki> abgelöst.<ref name="rfc9110"/>

	== Nutzen ==		== Nutzen ==

Matthäus Wander: /* Vorinstallierte Zertifikate */ aktualisiert

2024-09-28T10:04:55Z

Vorinstallierte Zertifikate: aktualisiert

← Nächstältere Version		Version vom 28. September 2024, 12:04 Uhr
Zeile 54:		Zeile 54:
	* Seit 2020 (Version 83) kann [[Firefox]] so eingestellt werden, dass es nur HTTPS verwendet.<ref>{{Internetquelle \|url=https://support.mozilla.org/en-US/kb/https-only-prefs \|titel=HTTPS-Only Mode in Firefox \|werk=support.mozilla.org \|sprache=en \|abruf=2021-06-18}}</ref> Falls eine Website nur über das unsichere HTTP erreicht werden kann, erfolgt der Zugriff erst nach expliziter Zustimmung durch den Nutzenden.		* Seit 2020 (Version 83) kann [[Firefox]] so eingestellt werden, dass es nur HTTPS verwendet.<ref>{{Internetquelle \|url=https://support.mozilla.org/en-US/kb/https-only-prefs \|titel=HTTPS-Only Mode in Firefox \|werk=support.mozilla.org \|sprache=en \|abruf=2021-06-18}}</ref> Falls eine Website nur über das unsichere HTTP erreicht werden kann, erfolgt der Zugriff erst nach expliziter Zustimmung durch den Nutzenden.

	=== ~~Vorinstallierte Zertifikate~~ ===		=== Vertrauensanker ===
			Die Authentizität einer aufgerufenen HTTPS-Adresse ergibt sich durch ein [[Digitales Zertifikat]] des Webservers. Das Zertifikat ist Teil einer [[Public-Key-Infrastruktur]] (PKI) nach dem [[X.509]]-Standard. Serverzertifikate werden von [[Zertifizierungsstelle (Digitale Zertifikate)\|Zertifizierungsstellen]] ausgestellt, deren Wurzelzertifikate dem Browser bekannt sein müssen und als [[Vertrauensanker]] dienen. Ist das Serverzertifikat authentisch, so zeigt der Browser die Verbindung als sicher an.
	Um diese für Unkundige eventuell irritierende Abfrage zu vermeiden, wurde mit der Zeit eine Reihe von Root-Zertifikaten von den Browserherstellern akzeptiert, die schon bei der Installation eingetragen werden. Webseiten, die entsprechende Zertifikate haben, werden dann, ebenso wie davon abgeleitete Unter-Zertifikate, bei Aufruf ohne Nachfrage akzeptiert. Ob ein Root-Zertifikat dem Browser bekannt ist, hängt von der Browser-Version ab; zudem wird die Liste der Zertifikate teils auch online im Rahmen der Systemaktualisierung auf den neuesten Stand gebracht, so bei Microsoft Windows.

	~~Mit~~ ~~dem~~ ~~[[Internet Explorer#Version 7\|Internet Explorer 7]] hat Microsoft, kurz danach auch Mozilla mit~~ dem ~~[[Mozilla Firefox\|Firefox 3]], die Warnung bei~~ nicht ~~eingetragenen~~ ~~Zertifikaten~~ ~~verschärft:~~ ~~Erschien~~ ~~vorher~~ ~~nur~~ ~~ein~~ ~~[[Pop-up]]~~ ~~„Sicherheitshinweis“,~~ ~~das~~ nach ~~Name,~~ ~~Quelle~~ und ~~Laufzeit~~ des ~~Zertifikats~~ ~~differenzierte~~, so ~~wird~~ ~~nun~~ der ~~Inhalt der Webseite ausgeblendet und eine Warnung angezeigt, mit der Empfehlung,~~ die Seite ~~nicht~~ zu ~~benutzen.~~ Um ~~diese~~ ~~sehen~~ zu ~~können,~~ ~~muss der Anwender dann explizit~~ eine „Ausnahme hinzufügen“. ~~Ein~~ ~~nicht~~ im Browser eingetragenes Zertifikat ~~wird~~ damit für Massenanwendungen ~~zunehmend~~ untauglich.		Ist das Wurzelzertifikat dem Browser nicht bekannt, so führt das zu einer Sicherheitswarnung beim Seitenaufruf. Je nach Einstellung der Browser und des Servers (HSTS, siehe oben) kann der Anwender die Seite entweder gar nicht aufrufen oder explizit auf eigenes Risiko eine „Ausnahme hinzufügen“. Eine Website ohne ein im Browser eingetragenes Zertifikat ist damit für Massenanwendungen untauglich.

			Je nach Browser und [[Betriebssystem]] liefern die Browser-Hersteller entweder eine Liste von vertrauenswürdigen Stammzertifikaten mit oder greifen auf den Zertifikatsspeicher des Betriebssystems zurück. Ob ein Wurzelzertifikat dem Browser bekannt ist, hängt somit von der Version des Browsers und des Betriebssystems ab. Die Liste der vertrauenswürdigen Wurzelzertifikate wird durch den Hersteller mit [[Softwareaktualisierung]]en auf den neuesten Stand gebracht.
	Die Frage, welche Zertifikate in die Browser aufgenommen werden, hat in der Open-Source-Community fallweise zu längeren Diskussionen geführt, so zwischen [[CAcert]], einem Anbieter kostenloser Zertifikate, und der [[Mozilla Foundation]], siehe [[CAcert#Vertrauenswürdigkeit\|CAcert (Vertrauenswürdigkeit)]].

			Welche Wurzelzertifikate die Hersteller in ihre Zertifikatsspeicher aufnehmen, ergibt sich aus den Regelungen des [[CA/Browser Forum]]s. Die Zertifizierungsstelle muss hierbei durch einen externen [[Audit]] nachweisen, mit den Sicherheitsvorgaben konform zu sein. Da dies mit Kosten verbunden ist, stellt es eine Aufnahmehürde dar. Das in der [[Open Source\|Open-Source-Community]] verbreitete [[CAcert]], ein früher Anbieter kostenloser Zertifikate, ist eine prominente Zertifizierungsstelle, das nicht in den Browsern mitgeliefert wird. Anwender, die eine Seite mit CAcert-Zertifikat besuchen, müssen das Wurzelzertifikat händisch installieren.
	Ende 2015 ging [[Let’s Encrypt]] online, gegründet u. a. von [[Mozilla]] und der [[Electronic Frontier Foundation]]. Hier werden kostenlose Zertifikate für jedermann angeboten mit dem Ziel, die Verbreitung von HTTPS insgesamt zu fördern. Für die Installation und laufende Aktualisierung der Zertifikate ist jedoch eine eigene Software auf dem Server notwendig.

			Um die Verbreitung von HTTPS zu fördern, ging Ende 2015 die gemeinnützige Zertifizierungsstelle [[Let’s Encrypt]] in Betrieb. Let’s Encrypt stellt für jeden kostenlose Zertifikate aus, die von den gängigen Browsern als vertrauenswürdig akzeptiert werden. Für die Installation und laufende Aktualisierung der Zertifikate ist eine Software auf dem Server notwendig.

	== Server-Betrieb ==		== Server-Betrieb ==

Matthäus Wander: /* Varianten der HTTPS-Anwahl */ aktualisiert

2024-09-28T09:03:41Z

Varianten der HTTPS-Anwahl: aktualisiert

← Nächstältere Version		Version vom 28. September 2024, 11:03 Uhr
Zeile 48:		Zeile 48:
	=== Varianten der HTTPS-Anwahl ===		=== Varianten der HTTPS-Anwahl ===
	Die Entscheidung, ob eine sichere HTTPS- statt einer HTTP-Verbindung genutzt wird, kann unterschiedlich erfolgen:		Die Entscheidung, ob eine sichere HTTPS- statt einer HTTP-Verbindung genutzt wird, kann unterschiedlich erfolgen:
	* Serverseitig wird ausschließlich HTTPS zugelassen, ~~wie~~ ~~meist~~ ~~bei~~ ~~[[Electronic~~ ~~Banking\|Online-Banking]];~~ ~~teils~~ ~~wird~~ ~~dabei~~ ~~eine~~ ~~angewählte~~ ~~http-Adresse~~ ~~automatisch~~ ~~auf~~ ~~https~~ ~~weitergeleitet~~.		* Serverseitig wird ausschließlich HTTPS zugelassen; eine aufgerufene HTTP-Adresse wird automatisch auf HTTPS weitergeleitet. Dies entspricht dem [[Stand der Technik]] im Internet.
	* Der Login wird über HTTPS erzwungen, ~~dann~~ ~~wird~~ ein [[HTTP-Cookie]] im Browser gesetzt ~~und~~, um ~~Rechenzeit~~ zu ~~sparen~~, ~~der~~ ~~weitere~~ ~~Dienst~~ ~~unverschlüsselt~~ ~~abgewickelt;~~ ~~z. B.~~ ~~bei~~ ~~[[eBay]]~~.		* Der Login wird über HTTPS erzwungen, bei dem ein [[HTTP-Cookie]] im Browser gesetzt wird, während die anderen Seitenaufrufe im Klartext gesendet werden. Dies war eine früher übliche Vorgehensweise, um sensible Informationen wie das Passwort oder Zahlungsdaten zu schützen, und ansonsten Rechenzeit zu sparen.
	* ~~Clientseitig durch~~ [[~~HSTS~~]]: ~~Wenn~~ der ~~Server~~ ~~nur~~ ~~HTTPS~~ ~~zulässt~~ ~~(wie~~ ~~oben~~ ~~beschrieben),~~ ~~kann~~ ~~der~~ ~~Browser~~ ~~dies~~ ~~speichern~~ und stellt ~~zukünftig~~ immer eine Verbindung über HTTPS her. ~~Steht~~ ~~der~~ ~~Server~~ ~~zusätzlich~~ ~~auf~~ ~~der~~ ~~HSTS~~ ~~Preload~~ Liste, ~~stellt~~ der Browser auch beim ersten Besuch ~~schon~~ ~~direkt~~ ~~eine~~ HTTPS~~-Verbindung~~ ~~her~~.<ref>[https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ Preloading HSTS].</ref>		* [[HTTP Strict Transport Security]] (HSTS): Der Server signalisiert beim ersten Seitenaufruf, dass der Client für alle zukünftigen Aufrufe HTTPS verwenden muss. Der Client speichert diese Information und stellt bei zukünftigen Besucehn immer eine Verbindung über HTTPS her. Dies entspricht dem Sicherheitsmodell [[Trust on First Use]]. Einige Browser-Hersteller liefern eine vorinstallierte Liste von HSTS-Einträgen aus, mit der der Browser auch schon beim ersten Besuch die Verwendung von HTTPS erzwingt.<ref>[https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ Preloading HSTS].</ref>
	* Clientseitige Eingabe der HTTPS-Variante oder Browser-[[Plug-in]] (z. B. für [[Mozilla Firefox\|Firefox]] und [[Google Chrome\|Chrome]] „[[HTTPS Everywhere]]“), welches ~~http~~-Anfragen durch ~~https~~-Anfragen ersetzt, bei Diensten, die beide Varianten unterstützen.		* Clientseitige Eingabe der HTTPS-Variante oder Browser-[[Plug-in]] (z. B. für [[Mozilla Firefox\|Firefox]] und [[Google Chrome\|Chrome]] „[[HTTPS Everywhere]]“), welches HTTP-Anfragen durch HTTPS-Anfragen ersetzt, bei Diensten, die beide Varianten unterstützen.
	* Seit 2020 (Version 83) kann [[Firefox]] so eingestellt werden, dass es nur HTTPS verwendet.<ref>{{Internetquelle \|url=https://support.mozilla.org/en-US/kb/https-only-prefs \|titel=HTTPS-Only Mode in Firefox \|werk=support.mozilla.org \|sprache=en \|abruf=2021-06-18}}</ref> Falls eine Website nur über das unsichere HTTP erreicht werden kann, erfolgt der Zugriff erst nach expliziter Zustimmung durch den Nutzenden.		* Seit 2020 (Version 83) kann [[Firefox]] so eingestellt werden, dass es nur HTTPS verwendet.<ref>{{Internetquelle \|url=https://support.mozilla.org/en-US/kb/https-only-prefs \|titel=HTTPS-Only Mode in Firefox \|werk=support.mozilla.org \|sprache=en \|abruf=2021-06-18}}</ref> Falls eine Website nur über das unsichere HTTP erreicht werden kann, erfolgt der Zugriff erst nach expliziter Zustimmung durch den Nutzenden.

	Gemäß der ursprünglichen Auslegung soll der Client-Browser nach Anwahl der HTTPS-Adresse dem Anwender zuerst das [[Digitales Zertifikat\|Zertifikat]] anzeigen. Dieser entscheidet nun, ob er dem Zertifikat für diese Sitzung vertraut, es evtl. auch permanent speichert, gegebenenfalls nach Prüfung über die angegebenen Links. Andernfalls wird die HTTPS-Verbindung nicht hergestellt („Diese Seite verlassen“ bei Firefox bzw. „Klicken Sie hier um diese Seite zu verlassen.“ beim Internet Explorer).

	=== Vorinstallierte Zertifikate ===		=== Vorinstallierte Zertifikate ===

← Nächstältere Version		Version vom 4. Februar 2025, 11:15 Uhr
Zeile 69:		Zeile 69:
	Das [[Digitales Zertifikat\|digitale Zertifikat]] für [[Secure Sockets Layer\|SSL]], das die Authentifizierung ermöglicht, ist vom Server bereitzustellen: Ein Binärdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – [[Zertifizierungsstelle (Digitale Zertifikate)\|Zertifizierungsstelle]] (CA von {{enS\|certificate authority}}) ausgestellt wird, das den Server und die [[Domain (Internet)\|Domain]] eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und der Firmenname des Antragstellers geprüft.		Das [[Digitales Zertifikat\|digitale Zertifikat]] für [[Secure Sockets Layer\|SSL]], das die Authentifizierung ermöglicht, ist vom Server bereitzustellen: Ein Binärdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – [[Zertifizierungsstelle (Digitale Zertifikate)\|Zertifizierungsstelle]] (CA von {{enS\|certificate authority}}) ausgestellt wird, das den Server und die [[Domain (Internet)\|Domain]] eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und der Firmenname des Antragstellers geprüft.

	In gängigen Browsern eingetragene Zertifikate werden typischerweise zu Preisen zwischen 15 und 600 € pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind. Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus. Die etwa von <!--[[StartCom]]<ref>{{Internetquelle \|url=https://www.heise.de/security/meldung/Mozilla-vertraut-kostenlosen-StartCom-Zertifikaten-129472.html \|titel=Mozilla vertraut kostenlosen StartCom Zertifikaten \|hrsg=Heise-Online \|datum=2006-06-03 \|zugriff=2010-03-04}}<br />Vgl. dazu auch ''[[:en:Comparison of SSL certificates for web servers\|Comparison of SSL certificates for web servers]]'' in der englischsprachigen Wikipedia.</ref> oder--> [[Let’s Encrypt]] ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert. Ebenfalls kostenlose Zertifikate erstellt [[CAcert]], wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe [[#~~Vorinstallierte Zertifikate~~\|oben]]. Ein solches Zertifikat muss daher bei der [[#Client-Verarbeitung\|Client-Verarbeitung]] vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein.		In gängigen Browsern eingetragene Zertifikate werden typischerweise zu Preisen zwischen 15 und 600 € pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind. Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus. Die etwa von <!--[[StartCom]]<ref>{{Internetquelle \|url=https://www.heise.de/security/meldung/Mozilla-vertraut-kostenlosen-StartCom-Zertifikaten-129472.html \|titel=Mozilla vertraut kostenlosen StartCom Zertifikaten \|hrsg=Heise-Online \|datum=2006-06-03 \|zugriff=2010-03-04}}<br />Vgl. dazu auch ''[[:en:Comparison of SSL certificates for web servers\|Comparison of SSL certificates for web servers]]'' in der englischsprachigen Wikipedia.</ref> oder--> [[Let’s Encrypt]] ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert. Ebenfalls kostenlose Zertifikate erstellt [[CAcert]], wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe [[#Vertrauensanker\|oben]]. Ein solches Zertifikat muss daher bei der [[#Client-Verarbeitung\|Client-Verarbeitung]] vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein.

	Um veraltete oder unsicher gewordene Zertifikate für ungültig zu erklären, sind [[Zertifikatsperrliste]]n ({{enS\|certificate revocation list}}, ''CRL'') vorgesehen. Das Verfahren sieht vor, dass diese Listen regelmäßig von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden.		Um veraltete oder unsicher gewordene Zertifikate für ungültig zu erklären, sind [[Zertifikatsperrliste]]n ({{enS\|certificate revocation list}}, ''CRL'') vorgesehen. Das Verfahren sieht vor, dass diese Listen regelmäßig von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden.