phpBB.de

Hallo
Das

Nee, HTTPS geht ausschließlich mit der URL https://WWW.forum.nacktsport.org/.

kann ich nicht bestätigen.
Ich kann beide Seiten ohne Probleme aufrufen:
https://forum.nacktsport.org/
https://www.forum.nacktsport.org/


Grüße: Mahony

Mahony hat geschrieben:Hallo
Das

Nee, HTTPS geht ausschließlich mit der URL https://WWW.forum.nacktsport.org/.

kann ich nicht bestätigen.
Ich kann beide Seiten ohne Probleme aufrufen:
https://forum.nacktsport.org/
https://www.forum.nacktsport.org/

Grüße: Mahony

Nach dem Aufruf von https://forum.nacktsport.org will Google Chrome die gesicherte Verbindung nicht aufbauen und meckert: "Beim Versuch, mit forum.nacktsport.org zu kommunizieren, haben Sie einen Server erreicht, der sich http://www.forum.nacktsport.org nennt." und "Das Serverzertifikat stimmt nicht mit der URL überein." Internet Explorer stimmt dem zu: "Das Sicherheitszertifikat dieser Website wurde für eine andere Adresse der Website ausgestellt... Es wird empfohlen, dass Sie die Webseite schließen und nicht zu dieser Website wechseln." Tut man es dennoch, besteht Internet Explorer auf "Zertifikatsfehler" und zeigt die Seite nach dem Anmelden nur im Textmodus an und nach dem Abmelden kommt "Die Webseite wurde nicht gefunden." Dieses Vorgehen ist wohl weniger dazu geeignet, um den Nutzern des Forums ein erhöhtes Gefühl von Sicherheit zu geben.

Wenn eine Ursache für die fehlerhaften Rücksprünge des Browsers im Aufruf der Portnummer liegt: wie kann ich dieses Verhalten ändern?

Nach dem Aufruf von https://forum.nacktsport.org will Google Chrome die gesicherte Verbindung nicht aufbauen und meckert: "Beim Versuch, mit forum.nacktsport.org zu kommunizieren, haben Sie einen Server erreicht, der sich http://www.forum.nacktsport.org nennt." und "Das Serverzertifikat stimmt nicht mit der URL überein."

Das hatte ich schon geschrieben, das Dein zertifikat auf die sub.sub.domain Zertifiziert ist, das der Chrome an der Stelle bei sub.domain meckert ist bei allen so, diesen Umstand kann man aufheben indem man das aufgerufene mittels Bestätigen (beim fireFox nennt sich das "Zertifikat herunterladen") des vorhandenen Zertifikats übernimmt und die Verbindung ist ab diesem Zeitpunkt auch Verschlüsselt.
Wenn man dann das Zertifikat anschaut steht darin die Originale sub.sub.domain.

Zur weiteren Erklärung:
das "www" ist ein Relikt aus den Anfängen des Internets (da wurde noch das Gopher benutzt und brauchte eine schematische Trennung von Aufrufen zur Darstellung mittels HTML) nachdem man aber das Internet Publick gemacht hat und die DNS Server das "www" gar nicht als Bestandteil einer URI ansehen, so ist das "www" im Sprachgebrauch bei den Admins eine SUBdomain Angabe.
(Dies ist eine in kürze formulierte Erklärung, da dazwischen noch einige technische Schritte liegen ist mir Bekannt aber dürfte den Inhalt hier in einen Roman erweitern.)

JohannesK hat geschrieben:Wenn eine Ursache für die fehlerhaften Rücksprünge des Browsers im Aufruf der Portnummer liegt: wie kann ich dieses Verhalten ändern?

Im ACP (Allgemein) befindet sich unter Server URL-Einstellungen:
"Server-Port:
Der Port, auf dem der Server läuft, für gewöhnlich 80. Ändere den Wert nur, wenn er sich davon unterscheidet."

Klar ist der Wert 80. Ist dieser Eintrag der Grund, weshalb die 80 vom Browser in die URL eingefügt wird, die dann vom Server aber nicht verstanden wird? Was passiert, wenn ich o.g. Parameter lösche?

Problem: der Browser fügt in die Rücksprungadresse die Portnummer ein. Diese URL wird vom Server nicht verstanden, es kommt eine Fehlermeldung. Wenn ich die "80" aus der URL rausnehme und lade, kommt die korrekte Seite.

an dieser Stelle hänge ich auch fest... gab es auf diesen letzten Thread eine irgendwo ein Antwort?

Der Standardport für HTTPS Anfragen ist 443. Du brauchst außerdem ein gültiges Zertifikat für die Webseite, damit die Verschlüsselung greifen kann.