IE6 warnt vor unverschlüsselter Verbindung

[ragnar]

Moin,

bei mir ist folgendes Problem im Zusammenhang mit einer SSL-Verschlüsslung aufgetreten:

Logge ich mich mit dem IE6 in meinen Shop ein, kommt der Sicherheitshinweis: „Sie sind im Begriff, die Verbindung auf eine nicht sichere Verbindung umzuleiten. (...)“ Die Wanung kommt allerdings nicht bei anderen Browsern wie z.B. Firefox und Opera. Den IE7 habe ich nicht getestet, allerdings weiß ich aus Erfahrung, daß der sich sehr ähnlich zu Firefox verhält.

Nachdem man sich mit dem IE6 eingeloggt hat, ist man in der Tat noch im unverschlüsselten Bereich (kein https in der Adresszeile). Wenn ich mich aber als Admin einlogge, wechsle ich in den https bereich – und es folgt dementsprechend auch keine Warnung.

Hat jemand einen Rat, was ich falsch gemacht habe bzw. was nicht stimmt ?

Kann man den Bereich direkt nach dem einloggen auch verschlüsseln - und wenn wie?

Falls es wichtig ist: Der Shop liegt übrigens bei Strato.

[Numerobis]

Wenn ich nicht irre, kannst Du das mit einer Anpassung der htaccess-datei lösen.

Das steht bei meiner drin:

# The following makes adjustments to the SSL protocol for Internet

# Explorer browsers

<IfModule mod_setenvif.c>

  <IfDefine SSL>

    SetEnvIf User-Agent ".*MSIE.*" \

             nokeepalive ssl-unclean-shutdown \

             downgrade-1.0 force-response-1.0

  </IfDefine>

</IfModule>

[/PHP]

[ragnar]

Danke für Deinen Hinweis, allerdings sieht meine htaccsess genauso aus. Das war es also leider nicht. Hat noch jemand einen Vorschlag zur Lösung des Problems?

[nrrlh]

Hallo

wie ist die Adresse

Gruß

Norbert

[ragnar]

Die Adresse lautet:

(optisch aber noch um Umbau:rolleyes: )

[Numerobis]

Wenn ich das richtig sehe, hast Du auch im FF keine gesicherte Verbindung. Er meckert nur nicht. Lies mal das da.

Edit sagt: Bei SSL ist die Adresszeile im FF immer gelb.

[nrrlh]

Hallo

das ist ein Template von Hartmut Frings

das Problem ist in seinen FAQ bekannt

schau mal hier

http://www.hartmutfrings.de/faq/content/3/24/de/ssl-verschluesselung-warenkorb-_-kasse.html

http://www.hartmutfrings.de/faq/content/5/45/de/durch-das-hf-logo-wird-die-ssl-verschluesselung-gestoert-ich-weiss-aber-nicht-wo-und-wie-ich-das-logo-entfernen-kann.html

Gruß

Norbert

[ragnar]

Hier also der aktuelle Stand der Dinge. Der Hinweis auf das Template von Hartmut Frings war insofern sinnvoll, als das ich den Quellcode nun nach seiner Vorlage abgeändert habe. Das Bild hatte ich bereits vorher entfernt, so kann ich ausschließen, daß das die Fehlerursache ist.

Zum jetzigen Zeitpunkt habe ich das Template allerdings wieder komplett entfernt, da in der Anleitung von all-inkl.com steht, daß das Zertifikat durch Produkte Dritter beinflußt werden kann. Das hat am Ergebnis allerdings nichts geändert. Und nun wird lustig:

Ich habe die bei all-inkl.com beschrieben Änderungen durchgeführt – und es hat geklappt. Allerdings schrieben dann die Browser, daß es sich zwar um ein gültiges und vertrauenswürdiges Zertifikat handeln würde, allerdings würde das Zertifikat nicht meine Netzseite zuordnen können. Soweit verständlich, da ich ja auch nicht bei denen liege.

Als ich die config-Dateien sowie die application_top nun auf die Strato-Angaben modifiziert habe (in meinem Fall https://www.ssl-id.de/... bzw. www.ssl-id.de in der application_top) hat es wieder nicht funktioniert. Letzlich besteht die Ausgangsproblematik weiterhin. Ich habe daraufhin ein längeres Gespräch mit einem Techniker von Strato geführt, welches damit endete, daß meine Angaben korrekt seien und der Fehler darin läge, daß in irgendeiner XTC-Datei noch ein Hinweis auf das SSL-Zertifikat fehlen würde. Weiteres könnte er jedoch nicht sagen, da er kein XTC-Programmierer sei.

Wer sich Beispielsweise falsch einloggt landet auf einer https-Seite. Wer eingeloggt ist und sich abmeldet, der landet auch auf einer https-Seite. Wenn ich mich in den Admin-Bereich begebe bzw. mich von dort wieder abmelde, ist ebenfalls alles in Ordnung. Nur beim einfachen Anmelden klappt es nicht.

Gibt es da irgendeine Datei die noch geändert werden muß?

[stefzz]

Hallo,

gibt es mittlerweile eine Lösung?

Habe dasselbe Problem....

Gruß,

Stefanie

[ragnar]

Nein, leider besteht das Problem zur Zeit noch. Vielleicht hat ja hier noch einer einen Vorschlag?

[Numerobis]

Ich habe nochmal reingeklickt und habe zwei Dinge festgestellt:

Du mußt in den ganzen config-Dateien was übersehen haben. Er lädt Dir alle Bilder über http:// und nicht über https://. Vllt. war eine Datei schreibgeschützt und hat einfach Deine Änderungen nich übernommen.

Der Login-Button verweist nicht auf https://.../login.php. Du solltest auch im Template unbedingt mit xtc_href_link(...) arbeiten.

xtc_href_link($page = '', $parameters = '', $connection = 'NONSSL', $add_session_id = true, $search_engine_safe = true)[/PHP]

Wenn mich jetzt nicht alles täuscht, sollte das im Template so aussehen:

[PHP]<a href="{php}xtc_href_link('login.php', '', 'SSL'){/php}">Login</a>[/PHP]

Evtl. steht der Login-Link auch schon als Template-Variable zur Verfügung.

Meine Seite, die auch über einen ssl-Proxy läuft verhält sich absolut normal.

Alles was mit Login, Ihr Konto, Warenkorb und Kasse zusammenhängt, läuft über ssl.

Was Du an Meldungen beschreibst ist normal.

Login über die Box:

-> Aufruf der login.php aus dem Formular über ssl.

Ist alles Richtig, dann Weiterleitung auf index.php ohne ssl. => Meldung umgeleitet auf nicht sichere Verbindung.

Irgendwas falsch, bleibt er bei https://.../login.php und will neue Daten. => keine Meldung, logisch.

Wenn der Kunde was im Warenkorb hat, leitet er übrigens auf den Warenkorb, der auch unter ssl läuft.

Mir fällt gerade ein, daß ich die beiden configure.org.php analog zu den configure.php geändert habe. Vielleicht liegt es einfach daran, daß es bei mir funktioniert.

[ragnar]

Moin,

zunächst einmal einen herzlichen Dank an Numerobis für Deine Hilfe. Ich meine den Fehler nun gefunden zu haben – und zwar in der login.php.

Dort stand bei mir (geöffnet mit WebCraft) in Zeile 87:

82 if (is_object($econda)) $econda->_loginUser();

83

84                        if ($_SESSION['cart']->count_contents() > 0) {

85                                xtc_redirect(xtc_href_link(FILENAME_SHOPPING_CART, '', 'SSL'));

86                        } else {

87                                xtc_redirect(xtc_href_link(FILENAME_DEFAULT,));[/HTML]

das habe ich wie folgt geändert:

[HTML]82if (is_object($econda)) $econda->_loginUser();
83
84 if ($_SESSION['cart']->count_contents() > 0) {
85 xtc_redirect(xtc_href_link(FILENAME_SHOPPING_CART, '', 'SSL'));
86 } else {
87 xtc_redirect(xtc_href_link(FILENAME_DEFAULT, '', 'SSL'));[/HTML]

Nun scheint der Fehler weitestgehend behoben. Nach dem „einfachen“ einloggen gelange ich nun auf eine https-Seite. Der IE meckert nicht mehr und bei allen anderen Browsern klappt auch alles. Ein klitzekleines Problem bleibt allerdings noch, da der FF die Zeile nicht gelb darstellt und sagt, daß Teile der Seite nicht verschlüsselt seien. Hat jemand eine Ahnung woran das liegen kann?

[ragnar]

Ich habs.

Für die, die die Server-Variable FORWARDED_HOST nicht zur Verfügung haben, bzw. bei denen getenv("HTTP")

nicht funktioniert, habe ich folgende Lösung:

Ersetzt in der includes/application_top.php und application_top_export.php die Zeile

QUELLTEXT

$request_type = (getenv('HTTPS') == '1' || getenv('HTTPS') == 'on') ? 'SSL' : 'NONSSL';

oder

QUELLTEXT

$request_type = ($_SERVER['HTTP_X_FORWARDED_HOST'] == 'ssl.webpack.de') ? 'SSL' :

'NONSSL';

durch

QUELLTEXT

$request_type = (substr(HTTPS_SERVER,$_SERVER["HTTP_REFERER"]) != -1 ) ? 'SSL' : 'NONSSL';

Er nimmt sich dann die letzte URL von der der Browser kam, um zu prüfen, ob es ein SSL Proxy war und schaltet SSL ein oder aus. Ist eigentlich ähnlich wie der FORWARDED_HOST, nur dass diese Variable wohl nich alle Provider zur Verfügung stellen.

Im Admin- Bereich gibts eigentlich nichts weiter, außer vielleicht IP überprüfen unter Sessions. Auf true hat das bei mir zu Problemen geführt, da er irgendiwe den SSL- Proxy für nen anderen Benutzer gehalten hat.

Glaube aber eher nicht, dass es das ist.

Es kann sich nur um Probleme mit der base-URL handeln, da er anhand derer alles einbindet.

man man man...

[Madcat2000]

Hi,

ich habe Deine Tipps mal ausprobiert, da ich das gleiche Problem bei Strato habe. Jetzt funktioniert das Login mit SSL, aber ich habe das Problem, dass im Admin-Bereich sämtliche Buttons nur normale http-Links aufweisen. So bald ich z.B. auf Mein Shop klicke, werde ich komplett rausgeschmissen und lande wieder auf der Anmeldung.

Normalerweise sollten diese Einstellungen doch auch verschlüsselt sein, oder?

Madcat

[ragnar]

Zu den Links: Das die nur auf http verweisen ist richtig, denn eine verschlüsselte Verbindung baut er nur auf, wenn sensible Daten übertragen werden (Passwort, Kundendaten etc.).

Allerdings hast Du recht, daß man mit diesen Einstellungen aus dem "Mein Shop"-Bereich wieder rausfliegt. Woran das liegt weiß ich nicht. Nachdem ich jetzt die letzten Nächte damit zugebracht habe eine SSL-Lösung zu finden, werde ich lieber für Änderungen im "Mein Shop"-Bereich die Zeile wieder austauschen, als nach einer Lösung des Problems zu suchen. Sollte jemand eine Lösung finden, werde ich die natürlich auch einbauen.

[ragnar]

Nun klappt es doch wieder. Keine Ahnung.