UCS Reverse Proxy SSL

UCS - Univention Corporate Server
#1

Hallo,

Ich versuche schon seit Tagen den UCS-Master dazu zu überreden, dass wenn “https://cloud.domain.de” aufgerufen wird, der UCS das weiter leitet zur “NAS” (eigenständiger Server im NW)mit der Cloud drauf.

Ich habe mir auch schon diesen Post angeschaut
( Reverse proxy forwarding to a 2end Server )
Leider bekomme ich immer Zertifikatsfehler.
Ich kann erst gar nicht die Webseite besuchen.

Wenn ich dazu die Let´ Encrypt App starte und “cloud.domain.de” verifizieren will, bekomme ich diesen Fehler:

Traceback (most recent call last):
File “/usr/share/univention-letsencrypt/acme_tiny.py”, line 198, in
main(sys.argv[1:])
File “/usr/share/univention-letsencrypt/acme_tiny.py”, line 194, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)
File “/usr/share/univention-letsencrypt/acme_tiny.py”, line 123, in get_crt
wellknown_path, wellknown_url))
ValueError: Wrote file to /var/www/.well-known/acme-challenge/EsP2vIuoH_ZVaI5EIAJDwRqanw5Ur3_rtb6PMWSiHHE, but couldn’t download http://cloud.domain.de/.well-known/acme-challenge/EsP2vIuoH_ZVaI5EIAJDwRqanw5Ur3_rtb6PMWSiHHE

“domain” ist natürlich ein Platzhalter für meine eigene Domain.

Kann mir jemand erklären, was ich das Falsch mache?
Ich muss zugeben, dass ich mit dem Reverse Proxy nicht vertraut bin.
Vielleicht hat einer eine Step-by-Step Anleitung?

Anbei noch fix die cloud.domain.de.conf

<VirtualHost *:80>
ServerName cloud.domain.de

    Redirect / https://cloud.domain.de/nextcloud

<VirtualHost *:443>
ServerName cloud.domain.de
SSLEngine on
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLCertificateFile /etc/univention/letsencrypt/signed.crt
SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
SSLCACertificateFile /etc/univention/letsencrypt/chained.pem

    #SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

    ### To enable special log format for HTTPS-access
    # LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %p" combinedssl
    # CustomLog /var/log/apache2/access.log combinedssl     ## with port number

    RedirectMatch ^/$ /nextcloud/

    ProxyPass /nextcloud/ http://10.0.0.253/nextcloud/
    ProxyPassReverse /nextcloud/ http://10.0.0.253/nextcloud/

Frohes neues Jahr und
viele Grüße

#2

Hallo,

das Problem ist wohl auch hier, dass während der Erstellung bzw. Verifizierung der Lets Encrypt Zertifikate die Challenge in das lokale Dateisystem geschrieben wird und dann via http heruntergeladen werden soll. Letzteres funktioniert aber nicht da der effektive Zugriff auf ein anderes System erfolgt.

Entweder man macht die Zertifikatsprozedur auf dem NAS oder man sieht zu, dass die von den UCS-Skripten lokal nach /var/www/.well-known/acme-challenge geschriebenen Dateien auch extern für alle Lets Enrypt Domains/Hosts erreichbar sind. Mit einem globalen ‘Redirect’ geht das nicht. Da müsste man Ausnahmen definieren, wobei ich leider aus dem Stehgreif nicht sagen kann, wie man das macht.

Viele Grüße,
Dirk Ahrnke

#3

Hallo, Danke zuerst für die Info.
Okay Habe verstanden, und Natürlich die certs auf der nas gebaut.
Das klappt nun.

Allerdings bekomme ich trotzdem certs Probleme bei dem redirect.

Ich bräuchte also nur einen funktionierenden redirect auf dem ucs, richtig?

Grüße

#4

Was sind denn das für konkrete Probleme?
Sprich:
Bei welcher Aktion treten die Probleme auf?
Wie äußern sie sich?
Was steht in den Logs vom UCS-Apache?
Was kommt auf dem NAS im Webserver und der Applikation an (wenn überhaupt)?

#5

Hallo ahrnke,
Zuerst einmal ganz lieben Dank für die Hilfe und anteilnahme!

Jetzt zu Deinen Fragen…
Aus der “error.log” des UCS-Master steht folgendes:

[Thu Jan 11 19:16:08.652623 2018] [mpm_prefork:notice] [pid 5995] AH00171: Graceful restart requested, doing restart
[Thu Jan 11 19:16:09.056244 2018] [ssl:warn] [pid 5995] AH01909: cloud.domain.de:443:0 server certificate does NOT include an ID which matches the server name
[Thu Jan 11 19:16:10.001121 2018] [mpm_prefork:notice] [pid 5995] AH00163: Apache/2.4.10 (Univention) OpenSSL/1.0.2k configured – resuming normal operations
[Thu Jan 11 19:16:10.001140 2018] [core:notice] [pid 5995] AH00094: Command line: ‘/usr/sbin/apache2’

Wenn ich die Seite aufrufe, dann ist das Cert nicht gültig
Kurzbeschreibung aus Chrome:
Sie können die Webseite nicht aufrufen, das sie HSTS verwendet"
Reicht die Kurzfassung dazu?

Auf der NAS im Apache steht:
cat /var/log/apache2/error.log
[Thu Jan 11 06:25:02.308382 2018] [mpm_prefork:notice] [pid 1016] AH00163: Apache/2.4.25 (Debian) OpenSSL/1.0.2l configured – resuming normal operations
[Thu Jan 11 06:25:02.308409 2018] [core:notice] [pid 1016] AH00094: Command line: ‘/usr/sbin/apache2’

Brauchst Du noch die “access.log”?
Ich hoffe, ich konnte es “gut” berichten? :open_mouth:
Natürlich, wenn das hier klappt auch gerne PM Nachrichten. Dann kölnnte man die Webseitenadresse auch ausschreiben?

Herzliche Grüße

#6

Hallo,

die access.log(s) wären in der Tat mit Sicherheit etwas aussagekräftiger da nur dort die effektiven Zugriffe zu sehen sind, es sei denn, der Apache hat bei der Verarbeitung selbst ein Problem.
Der Zugriffstest mit Chrome ist von der Herangehensweise insofern weniger ausagekräftig, da gerade dieser Browser etwas wählerisch ist wenn irgendetwas an den Zertifikaten nicht stimmt. Das ist hinsichtlich der besseren Sicherheit für Otto Normal sicher angebracht, fürs Debuggen aber etwas hinderlich Man muss dann schon genau wissen, wie man diese Abwehrreaktion zu interpretieren hat.
Hilfreicher bei der Fehlersuche sind Tools wie openssl, z.B.:

openssl s_client -connect meinserver.domain.de:443

Zum einen sieht man die präsentierte Zertifikatskette (ggf. auch noch -showcerts nehmen), zum anderen sieht man im access.log den Zugriff und kann nachvollziehen, was der Webserver tut. Wenn man möchte, kann man noch wie ein Client mit dem Webserver reden und eine Seite anfordern (siehe z.B. TCP Port 443 (https) Zugriff mit openssl überprüfen).

Ich bitte um Verständnis, dass ich hier keinen direkten Support über PM machen möchte. Das würde sowohl unsere eigenen als auch die kommerziellen Supportangebote von Univention und anderen Univention-Partnern torpedieren. Stattdessen sind die Aktionen hier als “Hilfe zur Selbsthilfe” und für die Community nachvollziehbar und nachnutzbar gedacht.

Viele Grüße,
Dirk Ahrnke

Mastodon