grill-it
Goto Top

Http https Problem bei Interner Seite

Hallo zusammen,

bei uns wird intern eine Webseite betrieben.
Wenn ich diese mit Chrome oder FireFox über http://<fqdn>:8080 aufrufe schwenken die Browser automatisch auf https um.
Dies ist so aber nicht gewünscht.

Da kein Zertifikat vorhanden ist, bringen natürlich die Browser entsprechende Sicherheitswarnungen.

Chrome bspw. meckert, dass der Server eine ungültige Antwort zurück liefert und man die Windowsnetzwerk Diagnose bemühen soll...
Schaut man sich die Security Informationen an, behauptet er allerdings dass alles Sicher sei, das Zertifikat passt (welches auch immer er da angeblich nimmt, anzeigen ist nicht möglich), aber die Seite ist nicht sicher..

Jemand eine Idee wie ich den Browsern das abgewöhnt bekomme da zu meckern?

oder ist der Schnellste/einfachste Weg, dem Apache ein Zertifikat für die Webseite zu verpassen?
zu letzerem: Wenn ja, wie funktioniert das am besten bei einem Apache der auf Windows betrieben wird? habe hinsichtlich Apache nicht sooo die Erfahrung....

Danke schonmal,

Gruß, Manu

Ergänzung: Das ganze tritt nur sporadisch auf. wenn man statt dem FQDN die IP des Servers mit port ruft, funktioniert das ganze.

Content-ID: 357427

Url: https://administrator.de/contentid/357427

Ausgedruckt am: 22.11.2024 um 04:11 Uhr

IrunGoldstein
IrunGoldstein 08.12.2017 um 11:52:08 Uhr
Goto Top
Hi Grill-It,

hört sich ganz nach einer automatischen Weiterleitung aus, entweder in einem VHost des Apache oder in einer .htaccess Datei im Wurzelverzeichnis der Webseite.

Falls es einen VHost gibt wovon ich mal ausgehe sollte darin etwas wie:


RewriteEngine On # This will enable the Rewrite capabilities 
RewriteCond %{HTTPS} !=on # This checks to make sure the connection is not already HTTPS
 RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L] # This rule will redirect users from their original location, to the same location but using HTTPS. # i.e. http://www.example.com/foo/ to https://www.example.com/foo/ # The leading slash is made optional so that this will work either in httpd.conf # or .htaccess context

Wie zu sehen greift dann die RewriteEngine, wenn nicht gewünscht wieder rausnehmen und "Standard" konfigurieren.

Falls doch eigenes Zertifikat dann aufnehmen in die jeweiligen trust stores der Anwendungen, nicht alle greifen auf das Systemeigene zu.

Falls externes gewünscht und somit gültiges Zertifikat dann wäre LetsEncrypt eine Möglichkeit. Geht aber nur auf korrekte FDQN.

Zum letzten Punkt das es mit der IP funktioniert ist klar,da auf dem weg höchstwahrscheinlich die "default VHost" datei angesprochen wird und keine Umleitung zu https stattfindet und dort auch kein weiterer VHost eine Verschlüsselung anbietet.

Checke einfach mal die Konfigurationen falls dann noch konkrete fragen sind gerne nochmals melden face-smile

Nutze keine Windows Systeme von daher kann ich nichts zu den Speicher Pfaden sagen aber sollte sich schnell rausfinden lass wo die unter WIN liegen.

Grüße
134464
134464 08.12.2017 aktualisiert um 12:33:02 Uhr
Goto Top
Alternativ den Webserver einfach nicht mehr auf Port 443 schnüffeln lassen face-smile wenn man das sowieso nicht nutzen will (aber besser sollte wenn sensible Daten über die Leitung gehen, in dem Fall vertrauenswürdiges Zertifikat mit richtigen Common-Name hinterlegen).
grill-it
grill-it 11.12.2017 um 13:27:22 Uhr
Goto Top
Zitat von @IrunGoldstein:

Hi Grill-It,

hört sich ganz nach einer automatischen Weiterleitung aus, entweder in einem VHost des Apache oder in einer .htaccess Datei im Wurzelverzeichnis der Webseite.

das vermute ich auch. kann aber nichts derartiges finden

Falls es einen VHost gibt wovon ich mal ausgehe sollte darin etwas wie:

die vhostdatei ist, in meinen augen Standardmäßig konfiguriert

> 
> RewriteEngine On # This will enable the Rewrite capabilities 
> RewriteCond %{HTTPS} !=on # This checks to make sure the connection is not already HTTPS
>  RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L] # This rule will redirect users from their original location, to the same location but using HTTPS. # i.e. http://www.example.com/foo/ to https://www.example.com/foo/ # The leading slash is made optional so that this will work either in httpd.conf # or .htaccess context

Wie zu sehen greift dann die RewriteEngine, wenn nicht gewünscht wieder rausnehmen und "Standard" konfigurieren.

in der htacess habe ich einen Eintrag bzgl. Rewriteeintrag gefinden, der Sieht wie folgt aus:

 <IfModule mod_rewrite.c>
        SetEnv HTTP_MOD_REWRITE On

        #CGI mode PHP auth fix
        SetEnvIfNoCase Authorization "Basic ([a-z0-9=]+)" US_HTTP_AUTHORIZATION=$1  

        RewriteEngine On
        #RewriteBase /

        #Checks to see if the user is attempting to access a valid file,
        #such as an image or css document, if this isn't true it sends the 
        #request to index_us.php
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^(.*)$ index_us.php?/$1 [PT,L]



Falls doch eigenes Zertifikat dann aufnehmen in die jeweiligen trust stores der Anwendungen, nicht alle greifen auf das Systemeigene zu.


Das werde ich nochmals prüfen.

Danke schonmal.


Zitat von @134464:

Alternativ den Webserver einfach nicht mehr auf Port 443 schnüffeln lassen face-smile wenn man das sowieso nicht nutzen will (aber besser sollte wenn sensible Daten über die Leitung gehen, in dem Fall vertrauenswürdiges Zertifikat mit richtigen Common-Name hinterlegen).

Danke.. Das teste ich mal. Nehme an der Apache braucht aber dafür einen Neustart des Dienstes, richtig?

Gruß, Manu
grill-it
grill-it 14.12.2017 um 16:17:06 Uhr
Goto Top
noch was, interessanter Weise Tritt die Problematik nicht flächendeckend an allen Clients auf.
Manche können die Webseite ganz normal aufrufen.