Beiträge von antondollmaier

  • Installation

    Zitat von andreas

    Bleibt mir also nichts weiter übrig als den LE-Client zu installieren.


    oder 7€ mehr in die Hand zu nehmen - für "SSL-Certs flat" ein guter Preis.


    Zitat

    Generell müsste das doch irgendwie in Verbindung mit LC funktionieren?


    Ja, mit der Webroot-methode sollte die Validierung klappen. Die Zertifikate müssen dann halt manuell ins LiveConfig integriert werden.

  • Reset DNS

    Zitat von kk

    Sie kennen den. ;)


    ah. :)


    Zitat

    Um dessen Ehre etwas zu retten: ich vermute, dass es am PowerDNS liegt, der dort zum Einsatz kommt. 255 Zeichen klingt für mich nach der typischen "varchar"-Grenze, und ein Datenbankschema mit zig Millionen von Einträge auf "text" umstellen ist meistens keine gute Idee...


    oh, nett. Wusste nicht, dass dort PowerDNS zum Einsatz kommt.


    Zitat

    Wir werden uns in Kürze auch intensiver mit PowerDNS beschäftigen.


    Halte ich - insbesondere wegen DNSSEC - für sehr sinnvoll.


    Bei Fragen einfach melden :)

  • Reset DNS

    Zitat von marinal

    Und ja, sie haben mit den 255 Zeichen recht ... ich war einen Moment sprachlos ... Änderungen sind hier nicht geplant.


    Oh Mann.


    Da wäre jetzt gut zu wissen, wer das ist, um zukünftig einen großen Bogen drumrum machen zu können :)

  • Transparenter Proxy für HTTPS-Verbindungen

    Zitat von WebOscar

    antondollmaier: Hasse rääsch! Ich hatte mich mit der Problematik schon einmal befasst und erfolgreich verdrängt, dass der Host erst dann aufgelöst wird, wenn eine HTTPS-Verbindung hergestellt wurde. Bis dahin gibt es das Standard-SSL-Zertifikat und danach erst kann mit SNI das richtige, passende Zertifikat ausgeliefert werden.


    Mit SNI sendet der Client im TLS-Handshake den Hostname mit, für den er eine TLS-Verbindung aufbauen will - somit kann der Server (soweit der die SNI-Erweiterung unterstützt) _direkt_ das richtige SSL-Zertifikat selektieren und verwenden.


    Das "Standard-Zertifikat" kommt nur noch zum Einsatz, wenn ein Client kein SNI kann:


    > https://sni.velox.ch/




    Zitat

    Darum habe ich erstmal ein Wildcard-Zertifikat auf dem entsprechenden Server und wenn ein Kunde eine eigene Domain wünscht, dann muss er halt eine eigene IP bekommen und für das passende Zertifikat halt selbst bezahlen.


    Genau.


    Kunden haben zwei Optionen:


    - SNI nutzen
    - eigene IP zusätzlich bezahlen


    Beides ist ja vom SSL-Zertifikat an sich unabhängig.



    Zitat

    In meinem wirren Programmierer-Hirn habe ich eine unscharfe Idee, die ich aber aufgrund der Auftragslage in diesem Leben wohl nicht mehr umsetzen kann:


    Ein Deamon, der HTTPS Anfragen entgegennimmt und cached. Anhand einer Liste interner IPs wird diese Anfrage nacheinander an alle internen IPs gesendet und der Handshake wird getestet. Passt das ausgelieferte Zertifikat, sorgt der Deamon fur ein Forwarding (via iptables oder so) des Clients zum richtigen Zielhost für die Dauer der Session...


    Ok, das ist ... spooky.


    Aber wie gesagt: wird nicht klappen. Woher weiß dein "Proxy" denn, nur anhand der Client-IP(!), was denn nun das "richtige" Zertifikat auf der "richtigen" Backend-IP sein soll?


    Ich bin mir sicher: wenn das Problem gelöst wäre, wäre kein (großer...) Bedarf für SNI gewesen.

  • Berechtigungsfehler bei FastCGI

    Mit ProFTPd werden die Rechte per Default korrekt gesetzt:


    Code
    # Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
Umask                           022  022
# Normally, we want files to be overwriteable.
AllowOverwrite                  on


    Umask 022 ergibt chmod 0755.

  • Berechtigungsfehler bei FastCGI

    Zitat von leepfrog

    ./htdocs/ hat web1:www-data
    sämtliche Unterordner (sowie /blog/ als auch die Unterordner von WP darunter) haben aber web1:web1


    was so auch korrekt ist.


    Zitat

    Da stimmt wohl etwas nicht bei der Gruppenzuweisung beim Upload durch den ProFTPd oder es fehlt Gruppenmitgliedschaft für www-data in web1.


    Nach einem manuellen chgrp -R www-data ./htdocs/ funktioniert es - aber das kann ja nicht die Lösung sein - auch ein Kunde kann ja mal Unterordner hochladen.


    Ordner-Rechte prüfen. Unterhalb von htdocs darf nicht 0750 verwendet werden, sondern es muss auf 0755 gesetzt werden - sonst darf der Apache ja nicht in den Ordner.

  • Transparenter Proxy für HTTPS-Verbindungen

    Ergänzung:


    Einzige Abhilfe, wenn mehrere Domains abgedeckt werden soll: ein Zertifikat erwerben, das alle Domains beinhaltet (Multi-Domain-Zertifikat).


    Ist natürlich nur möglich, wenn es finanzierbar ist (die kosten mehr als Single-Domain-Zertifikate) und vom Datenschutz her machbar ist (da die anderen abgedeckten Domains im Zertifikat aufgelistet werden müssen).

  • Transparenter Proxy für HTTPS-Verbindungen

    Zitat

    Hat vielleich jemand eine Idee?



    Ja: lass es. Man kann so keine IPs "sparen", es geht schlichtweg nicht.


    Kurz: der TLS-Handshake mit Zertifikats-Austausch erfolgt bei Clients, die kein SNI können, auf dem Server nur anhand der Server-IP, bevor der Server überhaupt eine Unterscheidung auf den HTTP-Hostname durchführen kann.



    Länger:


    Ohne SNI wird der erste vHost (sowohl Nginx als auch Apache) selektiert, dessen IP/Port-Kombination zur Anfrage passt (bei nginx: "listen ... default").


    Aus diesem vHost wird dann das SSL-Zertifikat genommen und dem Client präsentiert, der dann daraufhin den TLS-Handshake durchführt.


    Zu diesem Zeitpunkt ist dem Webserver über die tatsächlich gewählte Domain ("ServerName") nichts bekannt, die Auswahl erfolgt wirklich nur anhand von Server-IP/Port. Erst nach dem erfolgreichen TLS-Handshake sendet der non-SNI-Browser dann den HTTP-Request, der im "Host:"-Header den letztendlichen vHost/Server-Name enthält. Dessen SSL-Konfiguration ist dann aber hinfällig, da ja die Verbindung bereits verschlüsselt wurde.


    Somit kann - ob nun "Proxy" oder nicht - nur ein einziges SSL-Zertifikat je IP/Port überhaupt an Clients ausgeliefert werden, die kein SNI können.


    => es wird auch weiterhin für jedes SSL-Zertifikat eine eigene IP benötigt, sobald SNI nicht eingesetzt werden kann.



    Weitere Details siehe Wikipedia:


    - OSI-Layer:
    - TCP
    - TLS
    - HTTP
    - RFC 3546

  • Fragen zur API

    Zitat von Steinweber

    Hat man einen eigenen Datenstand, kann man jede API anbinden. Verwendet man aber LC und fügt dort die Funktionen ein, hat man keinen "eigenen" Datenbestand und man könnte nicht einfach wechseln.


    Warum implementierst du den letzten Teil deines Verwaltungs-Systems, nämlich die tatsächliche Konfiguration auf den Servern, nicht auch noch?


    Dovecot mit MySQL-Backend ist ziemlich easy. Einzig beim Apache hätte ich persönlich Bauchschmerzen bei der Implementierung (da einige Abhängigkeiten, vgl. System-Accounts, php.ini, FastCGI, ...).


    Ergebnis: komplette Unabhängigkeit von LiveConfig oder sonstigen Panels.

  • Fragen zur API

    Sehe ich teilweise auch so. Kunden neu anlegen und löschen sollte vollständig via API realisierbar sein.


    Ansonsten gibt es ja die Möglichkeit, die Rechnungen etc direkt im LiveConfig zu integrieren. Da mehrere Hosting-Accounts ja eh dem gleichen Kunden zugeordnet werden, hat jeder _Kunde_ auch eigentlich nur einen Login.

  • PHP 5.4.45, 5.5.29, 5.6.13 und 7.0.0rc2

    Zitat von Nosxxx

    Kommen denn auch 32bit Packete für Jessie =) ?


    Warum sollte man heute noch ein OS als 32Bit nutzen?


    Alle CPUs sind schon seit knapp 10 Jahren 64bit-tauglich. Auch unterhalb von 4GB gibt es eigentlich keinen Grund, 32Bit einzusetzen - erst Recht auf skalierbaren Plattformen, wo jederzeit auf >3,3GB hochskaliert werden könnte.



    Oder hab ich einen riesigen Denkfehler und es gibt tatsächlich Gründe "pro 32Bit"?