Jump to content
Froxlor Forum

chrisiwien

Members
  • Posts

    70
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by chrisiwien

  1. Hallo d00p!

    Ich möchte das froxlor-Backend über ein Lets Encrypt-Zertifikat absichern. Die notwendigen Einstellungen in den "Froxlor Virtual Host Einstellungen" habe ich vorgenommen, Häkchen bei "Lets Encrypt verwenden" und "SSL-Weiterleitung" aktiviert.

    Der Froxlor-Cronjob wirft aber diese Meldungen aus:

    [error] Could not find file '[server-domain].cer' in '/root/.acme.sh/[server-domain]/'
    [error] Could not find file 'ca.cer' in '/root/.acme.sh/[server-domain]/'
    [error] Could not find file 'fullchain.cer' in '/root/.acme.sh/[server-domain]/'
    [error] Could not get Let's Encrypt certificate for [server-domain]:

    Im Ordner root/.acme.sh/[server-domain]/ sind nur diese Dateien zu finden:

    [server-domain].conf
    [server-domain].csr
    [server-domain].csr.conf
    [server-domain].key


    Was mache ich falsch?

  2. Ja eh. Da ich nur gelegentlich mit Server-Arbeit konfrontiert bin habe ich aus unerfindlichen Gründen nicht die Vorgehensweise vom funktionierenden Server übernommen. Blöd.

    Ich werde versuchen vor dem nächsten Zert-Update das mit den Domains zu ändern. Ich sehe mich aber so gegen Mitte März 2021 wieder auf schrill gebürstet im Forum posten...*seufz*

    Danke für die Antworten jedenfalls!

  3. Sorry, hab Dein vorletztes Mail mit den vielen Erklärungen übersehen.

    "Nein, ein Alias bedeutet nur, dass der apache vhost nur 1x generiert wird, in erster linie für domain.tld und dann als alias (ServerAlias direktive) auch für www.domain.tld - das impliziert keinen redirect - der vhost reagiert nur auf beide urls".
    Der vHost reagiert nur auf beide urls - ja dann - aber dann ist das Ergebnis doch das gleiche wie bei Anlegen einer www-Domain und redirect auf non-www?? So klappt das zumindest auf dem Server wo es keine Zert-Probleme gibt - wo ich auch nur die non-www-Domain angelegt habe.

    "auch hier wieder, ssl-redirect heisst: leite http auf https um, NICHT leite www auf non-www" - ja logisch. Was ist meinte ist: wenn ich in den Froxlor-Settings "leite http auf https um" wähle brauche ich das nicht mehr in der htaccess manuell einzustellen.

     

    Wichtig ist nur dass bei Aufruf von www und non-www der selbe Inhalt erscheint (aus der selben document-root). Je mehr redirects man sich sparen kann desto besser!

  4. Ich sehe das "hallo". Der Redirect geift also. Aber was mich trotzdem stutzig macht: Der Froxlor-Mastercronjob führt ja die Let's Encrypt-Anfragen aus, also auch für den FDQN "www.domain.com". Let's Encrypt bekommt aber dank der Weiterleitung "domain.com" präsentiert. Das macht einen Unterschied, oder?

    Im Ordner root/.acme.sh liegen jetzt im Ordner "domain.com" keine Zertifikatsdateien. Im Ordner "www.domain.com" sehr wohl. Beim vorigen Zertifikatslauf waren aber auch im Ordner "domain.com" Zertifikatsdateien.

    Es ist zum schreien. Aber ich tippe auf den unnötig komplizierten Redirect der da den Hund reinhaut.

  5. Tja, das ist der Einstellungsdschungel in dem ich nicht ganz durchblicke...

    Mein Ziel ist es ja dass die automatische Zertifikatserneuerung funktioniert.

    Ok, ich versuch es zu erklären:

    • Ich habe die www und die non-www-Domain in Froxlor eingerichtet. Das Ziel war aber IMMER dass die www-Domain zur non-www-Domain umgeleitet wird.
    • Ich dachte mir es ist richtig wenn ich auch die www-Domain mit einem Zertifikat absichere, obwohl die auf die non-www-Domain weiterleitet. Ist das richtig? Oder bräuchte die www-Domain gar kein Zertifikat, da die eh auf die non-www-Domain MIT Zertifikat umleitet?
    • Bei der non-www-Domain habe ich "Keine Aliasdomain" und "Keine Subdomain einer Hauptdomain" ausgewählt. (keinen www-Alias eingestellt)
    • Bei der www-Domain habe ich "Keine Aliasdomain" und ("ist eine Subdomain von") "domain.com" ausgewählt. (dort ist der www-Alias also eingestellt)
    • Nochmals die Frage zum FDQN: ist es überhaupt zulässig dass ich ein Zertifikat für "www.domain.com" erstelle UND eines für "domain.com"? Der FDQN ist ja bis auf das "www" gleich. Oder sehe ich das falsch?

    Fakt ist: ich habe auf dem Server wo die automatische Zertifikatserneuerung klappt nur die non-www-Domain mit einem www-Alias eingerichtet. Nach meinem Verständnis entspricht der www-Alias einem Redirect zur non-www-Domain. Ist das korrekt? Dann bräuchte ich ja keinen htaccess redirect von www auf non-www. 

    Auf dem Server wo die Zertifikatserneuerung funktioniert leite ich in der htaccess nur von http auf https um. Bräuchte ich aber auch nicht, da ich in Froxlor ja die SSL-Weiterleitung in der SSL-Rubrik einstellen kann....help!

    Ich kenn mich nicht immer aus was welche Einstellung tut... und kratzen kann man sich ja bekanntlich auch von links oder von rechts.

     

  6. Hallo d00p!

    Mir lässt das keine Ruh. Ich habe was entdeckt: die fragliche Domain auf dem nginx-Server hab ich doppelt eingerichtet: einmal als non-www-Variante, einmal als www-Variante.

    Die www-Domain leite ich auf die non-www-Domain um. Bei der www-Domain habe ich auch SSL aktiviert, auch bei der non-www-Variante. Ich blick das nicht ganz durch aber mein Hausverstand flüstert mir leise zu dass ich einen Blödsinn gemacht habe. Ein Zertifikat muss ja einen FDQN haben, www.domain.com und domain.com - der Name ist ja eigentlich gleich oder? Also daher könnte der Murks mit der nicht automatischen Zertifkatsverlängerung herrühren, hm. Was meinst Du?

    Hab auch grad auf meinen anderen Server geschaut, da hab ich nur die non-www-Domain angelegt und eine www-Alias dazu - das ist vmtl. die korrekte Lösung.

  7. Folgendes Verhalten: bei der Hauptdomain domain.com kann ich nicht auf die PHP-Dateien zugreifen (502 Bad Gateway) aber auf die statischen Dateien (Texte, Bilder) schon.

    Bei der Subdomain subdomain.domain.com leitet der Server ins Nirvana. Ohne Versuch gezielt eine Datei aufzurufen kommt ein 403er mit Dateiversuch ein 404er.

    Und in den Error-Logs ist nach wie vor permission denied zu finden.

  8. # /etc/nsswitch.conf
    #
    # Example configuration of GNU Name Service Switch functionality.
    # If you have the `glibc-doc-reference' and `info' packages installed, try:
    # `info libc "Name Service Switch"' for information about this file.
    
    passwd:         compat extrausers
    group:          compat extrausers
    shadow:         compat extrausers
    gshadow:        files
    
    hosts:          files dns
    networks:       files dns
    
    protocols:      db files
    services:       db files
    ethers:         db files
    rpc:            db files
    
    netgroup:       nis

     

    Datei var/lib/extrausers/group:

    domain:x:10000:domain,www-data,froxlorlocal
    domain2:x:10001:domain2,www-data,froxlorlocal
    domain3:x:10002:domain3,www-data,froxlorlocal

    Ist das so richtig?

     

     

     

  9. 2020/12/16 22:06:12 [crit] 6725#6725: *3 connect() to unix:/var/lib/nginx/fastcgi/1-domain-domain.com-php-fpm.socket failed (13: Permission denied) while connecting to upstream, client: 80.109.49.138, server: domain.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/lib/nginx/fastcgi/1-domain-domain.com-php-fpm.socket:", host: "domain.com"

    und für eine subdomain.domain.com (da liegt eine Testseite):

    2020/12/16 22:06:10 [crit] 6725#6725: *1 stat() "/var/customers/webs/virtualbooth/index.php" failed (13: Permission denied), client: 80.109.49.138, server: virtual-booth.domain.com, request: "GET /favicon.ico HTTP/2.0", host: "virtual-booth.domain.com", referrer: "https://virtual-booth.domain.com/favicon-32x32.png"
     

    Der Froxlor-Admin läuft zum Glück. Da ist plötzlich in den vHosts ein Hund drinnen.

     

×
×
  • Create New...