Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM 9.6 Lets Encrypt Zertifikate

Hallo Zusammen.

Die 9.6er Version hat ja die Möglichkeit lets encrypt Zertifikate zu verwalten.

Ich habe folgendes  Problem.

Hinter der Sophos ist ein Nextcloud Server, die über HTTPS läuft und laufen muss.

Bisher musste ich die Zertifikate manuel, durch eine Nat Regel aktualisieren.

Wie kann ich das da mit den Zertifikaten realisieren? Ich benötige ja das Zertifikat in der Sophos auf dem Nextcloud Server?

Vielen Dank im Voraus!



This thread was automatically locked due to age.
  • Hi Robert,

    die UTM kann Zertifikate über Let's Encrypt erzeugen, die durch sämtliche Module der UTM verwendet werden können.

    Wenn deine Nextcloud per DNAT veröffentlicht ist, hast du nichts davon.

    Wenn du deine Nextcloud statt per DNAT über die WAF veröffentlichst, kannst du im Virtuellen Webserver das Let's Encrypt Zertifikat verwenden.

    Dann nimmst du für die Kommunikation zwischen Nextcloud und UTM etwas selbstsigniertes und nach draußen das öffentliche.

    Alternative per UTM das Zertifikat erzeugen, exportieren und im Nextcloud einspielen - müsstest du monatlich von Hand machen.

     

    Gruß Lukas

    lna@cema

    SCA (utm+xg), SCSE, SCT

    Sophos Platinum Partner

  • Hallo Lukas.

    Danke dir für die Antwort.

    DNAT aktiviere ich nur, um die Zertifikate monatlich zu aktualisieren.

    Das Problem mit zwei verschiedenen Zertifikaten ist zum Beispiel, dass in der Nextcloud der DAV Dienst nicht mehr funktioniert, weil das Eingangszertifikat in der Sophos anders ist als das auf dem Webserver.

    Ich verstehe dann den Sinn nicht ganz, wozu Sophos diese Funktion eingebaut hat, nur um das Zertifikat für die UTM aktuell zu halten? Die Systeme dahinter wurden da wohl vernachlässigt?

     

  • Hallo Robert,

    Sophos bietet das WAF Modul an, um unsichere Services sicherer veröffentlichen zu können.

    Zielsysteme sind also welche, die entweder nur Klartext können, oder die so unsauber programmiert sind, dass man sich ohne einen gehärteten Reverseproxy nicht traut diese im Internet zu betreiben.

    Zweite Zielgruppe sind Umgebungen mit nur einer öffentlichen IP aber mehreren zu veröffentlichenden Services (Content Switching).

    Dass zwei verschiedene Zertifikate verwendet werden ist in kleineren Umgebungen auch nicht unüblich (ein internes für den internen fqdn und an der WAF ein externes für den externen).

     

    Woran machst du fest, dass DAV ein Problem damit hat?

     

    Gruß Lukas

    lna@cema

    SCA (utm+xg), SCSE, SCT

    Sophos Platinum Partner

  • Hallo  Lukas,

    danke dir für deine Erklärung.

    Diese Meldung findet man in den Nextcloud-Einstellungen, wenn man von Extern auf die Cloud zugreift.

     


    Wenn ich jedoch Lokal auf diese Cloud zugreife ist diese Meldung nicht vorhanden.

     

     

    Hier habe ich folgendes gefunden:

    https://forum-raspberrypi.de/forum/thread/10707-webdav-vermutlich-defekt/?postID=92407#post92407

  • Die Owncloud sollte Zertifikatsthemen nur mitbekommen wenn sie entweder auf SSL-Ebene versucht mit dem Client zu kommunizieren (SSL Cert-Auth) oder wenn sie versucht Hostnames aus den Headern gegen das eigene Zertifikat oder den eigenen Hostname zu prüfen.

     

    Stimmt der Hostname im Zertifikat der owncloud mit dem überein, was von extern aufgerufen wird? funktioniert der Aufruf von Intern (wenn ja, mit dem Selben Namen wie von extern?)

    Verwendest du Zertifikatsauthentifizierung?

     

    Gerade mal durch ein paar Owncloud Forenbeiträge geflogen zum Theme Cert Auth bei DAV

    folgende Konfig Datei:

    /var/www/owncloud/3rdparty/Sabre/DAV/Client.php

    diese Parameter:

    CURLOPT_SSL_VERIFYPEER

    CURLOPT_SSL_VERIFYHOST

    lna@cema

    SCA (utm+xg), SCSE, SCT

    Sophos Platinum Partner

  • ich habe den Owncloud Link nur als Beispiel eingefügt, weil Nextcloud auf Owncloud aufsetzt.

     

    Was genau meinst du mit Zertifikatsauthentifizierung? Wo genau?

     

    der hostname intern ist genau der selber wie extern. eher gesagt, intern sind es ja auf dem linux server eigene domains die aufgerufen werden cloud.xxx-xxxx.de zum beispiel. genauso ist die domain auch von extern erreichbar und für diese domain wurde auch das zertifikat registriert.

     

    im Virtuellen Webserver für Nextcloud ist "Host-Header durchreichen" aktiv.

  • lna said:

     

    Alternative per UTM das Zertifikat erzeugen, exportieren und im Nextcloud einspielen - müsstest du monatlich von Hand machen.

     

     

    Hi,

    ich hab das bei mir folgendermaßen gelöst:

    - Abruf und Vergleich der Zertifikate extern und intern

    - wenn unterschiedlich, dann Erneuerung des lokalen Zertifikats durch script

    Und so hab ich es praktisch umgesetzt (Farbiges ist zu ersetzen):

    - ssh zur UTM, dann sudo su

    - mkdir /root/.remotecmd

    - mkdir /root/.remotecmd/WWW.MEINEDOMAIN.DE

    - touch /root/cmp-cert.sh

    - chmod 700 /root/cmp-cert.sh

    - vi /root/cmp-cert.sh

    DOM=$1
    LOC=$2
    openssl s_client -connect $DOM:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' >cert_dom.pem
    openssl s_client -connect $LOC:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' >cert_loc.pem
    cmp cert_dom.pem cert_loc.pem >/dev/null
    rc=$?
    if [ $rc -eq 0 ];
    then
      echo "gleich" >/dev/null;
    else
      echo "ungleich";
      /root/.remotecmd/$DOM/remotecmd.sh $DOM $LOC
    fi

    - touch /root/.remotecmd/WWW.MEINEDOMAIN.DE/remotecmd.sh

    - chmod 700 /root/.remotecmd/WWW.MEINEDOMAIN.DE/remotecmd.sh

    - REF_MEINEDOM.key und REF_MEINEDOM.pem ermitteln:

    #/usr/local/bin/confd-client.plx
    127.0.0.1 MAIN > OBJS
    Switched to OBJS mode.
    127.0.0.1 OBJS > ca
    127.0.0.1 OBJS ca > host_key_cert
    127.0.0.1 OBJS ca host_key_cert >

    pres tab twice to show the list of all certificates

    from the list find the certificate you want to write the Let's Encrypt certificate in.

    Copy everything upto the [ sign. We will use this reference in the next step

    For example:

    REF_CaHosLetsEncryp[Let's Encrypt,ca,host_key_cert]

    The reference to use is: REF_CaHosLetsEncryp

     

    - vi /root/.remotecmd/WWW.MEINEDOMAIN.DE/remotecmd.sh

    DOM=$1
    REMOTE_SERVER=$2
    REMOTE_USER="root"
    REMOTE_PATH="/etc/letsencrypt/live" # SSL-Pfad für NGINX
    LOC_PATH="/var/storage/chroot-reverseproxy/usr/apache/conf/ssl" #Pfadinhalt wohl erst nach Zertifikatszuweisung verfügbar
    LOC_PRIVKEY="REF_MEINEDOM.key" # s.o.
    LOC_CERT="REF_MEINEDOM.pem" # s.o.

    scp $LOC_PATH/$LOC_PRIVKEY $REMOTE_USER@$REMOTE_SERVER:$REMOTE_PATH/$DOM/privkey.pem >/dev/null
    scp $LOC_PATH/$LOC_CERT $REMOTE_USER@$REMOTE_SERVER:$REMOTE_PATH/$DOM/fullchain.pem >/dev/null

    ssh $REMOTE_USER@$REMOTE_SERVER systemctl restart nginx

    - vi /etc/crontab-static

    54 2 * * * root /root/cmp-cert.sh WWW.MEINEDOMAIN.DE nexctcloud.domain.local

    - reboot

     

    Wenn das noch jemand optimieren möchte, nur zu! Am besten wäre aber eine "offizielle" Lösung...

  • Es gibt eine offizielle Lösung: die REST-API der UTM. Über die kann man das komplette Let's Encrypt-Zertifikat aus der UTM abrufen und weiterverwenden.

    Ich habe mir hierzu ein kleines Bash-Script geschrieben, das man auf dem Nextcloud-Server laufen lassen kann. Siehe: community.sophos.com/.../let-s-encrypt-used-for

    ----------
    Sophos user, admin and reseller.
    Private Setup:

    • XG: HPE DL20 Gen9 (Core i3-7300, 8GB RAM, 120GB SSD) | XG 18.0 (Home License) with: Web Protection, Site-to-Site-VPN (IPSec, RED-Tunnel), Remote Access (SSL, HTML5)
    • UTM: 2 vCPUs, 2GB RAM, 50GB vHDD, 2 vNICs on vServer (KVM) | UTM 9.7 (Home License) with: Email Protection, Webserver Protection, RED-Tunnel (server)