Univention 4.2 und Letsencrypt

UCS - Univention Corporate Server
, ,
#1

Bisher hatten wir bei univention 4.1 den Certbot im Einsatz, mit dessen Hilfe wir einfach so viele Zertifikate erstellt haben wie benötigt um diese anschließend entsprechend in den Apache Configs zuweisen zu können. Da Certbot sich unter Univention 4.2 als momentan nicht installierbar erwiesen hat sind wir auf diese Methode ausgewichen:

http://wiki.univention.de/index.php?title=Cool_Solutions_-_Let's_Encrypt

Funktioniert soweit auch perfekt, nur haben wir zusätzliche Subdomains die wir benötigen z.B. ox. und dav.. Wenn wir in der UCS registry zusätzlich die Domains unter: letsencrypt/domains eintragen, dann bricht der Befehl: /usr/share/univention-letsencrypt/setup-letsencrypt jetzt mit der folegenden Meldung ab und die subdomain wird nicht mit einem Zertifikat versehen:

Verifying ox.#########.de...
Traceback (most recent call last):
  File "/usr/share/univention-letsencrypt/acme_tiny.py", line 198, in <module>
    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/WKJLKpYy-y2w6VPgA7DdH9AvxZ7SUT746HqATRxduMA, but couldn't download http://ox.########.de/.well-known/acme-challenge/WKJLKpYy-y2w6VPgA7DdH9AvxZ7SUT746HqATRxduMA
Setting apache2/force_https
File: /etc/apache2/mods-available/ssl.conf
Module: ox-config

Wir haben die virtuellen Domains in den Apache Configs genauso angelegt wie schon unter 4.1. und unser System reagiert auch entsprechend auf die URL http://ox.###### - nur ist das Letsencrypt Modul scheinbar nicht in der Lage die Domain entspechend zu verarbeiten.

#2

Hab einen ähnlichen Fehler…

Verifying domain.de...
Traceback (most recent call last):
  File "/usr/share/univention-letsencrypt/acme_tiny.py", line 198, in <module>
    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/TRaiX2YCFZIMxFSIq3vplydxARybFaMG1wKNAFpnmG4, but couldn't download http://domain.de/.well-known/acme-challenge/TRaiX2YCFZIMxFSIq3vplydxARybFaMG1wKNAFpnmG4
#3

Yep… das ist das selbe Problem. Zumindest komme ich mir jetzt nicht mehr so doof vor :slight_smile:

1 Like
#4

Auch wenn es das Problem mit univention-letsencrypt nicht wirklich löst

Ich habe es auf einem Kopano Mailserver vor einiger Zeit mit dehydrated gelöst.

Dehydrated ist ein rein in bash geschriebener letsencrypt client der keine Abhängigkeiten mitbringt.

Solltet ihr das versuchen wollen:

Git repo ziehen:

su -l root
cd ~/
git clone https://github.com/lukas2511/dehydrated.git
cd dehydrated

Register acc:

./dehydrated --register --accept-terms

Create cfg

echo WELLKNOWN="/var/www/.well-known/acme-challenge" > config.sh

Request cert

./dehydrated -d deinedomain --config config.sh

Im fall von Kopano sind das diese ucr vars:

apache2/ssl/certificate: /root/dehydrated/certs/deinedomain/cert.pem
apache2/ssl/certificatechain: /root/dehydrated/certs/deinedomain/chain.pem
apache2/ssl/key: /root/dehydrated/certs/deinedomain/privkey.pem
kopano/cfg/gateway/ssl_certificate_file: /root/dehydrated/certs/deinedomain/fullchain.pem
kopano/cfg/gateway/ssl_private_key_file: /root/dehydrated/certs/deinedomain/privkey.pem
kopano/cfg/ical/ssl_certificate_file: /root/dehydrated/certs/deinedomain/fullchain.pem
kopano/cfg/ical/ssl_private_key_file: /root/dehydrated/certs/deinedomain/privkey.pem
kopano/cfg/server/server_ssl_ca_file: /root/dehydrated/certs/deinedomain/fullchain.pem
mail/postfix/ssl/certificate: /root/dehydrated/certs/deinedomain/fullchain.pem
mail/postfix/ssl/key: /root/dehydrated/certs/deinedomain/privkey.pem

Apache, Kopano etc neu starten
service apache2 restart && service kopano-server restart && service postfix restart

Mein Crontab Eintrag:

30 2 * * 1 /root/dehydrated/dehydrated --cron --config config.sh && service apache2 restart && service kopano-server restart && service postfix restart >> /dev/null

Ich hoffe das hat euch geholfen.
Bei Fragen dürft ihr mich gerne kontaktieren.

Gruß Martin

1 Like
#5

Danke Dir npanic für Deinen Vorschlag…
Klingt interessant und ist sicher eine alternative Lösung, bin nur keine Freundin von zu vielen Änderungen in der ucr im Hinblick auf kommenden UCS Updates wäre eine Lösung eines eventuellen Bug lieber…

Gruß Carmen

#6

Hallo,

die genannte Cool Solution bzgl. Let’s Encrypt ist bislang nur für UCS 4.1 getestet und freigegeben. Mit dem Upgrade auf UCS 4.2 wurde auch Apache von 2.2 auf 2.4 aktualisiert und ich will nicht ausschließen, dass da jetzt was krumm ist.
Ich frag mal intern den Status an bzgl. Update der Cool Solution auf UCS 4.2

PS: Es wäre super, wenn zukünftige Topics entsprechend unserer Posting Guidelines in Englisch erstellt werden - dann haben mehr Leute was davon :slight_smile:

Gruß, Michael

1 Like
#7

Hi Martin,

danke vielmals. Ich hab von dehydrated schon gehört, wussten aber nicht dass es sich hier um ein reines bash Script handelt. Auf solche Lösungen steh’ ich. :wink:

Werden dass ausprobieren bis Michael bzgl. Cool Solutions was Neues hat. Vielleicht funktioniert ja auch dass irgendwann mal.

Cheers

1 Like
#8

Hi Michael,

ich hab’ mich schon gewundert daß viele Topics auf Deutsch geschrieben sind. Deswegen habe ich mir nichts dabei gedacht. Sorry deswegen.

Auch wenn ich Euch bzgl. Englisch voll verstehen kann, muss ich ganz egoistisch zugeben, daß es manchmal einfach besser ist sich in seiner Muttersprache zu verständigen, gerade wenn’s brennt und der Nerv zum englisch schreiben durchgeschmort ist :wink:

Nichts für ungut deswegen - und die Community hier ist einfach nur exquisit.
Cheers
Nick

2 Likes
#9

Any news about this topic?

#10

Kurze Frage, habt Ihr Port 80 freigegeben, glaube den braucht es zur Verifizierung der Domains

#11

Die “normalen” Maildomains werden ja auch korrekt erkannt. Nur zusätzliche subdomains nicht. z.B. die subdomain ucs.* wird durch das Tool normal verwaltet. Wenn wir jetzt eine zusätzliche Subdomain ox. oder dav. anlegen und entsprechen bei Letsencrypt konfigurieren, dann bricht es bei diesem ab.

#12

Hallo,

die Let’s Encrypt Cool Solution für 4.2 ist inzwischen auf dem Weg. Wenn nichts dazwischen kommt, gibt’s die noch im Mai.

@theodor.m: Ja, Port 80 muss von den Let’s Encrypt API-Servern aus erreichbar sein.

1 Like
#13

danke dir, irgendiw hat es bei uns auch mit der 4.1 nun geklappt, nachdem der Port 80 offen war…

#14

Hört sich gut an. Vielleicht löst dass ja das Problem mit den zusätzlichenSubdomains

#15

Hallo,
Gibt´s schon Neuigkeiten bzgl. diesem Thema?

#16

Guten Tag, gibt es ein Update ueber den Status dafuer? Gruss Alex

#17

Diese Cool Solution durchläuft im Moment einen QA-Prozess. Ich kann nicht genau sagen wann dieser abgeschlossen ist würde aber diese und nächste Woche ein Auge nach neuen Paketen und einer Wiki Aktualisierung offen halten.

#18

Gibt es Neuigkeiten dazu? Ich bräuchte die Lösung :-/

#19

Ich meine eigentlich dass es hierzu bereits ein Update gibt, also die Cool Solution ist soweit durch.

#20

Hallo zusammen,

Wie kann ich zwischendurch die Letsencrypt Zertifikate manuell aktualisieren?

Gruß Carmen

Mastodon