Klaus1: http redirect auf https erzeugt fehler?

Hallo,

mein alter Webserver hatte nur http unterstützt. Den neuen Server hatte ich in der default-server.conf direkt so konfiguriert, dass er https unterstützt.

Da viele als Startseite und Bookmark aber noch die http Adresse eingetragen haben, wollte ich jetzt auch http unterstützen und einen automatischen redirect zu https einrichten.

In der default-server.conf stehen keine VirtualHost Einträge, sondern direkt

DocumentRoot "/srv/www/htdocs"
ServerAdmin root@meinedomain.de
ServerName meinedomain.de:443

etc.

Ich habe dann die folgenden Einträge hinzugefügt:

RewriteEngine On 
RewriteCond %{HTTPS}  !=on 
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L] 

Eine Umleitung erfolgt zwar auch, aber zur URL mit Fehlermeldung:

https://meinedomain.de/error/HTTP_BAD_REQUEST.html.var

Was mache ich falsch?

LG Klaus

  1. Lieber Klaus1,

    Was mache ich falsch?

    keine Ahnung, aber bei mir sieht die Zwangsumleitung auf HTTPS [EDIT]in der .htaccess[/EDIT] so aus:

    # force https
    RewriteCond %{SERVER_PORT} !^443
    RewriteRule ^(.*)$ https://example.com/$1 [r=301,L]
    

    Liebe Grüße

    Felix Riesterer

    1. Den Eintrag in einer .htaccess hatte ich auch schon versucht. Mit demselben Fehler.

      Ich vermute, dass die RewriteRule gar nicht ausgeführt wird, denn wenn ich weder die Einträge in der default-server.conf noch in der .htaccess stehen habe, kommt derselbe Fehler.

      LG Klaus

      1. Lieber Klaus1,

        Mit demselben Fehler.

        entweder ist Dein SSL-Zertifikat nicht eingerichtet, oder das rewrite-Modul nicht verfügbar (manche shared hosting-Umgebungen haben das nicht verfügbar). Ein klarer Fall für den Support also.

        Liebe Grüße

        Felix Riesterer

        1. Hallo Felix,

          das SSL-Zertifikat ist eingerichtet, da ja der HTTPS-Zugriff einwandfrei funktioniert. Ich möchte ja nun auch den HTTP-Zugriff erlauben, aber mit Umleitung auf HTTPS. Mehr eigentlich nicht.

          Die RewriteRule dürfte theoretisch ausgeführt werden, da ja bei Eingabe von http://meinedomain.de/ eine Umleitung auf https://meinedomain.de/error/HTTP_BAD_REQUEST.html.var erfolgt. Oder kann ich das eventuell noch anders verifizieren?

          LG Klaus

          1. Hallo Klaus1,

            es hat nichts mit deinem Problem zu tun, aber für Beispieldomains gibts Beispieldomains.

            Bis demnächst
            Matthias

            --
            Pantoffeltierchen haben keine Hobbys.
            ¯\_(ツ)_/¯
            1. Ok, ich werds mit merken 😉

          2. Hallo Klaus1,

            kannst du mal eine URL bekannt geben, unter der man das prüfen kann?

            LG,
            CK

            1. Es ist ein Server, der nur intern also im Intranet verwendet wird / werden soll / werden darf.

              Daher leider keine URL zum prüfen.

              LG Klaus

          3. Gerade getestet:

            Bei der folgenden Rule

            RewriteRule ^/?(.*) https://%{SERVER_NAME}/test/$1 [R,L]
            

            Wird auch umgeleitet auf:

            https://example.com/test/error/HTTP_BAD_REQUEST.html.var
            

            Die ReWriteRule wird also ausgeführt.

            LG Klaus

  2. Hi,

    Eine Umleitung erfolgt zwar auch, aber zur URL mit Fehlermeldung:

    https://meinedomain.de/error/HTTP_BAD_REQUEST.html.var Was mache ich falsch?

    Du schaust nicht ins error.log - was steht denn da drin zu den betroffenen Requests?

    Oder im rewrite-log.

    cu,
    Andreas a/k/a MudGuard

    1. Hallo,

      im error_log steht nichts darüber. Wo würde ich denn die rewrite log finden? Im Verzeichis /var/log/apache2 finde ich nur die error_log, access_log und ssl_request_log.

      In der ssl_request_log steht:

      [02/Aug/2019:11:12:36 +0200] 10.10.10.10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "GET /error/HTTP_BAD_REQUEST.html.var HTTP/1.1" 994 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0"
      [02/Aug/2019:11:12:36 +0200] 10.10.10.10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "GET /favicon.ico HTTP/1.1" 894 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0"
      
      

      LG Klaus

  3. Hej Klaus1,

    weil ich keine Ahnung von Servern habe , ist die Frage vielleicht dumm. Trotzdem: kann es sein, dass eine dort installierte Software mit https oder http nicht klar kommt?

    In Wordpress beispielsweise hinterlegt man die URL, auf der eine Instanz läuft. Wenn man da http angibt, WP aber unter https laufen soll, hat man ein Problem…

    Marc

    --
    Ceterum censeo Google esse delendam
    1. Tach!

      weil ich keine Ahnung von Servern habe , ist die Frage vielleicht dumm. Trotzdem: kann es sein, dass eine dort installierte Software mit https oder http nicht klar kommt?

      Unwahrscheinlich, denn https:// geht laut Aussage. Nur die Umleitung bringt Fehler. Man müsste nun wissen, was beim Umschreiben rauskommt, um nachzuvollziehen, wie der Bad Request aussieht und auch wie es dazu kommt. Es gibt ein RewriteLog, dass man mal befragen sollte. Das muss sicher erst eingerichtet werden, weil man das im Normalbetrieb nicht braucht und haben möchte.

      In Wordpress beispielsweise hinterlegt man die URL, auf der eine Instanz läuft. Wenn man da http angibt, WP aber unter https laufen soll, hat man ein Problem…

      Ich empfinde das grundsätzlich als Unsitte, dass die Anwendung ihre vollständige URL wissen muss, und dann komplette URLs für Links generiert. Man bekommt solche Anwendungen nicht auf Testsysteme kopiert, ohne in der Datenbank rumzufummeln und die URL auf das Testsystem zu verbiegen. Liegt vielleicht an Anwendern, die keine Ahnung haben, wie man den Server korrekt konfiguriert und die Autoren das lieber kurzerhand in die Anwendung gezogen haben, als sich mit Supportanfragen rumzuschlagen.

      dedlfix.

      1. Hej dedlfix,

        In Wordpress beispielsweise hinterlegt man die URL, auf der eine Instanz läuft. Wenn man da http angibt, WP aber unter https laufen soll, hat man ein Problem…

        Ich empfinde das grundsätzlich als Unsitte, dass die Anwendung ihre vollständige URL wissen muss, und dann komplette URLs für Links generiert. Man bekommt solche Anwendungen nicht auf Testsysteme kopiert, ohne in der Datenbank rumzufummeln und die URL auf das Testsystem zu verbiegen. Liegt vielleicht an Anwendern, die keine Ahnung haben, wie man den Server korrekt konfiguriert und die Autoren das lieber kurzerhand in die Anwendung gezogen haben, als sich mit Supportanfragen rumzuschlagen.

        Sehe ich genauso.

        Marc

        --
        Ceterum censeo Google esse delendam
  4. Eine Umleitung erfolgt zwar auch, aber zur URL mit Fehlermeldung:

    https://meinedomain.de/error/HTTP_BAD_REQUEST.html.var

    Welcher HTTPstatus wird denn da gesendet? Und wo ist die Datei HTTP_BAD_REQUEST.html.var konfiguriert?

    MFG

  5. Hallo,

    ich habe die Ursache gefunden.

    Sobald man 2 Protokolle bedient, muss man zwingend die <VirtualHost>-Direktiven verwenden. Ich musste also meine bisherigen HTTPS-Einstellungen in eine <VirtualHost *:443> packen und die Rewrite-Regeln dann in eine <VirtualHost *:80>

    Danach hat alles wie erhofft funktioniert.

    Vielen Dank für Eure Unterstützung.

    LG Klaus

    1. Tach!

      Sobald man 2 Protokolle bedient, muss man zwingend die <VirtualHost>-Direktiven verwenden. Ich musste also meine bisherigen HTTPS-Einstellungen in eine <VirtualHost *:443> packen und die Rewrite-Regeln dann in eine <VirtualHost *:80>

      Ja klar. Das wird ja auch unterschiedlich konfiguriert. HTTPS braucht SSL-Konfigurationsdirektiven, HTTP braucht sie nicht. Die schalten sich auch nicht je nach Protokoll aktiv oder auch nicht.

      dedlfix.

    2. Hallo,

      ich habe die Ursache gefunden.

      Sobald man 2 Protokolle bedient, muss man zwingend die <VirtualHost>-Direktiven verwenden. Ich musste also meine bisherigen HTTPS-Einstellungen in eine <VirtualHost *:443> packen und die Rewrite-Regeln dann in eine <VirtualHost *:80>

      Also in meinem Apachen geht es ohne die <VirtualHost>-Direktive.
      Kann es hieran liegen?

      In sites-enabled einen Link auf sites-available setzen:
      cd /etc/apache2/sites-enabled
      ln -s ../sites-available/default-ssl.conf 001-ssl.conf

      Fred

      --
      I � Unicode
      1. Lieber Fred,

        In sites-enabled einen Link auf sites-available setzen:
        cd /etc/apache2/sites-enabled
        ln -s ../sites-available/default-ssl.conf 001-ssl.conf

        hach, waren das noch Zeiten. Ich habe das gesamte Verzeichnis sites-enabled zu einem Symlink auf sites-available gemacht. Heute nutze ich dafür a2ensite.

        Liebe Grüße

        Felix Riesterer

  6. Hi,

    Was passiert, wenn du ":443" aus dem ServerName entfernst? Die Portangabe ist dort zwar möglich, aber nicht erforderlich.

    Grüße