Umstellung HTTP --> HTTPS

  • Beim oberen Link geht bei mir Google Maps auf und zeigt die Karte (http). Beim unteren Link sehe ich nur Quellcode (https).

    Das merkwürdige Verhalten könnte an deinem Brwoser Cache liegen Dirk - die Links enthalten tatsächlich nur den Verweis auf die Maps API. Anscheinend füllt das Script deiner Webpage die für die Api benötigten Parameter in den Link. Und wenn die nicht drin sind sieht das so aus wie gehabt.


    Aber egal eigentlich - die Tatsache dass die Zielseite auch per HTTPS öffnet belegt, dass auch der aufgerufene Server HTTPS "spricht" also per Port 443 erreichbar ist. Auch wenn du nur die API Schnittstelle siehst. Dann kannst du davon ausgehen dass der aufgerufene Server beides kann. Was mich in dem Fall (Google) auch nicht weiters wundert.


    Wie es aussieht, wenn ein Server keinerlei HTTPS spricht kannst du hier sehen: https USAletsGo .

  • Das merkwürdige Verhalten könnte an deinem Brwoser Cache liegen Dirk - die Links enthalten tatsächlich nur den Verweis auf die Maps API. Anscheinend füllt das Script deiner Webpage die für die Api benötigten Parameter in den Link. Und wenn die nicht drin sind sieht das so aus wie gehabt.

    Hast Recht, das war bestimmt das Problem. Ich war auch nicht am heimischen Rechner und konnte nicht so ganz intensiv rumprobieren.

    Aber egal eigentlich - die Tatsache dass die Zielseite auch per HTTPS öffnet belegt, dass auch der aufgerufene Server HTTPS "spricht" also per Port 443 erreichbar ist. Auch wenn du nur die API Schnittstelle siehst. Dann kannst du davon ausgehen dass der aufgerufene Server beides kann. Was mich in dem Fall (Google) auch nicht weiters wundert.

    Denke ich auch mittlerweile. Um so besser.


    Wie ist das eigentlich mit meinem Kontaktformular? Das ist ja ein externes (lizenziertes) Skript - geht das durch, oder muss da etwas umgestellt werden?

  • Ich habe jetzt die Umstellung auf HTTPS vollzogen.


    Für alle, die es interessiert, ein kleiner Erfahrungsbericht in ein paar Stichpunkten:


    (1) Zeitaufwand: ca. 2 Stunden bei einem Projektvolumen von etwa 1500 Seiten Content
    (2) Schritt 1: Zertifikat anfordern (lassen) und auf dem Server installieren (lassen) --> ein Zertifikat war bei 1&1 kostenlos; Abruf und Installation durch 1&1 vollautomatisch; Zeitaufwand: 1 Minute
    (3) Schritt 2: In der .htaccess 301-Redirect von HTTP auf HTTPS eintragen. Wer möchte, kann von mir den Code haben, aber findet man auch im Internet. Zusätzlich zu der vorhandenen Umleitung von "ohne www" auf www, um duplicate content zu vermeiden.
    (4) Schritt 3: Umstellung sämtlicher nachgeladener Skripte, Programmbibilotheken und anderer externer Komponenten von HTTP auf HTTPS (Sachen, die es nicht in HTTPS gibt, schmeiße ich raus, aber das war so gut wie gar nichts); Zeitaufwand: 1 Stunde
    (5) ausgehende Links: unverändert; sind für die Bewertung, ob secure oder nicht, scheinbar irrelevant --> wusste ich nicht
    (6) eingehende Links: unverändert; wird ja umgeleitet, deshalb können alle Banner, die man bei irgendwelchen netten Forenkollegen usw. hat, so bleiben, wie sie sind
    (7) neue Sitemap generieren lassen und bei Google eingereicht


    Soweit ich das überblicke, scheint alles geklappt zu haben.


    Es ist natürlich nicht auszuschließen (sogar eher wahrscheinlich), dass noch die eine oder andere Seite nachgebessert werden muss. Falls jemand so eine Seite findet, wäre ich für eine Mitteilung dankbar.


    Fazit: alles halb so wild

  • Ob man eine statische oder dynamische IP hat, ist m.E. irrelevant. Da habe ich mich gar nicht drum gekümmert.


    Wichtig ist, dass die URL umgestellt wird.


    Eine feste IP habe ich ganz sicher nicht, das ist ja eher was für Business-Kunden, damit sich z.B. Mitarbeiter leichter über VPN oder so etwas einloggen können. Soweit ich weiß, klappt das auch nur mit einer Glasfaserleitung.

  • Ich glaube, z.B. Hosteurope macht das so. Kann wohl sein.


    1&1 fordert das nicht, glaube auch nicht, dass die das auf dem Server umstellen, wenn sie es ansonsten Business-Kunden teuer aufschwatzen wollen.


    Ich hätte da wenig Skrupel und würde ggf. den Host wechseln.

  • Ja, aber dahinter steht keine dedizierte IP-Adresse, sondern der Host shared darauf verschiedene Hosting-Konten - keine Ahnung, wie das intern genau gemacht wird (über interne Subdomains oder was weiß ich).


    Statische IP-Adressen sind, so kenne ich den Begriff, hingegen dediziert, damit sind entsprechende Pakete auch deutlich teurer und richten sich an Business-Kunden.


    Edit: Obwohl, ich habe mal ein bisschen recherchiert. Kann gut sein, dass das bei 1&1 wirklich automatisch über dedizierte IP-Adressen läuft, wenn man ein Webhosting-Paket erwirbt. Gefunden habe ich dazu konkret noch nichts.

  • Braucht man die wenn man die dinger online hostet (bzw hat man die da nicht sowieso)? Oder is the HP auf dem Heimserver?

    Nein, das ist nicht auf dem Heimserver. Das ist ein Server bei dem Hoster. dafür braucht man aber keine statische IP. Meine wechselt immer mal bisher.

  • Vermutlich, weil die eben nicht dediziert ist.
    Ich dachte, dass man feste IPs auch nur bekommt, wenn man einen sündhaft teuren dedizierten Server als Hostingpaket bucht.

    Nö, eben nicht. Ich bin gerade echt am Überlegen, was ich amchen. besonders auch, weil ich ja eine etwas längere Kündigungsfrist habe.

  • Nö, eben nicht.

    Also hast du eine feste IP auch ohne dedizierten Server? Oder habe ich das falsch verstanden?


    Keine Ahnung, was die Provider da machen, vielleicht geben sie dir auch gegen Extrakosten nur die Funktionalität einer festen IP ohne den Rest, der zu einem ded. Server gehört.


    Für ein "normales" SSL-Zertifikat (Domain Validation --> prüft nur, ob du auch Domaininhaber bist und dein Provider dich kennt; reicht für das grüne Schloss im Browser) - da gibt es ja auch Unterschiede - braucht man keine feste IP.

  • Also hast du eine feste IP auch ohne dedizierten Server? Oder habe ich das falsch verstanden?

    Nee, ich habe keine feste IP.

    Für ein "normales" SSL-Zertifikat (Domain Validation) - da gibt es ja auch Unterschiede - braucht man keine feste IP.

    Das sagen sie aber.


    Wenn du mal hier schauen magst. KLICK


    Die Umstellung selber kriege ich sicher auch hin, nur der Weg dahin ist momentan mein Problem.

  • Also die Preise beeindrucken mich. Ich zahle 3,99 im Monat für 50 GB inkl. ein Domain Validation-Zertifikat. Nix mit fester IP oder so.


    Rein "formal" braucht man meines Erachtens noch immer keine feste IP für eine Domain Validation, was der Hoster dann dem Kunden anbietet, steht natürlich auf einem anderen Blatt.


    Wenn es für dich keine zwingenden Gründe gibt, bei dem Hoster zu bleiben, würde ich die Fahnen wechseln und mir was Unkomplizierteres suchen.

  • Ich zahle 3,99 im Monat für 50 GB inkl. ein Domain Validation-Zertifikat.

    Bei 1&1? Hast du da Support dabei?


    Das ist ja schon extrem billig.

  • Um das ganze ein wenig aufzuklären (arbeite schließlich seit viele Jahren in dem Gebiet).


    Statische/dynamische IP-Adressen gibt es nur bei den Anschlüssen, wo das Internet genutzt wird (also zuhause, am Handy oder vielleicht auch noch selten im Büro).
    Statisch bedeutet, dass eine bestimmte IP-Adresse fix dem Anschluss zugewiesen ist. Dynamisch eben, dass diese sich ändern kann (im Detail wird dort das Protokoll DHCP verwendet, um die Adresse zuzuweisen).



    Ein Webserver (bei einem Hoster) hat immer eine statische IP-Adresse. Punkt.
    (Falls man zuhause einen Server betreibt, kommt es natürlich auf den Anschluss an).


    Was SSL betrifft, war es bis vor ein paar Jahren notwendig, dass ein Webserver für SSL eine eindeutig zugewiesene Adresse gebraucht hat. Also dass auf dieser Adresse nur dieser eine Webserver zu erreichen war (wurde im Thread schon als dediziert bezeichnet).
    Das ist aber mittlerweile nach Änderungen im SSL Standard nicht mehr notwendig (seit Einführung von SNI Server Name Indication). Es kann also auch ein SSL-Zertifikat verwendet werden, wenn der Webserver auf einem Shared Host (also viele Webserver mit derselben IP-Adresse) liegt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!