Tag: server

Anbieter SSL Zertifikate wie Sand am Meer

Tuesday, 30. December 2014 / / 0 Comments

Ganz zu Beginn meines Server-Wechsels zu Hetzner hatte ich mir ein signiertes SSL Zertifikat mit einer Laufzeit von zwei Jahre gegönnt. Nach Ablauf der zwei Jahre habe ich es nicht wieder erneuert, da mir auch irgendwo der Mehrwert gefehlt hat. Ich benutzte es damals zum Aufruf einer Administrationsoberfläche, die rote Seite im Chrome Browser mit dem entsprechenden Hinweis, bzgl. dem abgelaufenen SSL-Zertifikat, hat mich nicht weiter gestört, denn die Verbinung war weiterhin verschlüsselt. Nachdem Google jetzt bekannt gegeben hat, die Verbindungsverschlüsselung einer Seite zukünftig als Ranking-Faktor heranzuziehen, bin ich am überlegen wieder ein SSL Zertifikat zu kaufen.

Anforderungen an ein SSL-Zertifikat

Sowohl Anbieter als auch die SSL-Zertifikate selbst, scheint es mittlerweile, wie Sand am Meer zu geben, daher ist eine genaue Definition der Anforderungen wichtig um später besser abzuschätzen zu können, welche Eigenschaften benötigt werden:

  • Verschlüsselung: Die scheint bei allen Anbietern ähnlich zu sein, von daher gibt es hier keine besonderen Anforderungen. Der Unterschied zwischen der “Verschlüsselungstiefe” und der “Tiefe des Root-Zertifikats” ist im folgenden Artikel erklärt: http://security.stackexchange.com/questions/19473/understanding-2048-bit-ssl-and-256-bit-encryption.
  • Browser-Kompatibilität: Abhängig vom jeweiligen SSL-Zertifikat kann es besonders bei mobilen Browsern trotz gültigem Zertifikat zu einer Warnmeldung kommen, da die Trusted Autority dem Browser nicht bekannt ist. Es empfiehlt sich die Möglichkeit zu nutzen vorher ein Testzertifikat zu erstellen und auf mögliche Inkompatibilitäten vorab zu testen
  • Grüne Adresszeile: Beim Aufruf von bspw. https://www.ing-diba.de erscheint in der Adresszeile der Hinweis “ING-DiBa AG [DE]” im Vergleich dazu wird beim Aufruf von https://www.google.de nur das “https” grün. Interssant wäre zu wissen, wie viele Leute auf die grüne Adresszeile achten bzw. entsprechend handeln wenn dort nicht der Name der erwarteten Organisation erscheint. Für mich bietet die Funktion derzeit keinen Mehrwert, weshalb ich die Kosten und den zusätzlichen Aufwand bei der Beantragung einspare
  • Sub- und Multi-Domains: Theoretisch kann hinter einer IP-Adresse nur ein SSL-Zertifikat, was nur für eine Domain gültig ist, hinterlegt werden. Bei mehreren Web-Projekten, auf einem Server und der begrenzten Anzahl an IPv4-Adressen kann dies schnell teuer werden, wenn weitere IP-Adresse dazu gebucht werden müssen. Auch Subdomains sind eine zweite Domains, weshalb bei der Bestellung darauf geachtet werden sollte, ob bspw. mit oder ohne “www” der Standard ist, welcher abgesichert werden soll.
  • Laufzeit: I.d.R. beträgt die Laufzeit zwischen 1 und 3 Jahren. Auf jeden Fall empfiehlt es sich im Kalender eine entsprechende Erinnerung bzgl. dem Ablauftermin einzurichten und die initiale Bestellung nicht zwischen Weihnachten und Neujahr zu erledigen, damit einem “Unsere Internetseite funktioniert nicht mehr”-Anrufe erspart bleiben.
  • Preis: Die Preise variieren stark abhängig von den jeweiligen Eigenschaften, der Laufzeit und dem Anbieter bzw. der Certification Authority.

Anbieter SSL Zertifikate

Folgende SSL Zertifikats Anbieter werde ich mir näher anschauen:

  • PSW Group (https://www.psw.net)
  • GoDaddy (https://de.godaddy.com)
  • Speed IT (https://www.speedit.org)
  • Force SSL (http://forcessl.com/)
  • SSL Market (https://www.sslmarket.de)
  • icertificate (https://icertificate.eu/)
  • Trustico (http://www.trustico.de/)
  • GlobalProtec (http://globalprotec.com/de/)
  • SSL Point (https://www.sslpoint.com/de/)
  • Namecheap (https://www.namecheap.com)

Für welchen Anbieter ich mich entschieden habe, schreibe ich in einem späteren Artikel.

vServer, Root Server, Managed Server oder doch Dedicated Server

Saturday, 29. November 2014 / / 1 Comment

Angefangen hat Alles mal mit einem kleinen Webhosting bei All-Inkl. Danach folgte ein vServer bei 1blu und anschließend ein Root Server bei Hetzner. Aktuell sieht es danach aus, dass der nächste logische Schritt ein Business Hosting bei All-Inkl ist. Das mag auf den ersten Blick nicht logisch erscheinen, macht aber unter den folgenden Gesichtspunkten Sinn:

  • E-Mail: Natürlich könnte ich alles über eine GMX, Gmail oder anderswo Adresse abwickeln, aber für individuelle E-Mail Adressen pro Domain, muss entweder ein entsprechender MTA auf dem Server eingerichtet werden oder man muss den Dienst woanders buchen, wobei sich dann die Kosten an der Anzahl User und Domain orientieren.
  • Platz: Ein wichtiges Kriterium ist der verfügbare Speicherplatz, denn schließlich müssen nicht alle Dokumente / Unterlagen auf einem Web-Server auch zwangsläufig ins Web bzw. kann ein Web-Server auch für Berechnungen genutzt werden, die später Off-line benötigt werden.
  • SSH: Der große Vorteil gegenüber FTP ist die Verschlüsselung, welche gerade bei den vielen WLANs immer wichtiger wird. Außerdem ist es besonders bei der Anpassung von Konfigurationen immer etwas umständlich und langwierig die Datei erst herunterladen, bearbeiten und dann wieder hochladen zu müssen.
  • Wartung: Besonders die letzten Monate haben mit Heartbleed und Shellshock gezeigt, dass selbst in weit verbreiteter Open-Source Software noch Lücken sein können, bei denen schnelles Handeln gefragt ist. Dazu braucht es neben Zeit aber auch die nötigen Kenntnisse richtig zu handeln, denn oftmals existiert zunächst nur ein Workaround, der nicht einfach per apt-get oder yast eingespielt werden kann.
  • Domains: Seit langem habe ich meine Domains bei einem spezialisierten Dienstleister, da der Umzug von Domains mit viel Papierkram verbunden ist und es außerdem Kosten spart.
  • SSL-Zertifikat: Nachdem Google bekannt gegeben hat, das dies zukünftig ein Rankingfaktor ist und gleichzeitig IPv4-Adressen knapp sind bzw. der Umstieg auf IPv6 nicht vorwärts geht, sollte darauf geachtet werden, das es gleich dabei ist.
  • RAM: Besonders große Frameworks wie Symfony oder CMS wie TYPO3 brauchen schon mal etwas mehr RAM. Dies war, glaube ich, auch mal mein urspünglicher Grund gewesen von einem Webhosting zu einem vServer zu wechseln. Abhängig von der Art, wie PHP installiert ist, kann es selbst bei nur wenigen Zugriffen und schlechter Programmierung schnell knapp werden.
  • Installer: Viele Foren beschäftigen sich gefühlt nur damit, wie bei einem bestimmten Anbieter dieser oder jenes System konfiguriert werden muss, damit es richtig funktioniert. Auch bei einem Root-Server hat man oft das Problem die richtigen Einstellungen bspw. bei ImageMagick zu finden. Die Nutzung von Installern, bei denen dann nur noch die Domain angegeben und das System ausgewählt werden muss, erleichtert die Inbetriebnahme erheblich und schont die Nerven.

Der Auslöser für meinen Umzug dieses Mal war die Wartung des Servers, für die ich einfach keine Zeit mehr hatte. Zunächst wollte ich zu Strato in einen Managed Server wechseln, jedoch hätte ich dann meine Domains zu Strato umziehen und nochmals extra monatlich dafür zahlen müssen, außerdem gab es keinen SSH-Zugang. Bei All-Inkl sind 20 Domains im Business Tarif mit drin, es gibt einen SSH-Zugang, nur bzgl. der RAM-Leistung gibt es keine Aussage, aber auf E-Mail Anfrage hat man mir mitgeteilt, dass Performance Probleme jederzeit schnell bearbeitet werden würden.

Error 404, 500, etc. automatisch finden

Sunday, 15. May 2011 / / 0 Comments

Gerade bei größeren Webseiten, mit unterschiedlichen Plugins und Erweiterung, kann es vorkommen das einzelne Seiten nicht aufrufbar sind. Die Gründe dafür sind noch vielfälter als die zur Verfügung stehenden Status-Codes. In den Google Webmaster Sitemap Tools befindet sich unter der Kategorie Crawling Fehler folgende Einteilung:

  • Nicht gefunden
  • Nicht aufgerufene URLs
  • URLs durch “robots.txt” eingeschränkt
  • Zeitüberschreitung beim Aufrufen von URLs.
  • HTTP-Fehler
  • Nicht erreichbare URLs
  • Soft- 404-Fehler

Zu beachten ist dabei, das Google nicht nur die Verlinkung innerhalb der Seite überprüft, sondern auch Links von extern, welche Möglicherweise auf nicht mehr gültige URLs zeigen. Dafür eignet sich die anschließend vorgestellte Analyse Methode nicht. Im folgenden geht es ausschließlich um Links welche Innerhalb der Seite keinen 200 Code, OK bzw. Erfolgreich, zurückgeben.

Sehr anschaulich ist die Firefox Erweiterung LinkChecker, welche unter https://addons.mozilla.org/de/firefox/addon/linkchecker/ heruntergeladen werden kann.

Link Checker Ergebnis

Link Checker Ergebnis

Diese stellt in Ampelfarben, welche auch entsprechend konfiguriert werden können, die Erreichbarkeit von Links auf der jeweiligen Seite dar. In der Statusleiste gibt es zudem eine Anzeige, welche die Gesamtanzahl der Links, sowie die Anzahl der geprüften und den Fortschritt anzeigt:

Linker Checker Progress Bar

Linker Checker Progress Bar

Für größere Webseiten, welche über viele verschiedene Seiten und Kategorie verfügen, ist die händische Überprüfung mittels Firefox Plugin sicherlich nicht praktikabel. Dafür eignet sich wget. wGet ist ein kleines Kommandozeilen Tool, welches vielfältig einsetzbar ist. Für unseren Anwendungsfall benötigen wir die Spider Funktionalität:

[html]
wget -r –spider -o log.txt http://www.bugblog.de
[/html]

Wget verfolgt (-r rekursiv) alle Links innerhalb der selben Domain und läd die Dateien zum finden weiterer Links temporär (–spider) herunter. Das Ergebnis beim Aufrufen der Dateien (-o output) wird in der log.txt Datei gespeichert. Diese kann später nach den oben beschriebenen Statuscodes durchsucht werden.

Eine ausführliche Auflistung, aller möglichen Status Codes befindet sich unter: http://www.google.com/support/webmasters/bin/answer.py?answer=40132