Ihr lokales CMS ist nicht erreichbar, weil Edge ungefragt http durch https ersetzt? So lösen Sie das

Kennen Sie das Gefühl? Sie sitzen an Ihrem Rechner, die Entwicklung läuft auf Hochtouren, Ihr lokales CMS oder Ihre Webanwendung ist bereit zur Ansicht – doch anstatt der erwarteten Benutzeroberfläche präsentiert Ihnen Ihr Browser, genauer gesagt Microsoft Edge, eine unschöne Fehlermeldung. Meistens ist es ein „Seite nicht erreichbar“ oder gar ein „ERR_SSL_PROTOCOL_ERROR“. Was ist passiert? Der Verdacht liegt nahe: Edge hat ungefragt versucht, Ihre HTTP-Anfrage auf HTTPS umzuleiten, und Ihr lokaler Server war darauf nicht vorbereitet. Ein frustrierendes Szenario, das die Produktivität empfindlich stören kann. Aber keine Sorge, Sie sind nicht allein mit diesem Problem, und noch wichtiger: Es gibt Lösungen!

In diesem umfassenden Artikel tauchen wir tief in die Materie ein. Wir erklären, warum moderne Browser wie Edge diese automatische Umwandlung vornehmen, identifizieren die genauen Ursachen für den Fehler und präsentieren Ihnen detaillierte, praxiserprobte Schritte zur Fehlerbehebung. Von schnellen Workarounds bis hin zu dauerhaften, sicheren Lösungen – wir decken alles ab, damit Ihr lokales CMS wieder reibungslos erreichbar ist.

Das Problem verstehen: Warum Edge (und andere Browser) HTTP zu HTTPS umwandeln

Bevor wir uns den Lösungen widmen, ist es wichtig zu verstehen, warum Browser überhaupt so handeln. Die automatische Umstellung von HTTP zu HTTPS ist eine Reaktion auf das wachsende Bedürfnis nach Sicherheit im Web. HTTPS (Hypertext Transfer Protocol Secure) ist die sichere Variante von HTTP und verwendet SSL/TLS-Verschlüsselung, um die Kommunikation zwischen Ihrem Browser und einem Server zu schützen. Dies verhindert das Abhören von Daten, Manipulationen oder Identitätsdiebstahl.

Moderne Browser wie Chrome, Firefox und eben auch Edge haben daher Funktionen implementiert, die darauf abzielen, Benutzer automatisch zu sicheren Verbindungen zu leiten. Edge verfügt beispielsweise über einen „HTTPS-Only Modus„, der – wenn aktiviert – versucht, jede nicht-verschlüsselte HTTP-Anfrage auf eine HTTPS-Verbindung umzuleiten. Für öffentliche Websites, die HTTPS unterstützen, ist das hervorragend und erhöht die Sicherheit der Nutzer. Für Ihre lokale Entwicklungsumgebung, die oft aus Gründen der Einfachheit oder aufgrund fehlender Notwendigkeit auf unverschlüsseltem HTTP läuft, wird dies jedoch schnell zum Hindernis.

Die genaue Ursache: Ihr lokales CMS ist nicht für HTTPS konfiguriert

Der Kern des Problems liegt darin, dass Ihr lokaler Webserver, der Ihr CMS hostet (sei es Apache, Nginx, ein eingebauter PHP-Server oder Node.js), nicht für die Bereitstellung von Inhalten über HTTPS konfiguriert ist. Wenn Edge versucht, eine Verbindung über HTTPS zu Ihrem lokalen Server herzustellen, erwartet es ein gültiges SSL/TLS-Zertifikat. Da Ihr lokaler Server jedoch nur auf HTTP lauscht oder kein passendes Zertifikat besitzt, schlägt die Verbindung fehl. Der Browser kann keine sichere Verbindung aufbauen und meldet einen Fehler, anstatt die Seite anzuzeigen.

Die Fehlermeldung kann variieren, aber typisch sind:

• ERR_SSL_PROTOCOL_ERROR
• NET::ERR_CERT_INVALID
• Verbindung fehlgeschlagen: Fehlercode -SSL_ERROR_RX_RECORD_TOO_LONG
• Dieser Standort kann keine sichere Verbindung bereitstellen

Diese Meldungen deuten alle darauf hin, dass der Browser versucht hat, eine sichere Verbindung aufzubauen, aber daran gescheitert ist, weil der Server entweder kein SSL/TLS-Zertifikat angeboten hat oder ein ungültiges bzw. nicht vertrauenswürdiges Zertifikat präsentiert hat.

Erste Hilfe bei akuter Frustration: Schnelle Lösungsansätze

Bevor wir uns den dauerhaften Lösungen widmen, gibt es ein paar schnelle Tricks, die Sie ausprobieren können, wenn Sie sofortigen Zugriff benötigen und keine Zeit für eine detaillierte Konfiguration haben:

1. Die explizite HTTP-Eingabe (und Schnelligkeit)

   Manchmal hilft es, die Adresse wirklich explizit mit http:// zu beginnen und dann schnell die Enter-Taste zu drücken. Gelegentlich überschreibt der Browser dies nicht sofort, insbesondere wenn es eine neu eingegebene Adresse ist. Bei Adressen, die Sie schon oft aufgerufen haben, kann der Browser allerdings eine Historie haben und trotzdem versuchen, auf HTTPS umzuleiten.

2. Einen anderen Browser verwenden

   Auch wenn Chrome und Firefox ähnliche Sicherheitsmechanismen haben, ist es möglich, dass die Standardeinstellungen oder das Cachingverhalten eines anderen Browsers noch keine automatische Umleitung erzwingen. Dies ist natürlich keine dauerhafte Lösung, aber eine schnelle temporäre Abhilfe, um Ihre Arbeit fortzusetzen.

3. Browser-Cache und Verlauf löschen

   Manchmal speichert der Browser die Information, dass eine Seite über HTTPS aufgerufen werden sollte, im Cache (HSTS – HTTP Strict Transport Security). Das Löschen des Browser-Caches, insbesondere der Website-Daten und des Verlaufs, kann in manchen Fällen helfen, diese „Erinnerung“ zu löschen. Gehen Sie in Edge zu Einstellungen > Datenschutz, Suche und Dienste > Browserdaten löschen und wählen Sie dort entsprechende Optionen aus.

Die dauerhafte Lösung 1: Edge konfigurieren und den HTTPS-Only Modus deaktivieren

Die wohl direkteste und oft ausreichendste Lösung für das Problem in der Entwicklungsumgebung ist die Anpassung der Einstellungen in Microsoft Edge. Sie können den „HTTPS-Only Modus” deaktivieren oder Ausnahmen für Ihre lokalen Adressen definieren.

Schritt-für-Schritt-Anleitung in Edge:

1. Edge-Einstellungen öffnen

   Öffnen Sie Microsoft Edge und klicken Sie auf die drei Punkte (...) in der oberen rechten Ecke des Browserfensters. Wählen Sie dann „Einstellungen” aus dem Dropdown-Menü.

2. Zum Datenschutz-Bereich navigieren

   In den Einstellungen navigieren Sie im linken Menü zu „Datenschutz, Suche und Dienste”.

3. Den HTTPS-Only Modus finden

   Scrollen Sie nach unten, bis Sie den Abschnitt „Sicherheit” finden. Dort sehen Sie die Option „Immer sichere Verbindungen verwenden” (oder ähnlich formuliert, dies ist der HTTPS-Only Modus).

   • Option A: Deaktivierung für alle Seiten (Nicht empfohlen für öffentliche Webseiten)
     Wenn Sie diese Einstellung einfach deaktivieren, wird Edge nicht mehr versuchen, alle HTTP-Anfragen automatisch auf HTTPS umzuleiten. Dies löst Ihr Problem für alle lokalen Projekte, kann aber potenziell die Sicherheit beim Surfen auf öffentlichen Webseiten mindern, die zwar HTTPS anbieten, aber auch HTTP-Verbindungen zulassen. Für eine dedizierte Entwicklungsumgebung, die streng von normalen Browser-Aktivitäten getrennt ist, mag dies akzeptabel sein, ansonsten ist Vorsicht geboten.
   • Option B: Ausnahmen hinzufügen (Empfohlen für gezielte Lösungen)
     Ist „Immer sichere Verbindungen verwenden” aktiviert, suchen Sie darunter nach einer Option wie „Ausnahmen” oder „Liste der Websites, die keine HTTPS-Verbindungen verwenden”. Hier können Sie die spezifischen Adressen Ihres lokalen CMS hinzufügen. Typische Adressen könnten sein:
     • localhost
     • 127.0.0.1
     • 192.168.1.100 (ersetzen Sie dies durch die tatsächliche IP Ihres lokalen Servers)
     • meinedomain.local (wenn Sie eine lokale Domain verwenden)

     Klicken Sie auf „Hinzufügen” und geben Sie die URL ohne das http:// Präfix ein (z.B. nur localhost oder 192.168.1.100). Edge sollte diese Domains dann als Ausnahmen behandeln und nicht versuchen, sie auf HTTPS umzuleiten.

Nachdem Sie diese Änderungen vorgenommen haben, starten Sie Edge am besten einmal neu und versuchen Sie erneut, auf Ihr lokales CMS zuzugreifen. Das Problem sollte behoben sein.

Die dauerhafte Lösung 2: Ihr lokales CMS auf HTTPS umstellen

Während die Deaktivierung des HTTPS-Only Modus in Edge das unmittelbare Problem löst, ist die eleganteste und sicherste Langzeitlösung, Ihr lokales CMS oder Ihre Entwicklungsumgebung selbst für HTTPS zu konfigurieren. Dies bietet mehrere Vorteile:

• Sicherheit: Auch lokal entwickeln Sie sicherer.
• Realitätsnahe Entwicklung: Sie arbeiten unter Bedingungen, die näher an der Produktionsumgebung liegen. Moderne Web-APIs (wie Geolocation, Service Workers etc.) funktionieren oft nur unter HTTPS.
• Keine Browser-Probleme: Sie vermeiden zukünftige Konflikte mit Browser-Sicherheitsfunktionen.

Der Prozess umfasst im Wesentlichen drei Schritte: das Generieren von selbstsignierten Zertifikaten, die Konfiguration Ihres Webservers und das Vertrautmachen Ihres Browsers mit diesen Zertifikaten.

Schritt 1: Selbstsignierte Zertifikate generieren

Ein selbstsigniertes Zertifikat ist ein SSL/TLS-Zertifikat, das nicht von einer offiziellen Zertifizierungsstelle (CA) ausgestellt, sondern von Ihnen selbst erstellt und signiert wurde. Für die lokale Entwicklung ist dies völlig ausreichend. Tools wie OpenSSL sind ideal dafür geeignet.

Beispiel mit OpenSSL (Linux/macOS, auch unter Windows mit Git Bash oder WSL verfügbar):

1. Privaten Schlüssel generieren:

   openssl genrsa -out localhost.key 2048

2. Zertifikatsignieranforderung (CSR) erstellen:

   openssl req -new -key localhost.key -out localhost.csr

   Hier werden Sie nach Informationen wie Land, Ort, Organisation gefragt. Wichtig ist bei „Common Name (e.g. server FQDN or YOUR name) []:”, dass Sie hier localhost oder die IP-Adresse Ihres lokalen Servers eingeben, für die das Zertifikat gelten soll.

3. Das selbstsignierte Zertifikat erstellen:

   openssl x509 -req -days 365 -in localhost.csr -signkey localhost.key -out localhost.crt

   Dieses Zertifikat ist dann 365 Tage gültig.

Für eine bequemere Lösung unter Windows gibt es auch Tools wie mkcert, die automatisch lokale CAs erstellen und Zertifikate generieren, die von den Browsern vertraut werden.

Schritt 2: Webserver für HTTPS konfigurieren

Nachdem Sie Ihre Schlüssel und Zertifikate haben, müssen Sie Ihren Webserver anweisen, diese zu verwenden.

Beispiel für Apache:

Stellen Sie sicher, dass das mod_ssl-Modul aktiviert ist. Fügen Sie dann in Ihrer httpd-vhosts.conf oder der spezifischen Konfigurationsdatei für Ihr lokales CMS einen VirtualHost-Block für Port 443 hinzu:

<VirtualHost *:443>
    DocumentRoot "C:/path/to/your/cms"
    ServerName localhost

    SSLEngine on
    SSLCertificateFile "C:/path/to/your/certs/localhost.crt"
    SSLCertificateKeyFile "C:/path/to/your/certs/localhost.key"

    <Directory "C:/path/to/your/cms">
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Denken Sie daran, die Pfade anzupassen und Apache neu zu starten.

Beispiel für Nginx:

In Ihrer Nginx-Konfiguration (oft nginx.conf oder in sites-enabled):

server {
    listen 443 ssl;
    server_name localhost;

    ssl_certificate /path/to/your/certs/localhost.crt;
    ssl_certificate_key /path/to/your/certs/localhost.key;

    root /path/to/your/cms;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }

    # PHP-FPM Konfiguration, falls PHP verwendet wird
    location ~ .php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock; # Pfad anpassen
    }
}

Anschließend Nginx neu laden oder neu starten.

Beispiel für Node.js (Express):

const express = require('express');
const https = require('https');
const fs = require('fs');

const app = express();

const options = {
  key: fs.readFileSync('/path/to/your/certs/localhost.key'),
  cert: fs.readFileSync('/path/to/your/certs/localhost.crt')
};

app.get('/', (req, res) => {
  res.send('Hello HTTPS!');
});

https.createServer(options, app).listen(3000, () => {
  console.log('HTTPS Server running on port 3000');
});

Schritt 3: Das selbstsignierte Zertifikat im Browser vertrauen

Da Ihr Zertifikat selbstsigniert ist, wird der Browser es standardmäßig nicht vertrauen und weiterhin eine Warnung anzeigen (z.B. „Ihre Verbindung ist nicht privat”). Um dies zu beheben, müssen Sie das localhost.crt-Zertifikat in den Zertifikatsspeicher Ihres Betriebssystems (und damit auch für Edge) importieren.

Unter Windows:

1. Doppelklicken Sie auf die localhost.crt-Datei.
2. Klicken Sie auf „Zertifikat installieren…”.
3. Wählen Sie „Aktueller Benutzer” oder „Lokaler Computer” (erfordert Admin-Rechte).
4. Wählen Sie „Alle Zertifikate in folgendem Speicher speichern” und klicken Sie auf „Durchsuchen…”.
5. Wählen Sie „Vertrauenswürdige Stammzertifizierungsstellen” aus.
6. Folgen Sie den Anweisungen, um die Installation abzuschließen.

Nach diesem Schritt sollte Edge Ihr lokales Zertifikat als vertrauenswürdig einstufen, und Sie können Ihr CMS über https://localhost oder die entsprechende IP-Adresse ohne Warnungen aufrufen.

Weitere nützliche Tipps und Tricks

• `hosts`-Datei für lokale Domain-Namen

  Wenn Sie Ihre Entwicklungsumgebung unter einem ansprechenden Domain-Namen wie mein-cms.local statt localhost oder einer IP-Adresse aufrufen möchten, können Sie die hosts-Datei Ihres Betriebssystems anpassen:

  • Windows: C:WindowsSystem32driversetchosts
  • Linux/macOS: /etc/hosts

  Fügen Sie eine Zeile hinzu wie: 127.0.0.1 mein-cms.local. Danach können Sie Ihr CMS unter http://mein-cms.local (oder https://mein-cms.local, wenn Sie SSL eingerichtet haben und das Zertifikat dafür ausgestellt wurde) aufrufen.

• Entwickler-Tools von Edge nutzen

  Wenn Sie weiterhin Probleme haben, öffnen Sie die Entwickler-Tools in Edge (F12). Wechseln Sie zum Tab „Netzwerk”. Hier sehen Sie, welche Anfragen gestellt werden und welche Fehler auftreten. Dies kann Ihnen wertvolle Hinweise geben, ob die Umleitung weiterhin stattfindet, ob ein SSL-Fehler vorliegt oder ob das Problem eine andere Ursache hat.

• Überprüfen Sie Ihre Firewall

  Stellen Sie sicher, dass Ihre Firewall (egal ob Windows Firewall oder eine andere) keine Verbindungen zu den Ports 80 (HTTP) oder 443 (HTTPS) auf Ihrem lokalen Rechner blockiert.

Fazit: Beherrschen Sie Ihr lokales CMS und Edge

Es ist ärgerlich, wenn Tools, die eigentlich helfen sollen, plötzlich zum Hindernis werden. Die automatische HTTP zu HTTPS Umleitung von Edge ist ein Paradebeispiel dafür, wie gut gemeinte Sicherheitsfeatures in der Entwicklungsumgebung zu Problemen führen können. Glücklicherweise sind die Lösungen nicht allzu komplex.

Ob Sie sich für die schnelle Deaktivierung des HTTPS-Only Modus in Edge entscheiden oder den robusteren Weg wählen, Ihr lokales CMS für HTTPS zu konfigurieren – Sie haben jetzt das Wissen und die Werkzeuge, um das Problem eigenständig zu lösen. Wir empfehlen langfristig die HTTPS-Konfiguration für Ihre Entwicklungsumgebung, da sie eine realitätsnähere und sicherere Arbeitsweise ermöglicht und zukünftige Browser-Updates weniger wahrscheinlich zu neuen Problemen führen werden. Viel Erfolg bei Ihrer weiteren Entwicklung!