Apache/MacOS: Helft mir, ein Lets Encrypt Cert einzurichten

  • Hallo allerseits,


    ich bin eigentlich schon relativ weit mit meinen ganzen Einstellungen und dem Konfigurieren der httpd.conf, aber IRGENDWO scheint es noch zu hängen.


    Aber ich bin mir sicher, ich stehe kurz vor dem Durchbruch ;-)


    Die httpd Syntax ist OK und meldet keine Fehler.

    Die aktuelle Fehlermeldung sieht noch so aus:


    Soweit ich weiß, sind die DNS-Einträge aber bereits korrekt auf meine eigene, feste IP umgeschrieben.

    * A --> IP

    * AAAA --> IPv6

    @ A --> IP

    @ AAAA --> IPv6

    Diese vier Einträge habe ich auf meine IP geändert.


    Firewalls habe ich, soweit vorhanden, zumindest temporär deaktiviert.

    Ein Webroot-Plugin benutze ich, soweit ich mir bewusst bin, nicht, habe zumindest nichts mit diesem Namen installiert.


    Höchstens noch irgendwas mit Zugriffsrechten auf dem DocumentRoot? Da hat man aber allgemein Zugriffsrechte...

    Ideen sind willkommen... ?(

  • Was siehst du, wenn du "http://domain.de/" aufrufst?

    Eine Errorseite oder Indexseite deines Apache (Verbindung klappt) oder einen Timeout?

    Meine (Netcup) Produkte: VPS 1000 G7 SE, S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Okay, warum MacOS / Apple?

    Hast du dein Mac Gerät in Heimnetzwerk und willst Let's Encrypt Certs auf diesem Nutzen?

    Ist dein NAT am Router für Port 80 & 443 offen für die IP des Macbooks? (Port Forwarding?)


    Kannst du die Seite über das Mobilfunknetz öffnen?

  • "Connection refused" bedeutet, dass der Webserver nicht antwortet. Die Verbindung zum Webserver wird also vorher blockiert. Das Problem kann also sein:

    - Falscher/nicht propagierter DNS Eintrag

    - Webserver läuft nicht oder antwortet nicht auf dem Interface

    - Firewall blockiert Verbindung (kann auch ein Router/etc im Weg sein)

  • Okay, erst mal vielen Dank für die vielen Vorschläge und Fragen.

    Ich versuche, das nun aufzudröseln und der Sache auf den Grund zu gehen:


    Lukay

    Der aktuelle Fehler ist ein simples "kann keine Verbindung zum Server aufbauen"

    PING auf meine Domain funktioniert allerdings.


    vmk

    Nein, denn aktuell kann die ganze Website nicht aufgerufen werden.


    H6G

    Ja, ist ein lokaler Mac, und Ports 80 und 443 sind für dessen lokale IP auf TCP freigegeben.

    Das mit dem Mobilfunknetz hat sich aktuell eh erledigt, siehe oben, die Website ist nicht erreichbar.


    Steini

    DNS schließe ich aus, da PING auf die Domain funktioniert.

    Firewalls sind offen/eingerichtet


    Es läuft wohl alles darauf hinaus, dass der Apache nicht oder nicht korrekt läuft bzw. falsch konfiguriert ist. Das kann gut sein, da ich das mehr oder minder zum ersten Mal alles von Hand mache.


    Daher zitiere ich euch nun die "kritischen Stellen" aus meiner httpd.conf und möchte euch bitten, logische Fehler zu melden.

    Die Syntax ist wohl okay, aber der Server will nicht richtig. Daher...


    Seht ihr da was? ?(

  • Darauf antwortet wahrscheinlich der Router.


    Benutzt ihr NAT und RFC1918 Adressen? Wenn ja ist Listen 24.134.221.81:80 falsch.

    Ich gehe mal davon aus, denn du redest von lokalen Adressen.

    Dann müsste es Listen 80 heißen oder deine lokale Adresse.

    Wahnsinn! Jetzt bin ich offenbar einen Schritt weiter, denn der Aufruf von http://www.domain.de bringt mir nun:

    Forbidden

    You don't have permission to access / on this server.


    ...ich glaube, jetzt muss ich nur noch die Zugriffsrechte oder den www-Pfad korrigieren...?(

  • ...ich glaube, jetzt muss ich nur noch die Zugriffsrechte oder den www-Pfad korrigieren

    Wenn deine aufgerufene Datei /var/www/index.html sei, müssen alle Verzeichnisse durch den Webserver User (i.d.R. sind es die Other Rechte) mit x markiert sein.


    DocumentRoot "local/var/www"
    <Directory "local/var/www">

    Da fehlt der führende / <Directory "/usr/local/var/www">

    Ansonsten verschafft dir das Logfile einen genaueren Einblick.

  • Wenn deine aufgerufene Datei /var/www/index.html sei, müssen alle Verzeichnisse durch den Webserver User (i.d.R. sind es die Other Rechte) mit x markiert sein.


    Da fehlt der führende / <Directory "/usr/local/var/www">

    Ansonsten verschafft dir das Logfile einen genaueren Einblick.

    Die Verzeichnisrechte sind im Moment 775. Eigentlich müsste das richtig sein, aber es könnte trotzdem falsch sein, da aktuell in der httpd.conf als User und Gruppe für den Apache "_www" definiert ist, was dem Standardwert entspricht. Soll wohl aus Sicherheitsgründen so sein, dass der Prozess einen eigenen Usernamen bekommt.


    Müsste ich dann nicht das www-Verzeichnis auf "_www" als Besitzer umstellen, damit der Prozess drauf zugreifen kann? *grübel*


    Laut httpd.conf Begleittext ist das fehlende anführende / korrekt - Pfade mit fehlendem anführenden / werden immer durch den ServerRoot ergänzt, welcher /usr ist.

  • UPDATE


    Ich bin nun einen Schritt weiter, bekomme aber nun von Lets Encrypt bzw. certbot folgende Fehlermeldung:

    Code
    1. Waiting for verification...
    2. Cleaning up challenges
    3. Created an SSL vhost at /private/etc/apache2/httpd-le-ssl.conf
    4. Cannot find an SSLCertificateFile directive in /files/private/etc/apache2/httpd-le-ssl.conf/IfModule/VirtualHost. VirtualHost was not modified
    5. Unable to find an SSLCertificateFile directive
    6. IMPORTANT NOTES:
    7. - Unable to install the certificate

    Funfact: Unter dem angegebenen Pfad finde ich keine httpd-le-ssl.conf Datei.


    Außerdem wundert mich das /files/ Präfix im zweiten Pfad, was für mich gar keinen Sinn ergibt.


    Die Challenge-Daten wurden tatsächlich nun im Standard-Ordner /Users/username/Sites/ angelegt und erfolgreich geprüft. Wenn ich aber auf die Website zuzugreifen versuche, bekomme ich weiterhin den 403 Fehler.

  • Laut httpd.conf Begleittext ist das fehlende anführende / korrekt - Pfade mit fehlendem anführenden / werden immer durch den ServerRoot ergänzt, welcher /usr ist.

    Mag sein, dass es funktioniert. Ich finde es aber verwirrend und würde es nicht nutzen. Absolute Pfade sind in dem Fall deutlich weniger Fehleranfällig.


    Kann sein, dass dein LE Prozess keine Schreibrechte hat auf: /private/etc/apache2/httpd-le-ssl.conf ?