Was ist HTTPS? Verschlüsselung, Zertifikate und TLS einfach erklärt (2026)

Was ist HTTPS? HTTPS steht für Hypertext Transfer Protocol Secure. Es ist die verschlüsselte Variante von HTTP, dem Protokoll, mit dem dein Browser Webseiten lädt. Technisch ist HTTPS nichts anderes als normales HTTP, das durch einen verschlüsselten Tunnel geschickt wird. Dieser Tunnel heißt TLS (Transport Layer Security), früher SSL. Er sorgt für drei Dinge: Niemand unterwegs kann mitlesen, niemand kann die Daten unbemerkt verändern, und dein Browser weiß, dass er wirklich mit dem richtigen Server spricht.

Das Schloss in der Adresszeile kennt jeder. Was genau es verspricht, wissen erstaunlich wenige. Und noch weniger wissen, was es nicht verspricht. Genau das klären wir hier, und zwar nicht nur mit Theorie. Wir betreiben selbst eine ganze Reihe Websites auf einem eigenen Server und haben am 30. Oktober 2026 nachgemessen, was HTTPS in der Praxis macht. Drei Befunde vorweg:

1. Wir haben dieselbe Anfrage mit einem erfundenen Passwort einmal per HTTP und einmal per HTTPS an unseren Server geschickt und den Netzwerkverkehr mitgeschnitten. Per HTTP stand passwort=geheim123 dreimal im Klartext im Mitschnitt. Per HTTPS: null Treffer. Lesbar blieb nur ein einziges Wort: der Domainname.

2. Der verschlüsselte Verbindungsaufbau kostet uns rund 17 Millisekunden. Das ist der ganze Preis.

3. Auf unserem Server liegen 1.042 Zertifikate, die alle automatisch erneuert werden. Trotzdem hatten wir bei einem Serverumzug schon einmal eine abgelaufene Seite, weil ein Zertifikat nur kopiert und nicht neu eingerichtet wurde. Dazu unten mehr.

Was ist HTTPS? Die Kurzfassung in fünf Sätzen

1. HTTP ist die Sprache, in der Browser und Webserver sich unterhalten. Sie wurde in den frühen 1990ern entworfen, als niemand an Lauscher dachte, und schickt alles im Klartext.
2. HTTPS packt genau diese Unterhaltung in einen verschlüsselten Kanal. Den Kanal liefert TLS, der Nachfolger von SSL.
3. Bevor die eigentliche Seite fließt, handeln Browser und Server in einem kurzen Handshake einen gemeinsamen geheimen Schlüssel aus, ohne ihn jemals über die Leitung zu schicken.
4. Ein Zertifikat beweist dabei, dass der Server wirklich zu der Domain gehört, die du aufgerufen hast. Ausgestellt wird es von einer Zertifizierungsstelle, der dein Browser vertraut.
5. HTTPS schützt die Verbindung. Es sagt nichts darüber, ob die Website selbst ehrlich ist.

Den fünften Punkt solltest du dir merken. Er ist der Grund für die meisten Missverständnisse rund um das Schloss.

HTTP vs. HTTPS: Was ist der Unterschied?

Der Unterschied zwischen HTTP und HTTPS liegt nicht darin, was übertragen wird, sondern wie. Die Anfrage selbst ist identisch: GET /blog/ HTTP/1.1, ein paar Kopfzeilen, vielleicht Formulardaten. Bei HTTP gehen diese Bytes so, wie sie sind, über jedes Kabel, jeden WLAN-Router und jeden Knotenpunkt zwischen dir und dem Server. Jeder, der unterwegs Zugriff hat, kann sie lesen und sogar verändern.

Bei HTTPS werden genau dieselben Bytes vorher verschlüsselt. Unterwegs sieht man nur noch Datensalat.

Unser Mitschnitt: Was ohne HTTPS durchs Netz geht

Statt das zu behaupten, haben wir es ausprobiert. Auf unserem Server lief tcpdump, ein Programm, das Netzwerkpakete mitschneidet. Dann haben wir zwei Anfragen geschickt, einmal unverschlüsselt und einmal verschlüsselt, beide mit einem erfundenen Passwort in der Adresse:

# Mitschnitt starten
tcpdump -i lo -s0 'tcp port 80 or tcp port 443' -w https-demo.pcap &

# Einmal ohne, einmal mit Verschlüsselung
curl -s "http://getmind.io/?passwort=geheim123"
curl -s "https://getmind.io/?passwort=geheim123"

# Wie oft taucht das Passwort im Mitschnitt auf?
tcpdump -r https-demo.pcap -A 'tcp port 80'  | grep -ac geheim123   # → 3
tcpdump -r https-demo.pcap -A 'tcp port 443' | grep -ac geheim123   # → 0

Das Ergebnis ist eindeutig. Im HTTP-Teil stand das Passwort dreimal lesbar im Mitschnitt: einmal in der Anfrage (GET /?passwort=geheim123 HTTP/1.1), dazu noch zweimal in der Antwort, weil unser Server HTTP-Anfragen auf HTTPS umleitet und die vollständige Adresse in der Weiterleitung zurückschickt. Ein schönes Detail: Selbst die Umleitung auf HTTPS verrät das, was vorher unverschlüsselt angefragt wurde. Die Umleitung kommt einfach zu spät.

Im HTTPS-Teil: null Treffer. Nicht das Passwort, nicht der Pfad, nicht die Kopfzeilen, nicht der Inhalt der Seite. Sichtbar war genau eine Sache, nämlich getmind.io, und zwar einmal. Warum ausgerechnet der Domainname durchsickert, erklären wir weiter unten beim Thema SNI.

Diesen Test haben wir lokal auf dem Server gemacht, damit niemand sonst betroffen ist. In einem öffentlichen WLAN sieht ein Angreifer mit demselben Werkzeug exakt dasselbe. Genau deshalb galt HTTP-Login im Café-WLAN früher als Klassiker. Das Firefox-Add-on Firesheep hat 2010 gezeigt, wie trivial es war, damit fremde Facebook- und Twitter-Sitzungen zu übernehmen. Kurz danach stellten die großen Plattformen auf HTTPS um.

Wie funktioniert HTTPS? Der TLS-Handshake Schritt für Schritt

HTTPS hat ein Henne-Ei-Problem zu lösen. Damit Browser und Server verschlüsselt sprechen können, brauchen beide denselben geheimen Schlüssel. Den können sie sich aber nicht einfach zuschicken, denn die Leitung ist ja gerade unsicher. Die Lösung ist eine der elegantesten Ideen der Kryptografie: der Schlüsselaustausch.

So läuft ein TLS-1.3-Handshake ab, vereinfacht:

1. Client Hello. Dein Browser meldet sich: „Hallo, ich will zu getmind.io, ich kann TLS 1.3 und diese Verschlüsselungsverfahren, und hier ist schon mal meine Hälfte für den Schlüsselaustausch.”
2. Server Hello. Der Server antwortet: „Okay, wir nehmen TLS 1.3 mit diesem Verfahren, und hier ist meine Hälfte.” Aus den beiden Hälften berechnen beide Seiten unabhängig voneinander denselben geheimen Schlüssel. Ein Lauscher, der beide Hälften sieht, kann ihn trotzdem nicht ausrechnen. Das ist das Diffie-Hellman-Prinzip, heute meist in der Variante mit elliptischen Kurven (ECDHE).
3. Zertifikat und Unterschrift. Ab hier ist schon alles verschlüsselt. Der Server schickt sein Zertifikat und unterschreibt den bisherigen Handshake mit seinem privaten Schlüssel. Damit beweist er, dass er der echte Inhaber des Zertifikats ist.
4. Prüfung im Browser. Dein Browser prüft: Passt der Name im Zertifikat zur Domain? Ist es noch gültig? Wurde es von einer Stelle unterschrieben, der ich vertraue? Stimmt die Unterschrift?
5. Finished. Beide bestätigen, dass sie dasselbe gesehen haben. Danach fließt ganz normales HTTP, nur eben verschlüsselt.

Bei TLS 1.3 braucht das alles nur eine Hin-und-Rück-Runde zwischen Browser und Server. Bei der älteren Version TLS 1.2 waren es zwei. Bei wiederholten Besuchen geht es sogar ohne zusätzliche Runde.

Unsere Verbindung im Detail

Mit openssl kannst du dir den Handshake jeder Website selbst ansehen. So sieht es bei uns aus:

echo | openssl s_client -connect getmind.io:443 -servername getmind.io 2>/dev/null \
  | grep -E "Protocol|Cipher|Server public key|Verify return"

Protocol  : TLSv1.3
Cipher    : TLS_AES_128_GCM_SHA256
Server public key is 256 bit
Verify return code: 0 (ok)

Übersetzt heißt das: Die Verbindung läuft über TLS 1.3. Die eigentlichen Daten werden mit AES-128 im GCM-Modus verschlüsselt, einem Verfahren, das gleichzeitig verschlüsselt und Manipulationen erkennt. Der Serverschlüssel ist ein 256-Bit-Schlüssel auf elliptischen Kurven (ECDSA). Wer 256 Bit für wenig hält: Ein ECDSA-Schlüssel mit 256 Bit gilt als ungefähr so stark wie ein klassischer RSA-Schlüssel mit 3.072 Bit, ist aber viel schneller.

Wir haben auch geprüft, welche Protokollversionen unser Server überhaupt annimmt:

Genau so soll es sein. TLS 1.0 und 1.1 sind seit 2021 offiziell abgekündigt (RFC 8996), alle großen Browser haben sie abgeschaltet. TLS 1.2 bleibt für ältere Geräte noch erlaubt. Eingestellt haben wir dafür übrigens nichts: Das ist schlicht die Standardeinstellung von Caddy, unserem Webserver.

Was ist ein SSL-Zertifikat, und was beweist es?

Ohne Zertifikat wäre die Verschlüsselung wertlos. Du hättest dann zwar eine verschlüsselte Verbindung, wüsstest aber nicht, mit wem. Ein Angreifer im selben WLAN könnte sich einfach dazwischenschalten, mit dir einen verschlüsselten Kanal aufbauen und mit dem echten Server einen zweiten. Das nennt man Man-in-the-Middle-Angriff.

Das Zertifikat verhindert genau das. Es ist ein digitales Dokument, das sinngemäß sagt: „Der öffentliche Schlüssel X gehört zur Domain getmind.io. Unterschrieben: Let’s Encrypt.” Unseres sieht so aus:

echo | openssl s_client -connect getmind.io:443 -servername getmind.io 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

subject=CN = getmind.io
issuer=C = US, O = Let's Encrypt, CN = YE1
notBefore=Sep  6 09:45:18 2026 GMT
notAfter=Dec  5 09:45:17 2026 GMT
X509v3 Subject Alternative Name:
    DNS:getmind.io

Drei Dinge fallen auf. Erstens ist das Zertifikat nur für getmind.io ausgestellt, für nichts anderes. Zweitens gilt es genau 90 Tage. Drittens wurde es von Let’s Encrypt ausgestellt, einer gemeinnützigen Zertifizierungsstelle, die seit 2015 kostenlose Zertifikate vergibt und damit den größten Teil des HTTPS-Booms erst möglich gemacht hat.

Die Vertrauenskette

Woher weiß dein Browser, dass er Let’s Encrypt trauen kann? Über eine Kette. Unser Server schickt nicht nur sein eigenes Zertifikat, sondern auch die Zwischenzertifikate mit:

0  getmind.io            ← ausgestellt von YE1
1  Let's Encrypt YE1     ← ausgestellt von Root YE
2  ISRG Root YE          ← ausgestellt von ISRG Root X2
3  ISRG Root X2          ← ausgestellt von ISRG Root X1

Am Ende der Kette steht ein Stammzertifikat (Root). Diese Stammzertifikate sind fest in deinem Betriebssystem oder Browser hinterlegt, etwa 150 Stück. Der Browser hangelt sich von unserem Zertifikat Glied für Glied bis zu einem Stammzertifikat hoch, das er kennt. Klappt das, ist die Kette gültig. Klappt es nicht, siehst du die rote Warnung „Ihre Verbindung ist nicht privat”.

Eine kleine Beobachtung am Rande: Die Kette, die Let’s Encrypt im Herbst 2026 ausliefert, ist länger als früher und läuft über neue Zwischen- und Stammzertifikate (YE1, Root YE). Für Besucher ändert das nichts. Für Admins, die alte Geräte oder sehr alte Java-Versionen bedienen müssen, kann so eine Umstellung aber der Grund sein, warum plötzlich einzelne Clients Fehler melden. Die Frage ist dann fast immer, ob das Gerät das jeweilige Stammzertifikat schon kennt.

DV, OV, EV: Gibt es „bessere” Zertifikate?

Zertifikate gibt es in drei Prüfstufen:

Die Verschlüsselung ist bei allen dreien exakt gleich stark. Der Unterschied liegt nur darin, wie gründlich der Inhaber geprüft wurde. Früher zeigten Browser bei EV-Zertifikaten den Firmennamen grün in der Adresszeile an. Das haben Chrome und Firefox 2019 abgeschafft, weil Studien zeigten, dass Nutzer den Unterschied ohnehin nicht bemerkten. Für einen Blog, einen kleinen Shop oder eine Firmenseite ist ein kostenloses DV-Zertifikat heute völlig ausreichend. Wir nutzen für alle unsere Seiten nichts anderes.

Was HTTPS nicht schützt

Das Schloss ist ein ehrliches Symbol, wird aber gern überschätzt. Hier die wichtigsten Grenzen.

HTTPS sagt nichts über die Seriosität der Website. Phishing-Seiten haben heute fast immer ein gültiges Zertifikat, denn das kostet nichts und dauert Sekunden. Das Schloss bedeutet nur: Du sprichst verschlüsselt mit dem Server von paypa1-login.example. Ob das eine gute Idee ist, entscheidet es nicht. Genau deshalb hat Chrome das Schloss 2023 durch ein neutrales Einstellungssymbol ersetzt. Google selbst hatte festgestellt, dass viele Nutzer das Schloss als „diese Seite ist vertrauenswürdig” missverstanden.

Der Domainname bleibt meist sichtbar. Erinnerst du dich an unseren Mitschnitt? Das Einzige, was im HTTPS-Teil lesbar war, war getmind.io. Der Grund heißt SNI (Server Name Indication). Auf unserem Server laufen über tausend Domains auf derselben IP-Adresse. Damit der Server weiß, welches Zertifikat er vorzeigen soll, nennt der Browser den Namen ganz am Anfang des Handshakes, noch unverschlüsselt. Dein Netzbetreiber oder das Café-WLAN sieht also, welche Seite du besuchst, nicht aber was du dort tust. Die Erweiterung Encrypted Client Hello (ECH) soll auch das verschlüsseln, ist aber noch nicht überall angekommen. Außerdem verrät die DNS-Abfrage den Namen ebenfalls, wenn sie unverschlüsselt läuft. Wie DNS funktioniert, haben wir in Was ist DNS? gezeigt.

Als Nebeneffekt hat unser Mitschnitt übrigens genau das bestätigt: In den Paketen anderer Verbindungen, die zufällig zur gleichen Zeit über den Server liefen, standen ebenfalls lesbare Domainnamen, und zwar nur die Namen.

HTTPS schützt nicht vor Angriffen auf den Server selbst. Wenn eine Website eine Sicherheitslücke hat oder ihre Datenbank unverschlüsselte Passwörter speichert, hilft die verschlüsselte Leitung dahin nichts. Wie schnell so etwas gehen kann, haben wir in unserem Artikel über IT-Sicherheitslücken beschrieben.

HTTPS schützt nicht vor Schadsoftware auf deinem Gerät. Ein Trojaner liest mit, bevor die Daten verschlüsselt werden.

Innerhalb deines Servers ist oft wieder Klartext. Viele Setups beenden die Verschlüsselung an einem Reverse Proxy und sprechen dahinter unverschlüsselt mit der Anwendung. Das ist auf demselben Rechner unproblematisch, über ein fremdes Netz aber nicht. Wie das funktioniert, steht in Was ist ein Reverse Proxy?.

Macht HTTPS eine Website langsamer?

Früher war das ein ernsthaftes Argument gegen HTTPS. Heute nicht mehr. Wir haben fünfmal hintereinander gemessen, wie lange der Verbindungsaufbau zu getmind.io dauert:

curl -s -o /dev/null -w "%{time_connect} %{time_appconnect}\n" https://getmind.io/

# TCP verbunden   TLS fertig
0,0015 s          0,0188 s
0,0014 s          0,0195 s
0,0013 s          0,0186 s
0,0012 s          0,0192 s

Die TCP-Verbindung steht nach gut einer Millisekunde, der TLS-Handshake ist rund 17 bis 18 Millisekunden später fertig. (Der allererste Lauf brauchte wegen der DNS-Abfrage 170 ms extra, das hat mit HTTPS nichts zu tun.) Zum Vergleich: Ein einziges Bild auf einer typischen Website zu laden dauert länger.

Dazu kommt, dass HTTPS Websites in der Praxis oft schneller macht, nicht langsamer. Alle Browser unterstützen HTTP/2 und HTTP/3 nur über verschlüsselte Verbindungen. Diese neueren Versionen laden viele Dateien gleichzeitig über eine Verbindung statt nacheinander. Unser Server kündigt HTTP/3 aktiv an:

HTTP/2 200
alt-svc: h3=":443"; ma=2592000
server: Caddy

Wer bei HTTP/1.1 bleibt, um sich HTTPS zu sparen, verliert also mehr Zeit, als er gewinnt. Auch die Rechenlast auf dem Server ist bei modernen CPUs mit AES-Beschleunigung kaum noch messbar.

Ist HTTPS Pflicht?

Ein Gesetz, das wörtlich „HTTPS” vorschreibt, gibt es in Deutschland nicht. In der Praxis kommst du trotzdem nicht darum herum:

• DSGVO Art. 32 verlangt „geeignete technische Maßnahmen” zum Schutz personenbezogener Daten. Sobald deine Seite ein Kontaktformular, einen Login, einen Newsletter oder einen Shop hat, werden personenbezogene Daten übertragen. Datenschutzbehörden sehen unverschlüsselte Formulare seit Jahren als Verstoß an, und es gab dafür bereits Bußgelder.
• Browser markieren HTTP-Seiten als „Nicht sicher”. Chrome warnt bei Formularen auf HTTP-Seiten noch deutlicher. Viele Besucher brechen an dieser Stelle ab.
• Google nutzt HTTPS seit 2014 als (kleines) Ranking-Signal.
• Zahlungsanbieter wie Stripe oder PayPal und der Kartenstandard PCI DSS setzen verschlüsselte Verbindungen voraus.

Kurz: Für jede Website, die irgendetwas mit Nutzerdaten macht, ist HTTPS faktisch Pflicht. Für alle anderen ist es Standard, und es gibt keinen guten Grund mehr, darauf zu verzichten. Laut Googles Transparenzbericht laufen in Chrome inzwischen weit über 90 Prozent aller Seitenaufrufe über HTTPS.

HTTPS auf dem eigenen Server einrichten

Die gute Nachricht: Das ist heute weder teuer noch kompliziert. Es gibt zwei gängige Wege.

Weg 1: Ein Webserver, der es automatisch macht

Unser Webserver Caddy holt Zertifikate von Let’s Encrypt komplett selbstständig, sobald eine Domain in der Konfiguration steht. Die Konfiguration für eine Seite ist buchstäblich drei Zeilen lang:

getmind.io {
    root * /var/www/getmind
    file_server
}

Caddy beantragt beim ersten Aufruf ein Zertifikat, leitet HTTP automatisch auf HTTPS um und erneuert das Zertifikat rechtzeitig vor Ablauf, ohne dass du etwas tun musst. So verwaltet unser Server aktuell 1.042 Zertifikate. Wir haben kein einziges davon von Hand angefasst.

Weg 2: nginx oder Apache mit certbot

Wer nginx oder Apache nutzt, greift meist zu certbot, dem offiziellen Werkzeug von Let’s Encrypt:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

certbot prüft, dass du die Domain kontrollierst, holt das Zertifikat, trägt es in die nginx-Konfiguration ein und richtet einen Timer für die automatische Erneuerung ein. Ob die Erneuerung klappt, testest du mit:

sudo certbot renew --dry-run

Wie man nginx grundsätzlich als Reverse Proxy mit HTTPS aufsetzt, steht in unserem Artikel nginx Reverse Proxy. Wenn du noch überlegst, welcher Webserver zu dir passt, hilft Apache vs. nginx.

Die Falle, in die wir selbst getreten sind

Zertifikate von Let’s Encrypt laufen nach 90 Tagen ab. Das ist Absicht: Kurze Laufzeiten zwingen zur Automatisierung, und ein gestohlener Schlüssel ist nicht jahrelang nutzbar. Die Branche geht sogar weiter. Die Browser-Hersteller und Zertifizierungsstellen haben 2025 beschlossen, die maximale Laufzeit schrittweise bis 2029 auf 47 Tage zu senken.

Das heißt aber auch: Ein Zertifikat ohne funktionierende Erneuerung ist eine Zeitbombe mit 90-Tage-Zünder. Genau das ist uns passiert. Bei einem Serverumzug wurde für eine Website das Zertifikat als Datei auf den neuen Server kopiert. Die Seite lief, das Schloss war grün, alles sah gut aus. Was nicht mitkam, war die Erneuerungskonfiguration. Drei Monate später lief das Zertifikat ab, und die Seite war einige Stunden lang nicht erreichbar, bis es neu ausgestellt war.

Die Lehre daraus, die wir seitdem bei jedem Umzug befolgen:

1. Zertifikate nie nur kopieren. Entweder auf dem neuen Server neu ausstellen lassen oder das komplette Verzeichnis /etc/letsencrypt inklusive renewal/*.conf mitnehmen.
2. Direkt nach dem Umzug certbot renew --dry-run laufen lassen. Das ist der einzige Beweis, dass die nächste Erneuerung klappt.
3. Das Ablaufdatum notieren und überwachen. Ein grünes Schloss heute sagt nichts über das Schloss in drei Monaten.

Ein einfacher Check, den du per Cronjob laufen lassen kannst:

# Tage bis zum Ablauf
end=$(echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
echo $(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 )) Tage

Bei unserem getmind.io-Zertifikat liefert das zum Zeitpunkt dieses Artikels gut 35 Tage. Caddy erneuert ab einem Drittel Restlaufzeit, also in den nächsten Tagen. Wie man solche Prüfungen regelmäßig ausführt, zeigt unser Artikel Cronjob erstellen.

HTTP auf HTTPS umleiten

Wer HTTPS hat, sollte HTTP nicht einfach abschalten, sondern umleiten. Sonst landen Besucher, die die Adresse ohne https:// eintippen, auf einer Fehlerseite. Unser Server antwortet auf HTTP so:

HTTP/1.1 308 Permanent Redirect
Location: https://getmind.io/
Server: Caddy

Der Code 308 (oder 301) sagt dem Browser und Google: Die Seite ist dauerhaft umgezogen. Bei nginx sieht die entsprechende Regel so aus:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HSTS: Der Schritt, den viele vergessen

Erinnerst du dich an das Detail aus unserem Mitschnitt? Die Umleitung von HTTP auf HTTPS kam zu spät. Die erste Anfrage ging unverschlüsselt raus, inklusive Passwort in der Adresse. Ein Angreifer im selben Netz könnte genau diese erste Anfrage abfangen und den Besucher gar nicht erst zu HTTPS weiterleiten lassen. Das nennt man SSL-Stripping.

Die Gegenmaßnahme heißt HSTS (HTTP Strict Transport Security). Dabei schickt der Server eine Kopfzeile mit, die dem Browser sagt: „Sprich mit mir in Zukunft nur noch über HTTPS, egal was eingetippt wird.” Ab dem zweiten Besuch geht dann keine einzige unverschlüsselte Anfrage mehr raus. So sieht die Kopfzeile bei GitHub aus:

strict-transport-security: max-age=31536000; includeSubdomains; preload

Und jetzt der ehrliche Teil: Bei getmind.io fehlt diese Kopfzeile. Wir haben es beim Schreiben dieses Artikels gemessen (curl -sI https://getmind.io/ | grep -i strict → kein Treffer). Caddy erledigt Zertifikate und Umleitung automatisch, HSTS aber nicht. Das muss man selbst eintragen:

getmind.io {
    header Strict-Transport-Security "max-age=31536000; includeSubDomains"
    ...
}

Das steht jetzt auf unserer Liste. Wichtig vorher, auch für uns: HSTS ist schwer rückgängig zu machen. Wer max-age auf ein Jahr setzt und danach eine Subdomain ohne HTTPS betreibt, sperrt Besucher für ein Jahr aus. Fang deshalb mit kurzen Werten an (etwa max-age=300), prüfe alle Subdomains und erhöhe erst dann. Den Zusatz preload (Aufnahme in eine fest in Browser eingebaute Liste) solltest du erst nehmen, wenn du dir ganz sicher bist.

Häufige HTTPS-Fehler und was sie bedeuten

„Ihre Verbindung ist nicht privat” / NET::ERR_CERT_DATE_INVALID. Das Zertifikat ist abgelaufen, oder die Uhr auf deinem Gerät geht falsch. Als Besucher: Uhrzeit prüfen. Als Betreiber: Erneuerung reparieren, siehe oben.

NET::ERR_CERT_COMMON_NAME_INVALID. Das Zertifikat gilt für einen anderen Namen. Typischer Fall: Es wurde nur für example.com ausgestellt, aufgerufen wird www.example.com. Lösung: Beide Namen ins Zertifikat aufnehmen.

NET::ERR_CERT_AUTHORITY_INVALID. Die Kette endet nicht bei einem bekannten Stammzertifikat. Entweder ist das Zertifikat selbst signiert, oder der Server liefert die Zwischenzertifikate nicht mit. Bei nginx muss in ssl_certificate die Datei fullchain.pem stehen, nicht cert.pem. Diesen Fehler sehen wir in Foren ständig.

Gemischte Inhalte (Mixed Content). Die Seite selbst kommt per HTTPS, lädt aber Bilder oder Skripte per http://. Browser blockieren unsichere Skripte dann komplett, und das Schloss verschwindet. Lösung: Alle internen Links auf https:// oder relative Pfade umstellen. Bei WordPress hilft ein Suchen-und-Ersetzen in der Datenbank.

Weiterleitungsschleife. Typisch hinter Cloudflare oder einem anderen Proxy: Der Proxy spricht per HTTP mit deinem Server, der Server leitet auf HTTPS um, der Proxy ruft wieder per HTTP an. Lösung: Beim Proxy den Modus „Full (strict)” wählen, damit er auch nach hinten verschlüsselt spricht.

Häufige Fragen

Was ist HTTPS einfach erklärt?

HTTPS ist die verschlüsselte Version von HTTP, der Sprache, in der dein Browser Webseiten abruft. Alles, was zwischen dir und der Website hin und her geht, wird so verpackt, dass unterwegs niemand mitlesen oder etwas verändern kann. Ein Zertifikat stellt außerdem sicher, dass du wirklich mit der Website sprichst, die du aufgerufen hast.

Was ist der Unterschied zwischen HTTP und HTTPS?

HTTP überträgt alles im Klartext, HTTPS verschlüsselt die Daten mit TLS. In unserem Test stand ein Passwort per HTTP dreimal lesbar im Netzwerkmitschnitt, per HTTPS kein einziges Mal. Dazu kommt bei HTTPS die Prüfung der Server-Identität per Zertifikat. HTTP nutzt Port 80, HTTPS Port 443.

Was ist der Unterschied zwischen SSL und TLS?

SSL ist der alte Name, TLS der aktuelle. SSL 2.0 und 3.0 sind seit Jahren unsicher und abgeschaltet. Was heute als „SSL-Zertifikat” verkauft wird, ist in Wahrheit ein Zertifikat für TLS. Der Begriff SSL hat sich im Sprachgebrauch einfach gehalten. Aktuell sind TLS 1.2 und TLS 1.3.

Ist eine Seite mit HTTPS automatisch sicher?

Nein. HTTPS sichert nur die Verbindung. Auch Betrugsseiten haben fast immer ein gültiges Zertifikat, weil es kostenlos ist. Das Schloss sagt dir, dass niemand mitliest, nicht, dass die Seite vertrauenswürdig ist. Achte immer zusätzlich auf die genaue Domain in der Adresszeile.

Was kostet ein SSL-Zertifikat?

Ein Zertifikat, das deine Domain bestätigt (DV), bekommst du von Let’s Encrypt oder ZeroSSL kostenlos. Für die Verschlüsselung ist es genauso gut wie ein gekauftes. Organisations- oder EV-Zertifikate kosten zwischen etwa 50 und 500 Euro im Jahr und prüfen zusätzlich die Firma, bringen Besuchern aber seit 2019 kaum noch sichtbare Vorteile.

Woran erkenne ich, ob eine Seite HTTPS nutzt?

Die Adresse beginnt mit https://. Je nach Browser siehst du ein Schloss oder ein neutrales Einstellungssymbol, bei HTTP dagegen den Hinweis „Nicht sicher”. Mit einem Klick auf das Symbol kannst du dir das Zertifikat ansehen: für welche Domain es gilt, wer es ausgestellt hat und bis wann.

Kann mein Internetanbieter sehen, welche Seiten ich besuche?

Welche Domain du aufrufst, meistens ja, über den Namen im TLS-Handshake (SNI) und über die DNS-Abfrage. Welche Unterseite, was du suchst, was du eintippst und was die Seite anzeigt, nein. Das ist alles verschlüsselt. Mehr Privatsphäre bringen verschlüsseltes DNS und, sobald verbreitet, Encrypted Client Hello.

Ist HTTPS Pflicht für meine Website?

Ein Gesetz mit dem Wort HTTPS gibt es nicht. Sobald deine Seite aber Formulare, Logins oder einen Shop hat, verlangt die DSGVO eine sichere Übertragung, und das heißt in der Praxis HTTPS. Unabhängig davon warnen Browser vor HTTP-Seiten, und Google bevorzugt HTTPS leicht im Ranking.

Macht HTTPS meine Website langsamer?

Kaum messbar. Bei uns dauert der TLS-Handshake rund 17 Millisekunden. Weil HTTP/2 und HTTP/3 nur über HTTPS funktionieren, wird eine Seite insgesamt oft sogar schneller.

Wie lange ist ein HTTPS-Zertifikat gültig?

Let’s-Encrypt-Zertifikate gelten 90 Tage und werden automatisch erneuert. Gekaufte Zertifikate gelten derzeit höchstens rund ein Jahr. Die Maximallaufzeit sinkt nach einem Branchenbeschluss von 2025 bis 2029 schrittweise auf 47 Tage. Automatische Erneuerung ist damit nicht mehr optional.

Fazit: Was ist HTTPS, und was solltest du tun?

HTTPS ist das unsichtbare Fundament fast jeder Website. Es verschlüsselt die Verbindung, verhindert unbemerkte Veränderungen und stellt sicher, dass du mit dem richtigen Server sprichst. Unser Mitschnitt zeigt den Unterschied ganz nüchtern: dreimal Passwort im Klartext gegen null. Der Preis dafür sind rund 17 Millisekunden und, dank Let’s Encrypt, null Euro.

Wenn du Besucher bist: Achte auf https://, aber verlass dich nicht blind auf das Schloss. Es schützt die Leitung, nicht vor Betrügern.

Wenn du eine Website betreibst:

1. HTTPS einrichten, am einfachsten mit Caddy oder certbot.
2. HTTP dauerhaft auf HTTPS umleiten (301 oder 308).
3. Die automatische Erneuerung testen, nicht nur annehmen. Und bei jedem Serverumzug erneut testen.
4. HSTS setzen, mit kurzem max-age anfangen.
5. TLS 1.0 und 1.1 abschalten, falls dein Server sie noch anbietet.

Wir selbst haben beim Schreiben dieses Artikels gelernt, dass auch bei uns ein Punkt fehlte: HSTS. Das ist vielleicht die wichtigste Erkenntnis von allen. Ein grünes Schloss fühlt sich fertig an, ist es aber nicht immer. Wer seinen Server Schritt für Schritt absichern will, findet in Linux Server einrichten und UFW Firewall einrichten die nächsten Schritte.