Feature Anfrage: Let's encrypt

mschau · December 9, 2015, 2:27pm

Guten Tag!

Gibt es bereits Pläne zur Integration von “Let’s encrypt”?

Danke,
Markus

thorp-hansen · December 10, 2015, 1:11pm

Hallo,
Es gibt im Moment keine konkreten Pläne zur Integration von “Lets Encrypt”. Es gibt natürlich auch bei uns Diskussionen zu diesem Projekt. Wir konnten unter anderem folgende Punkte herausarbeiten:

Der offizielle LE-Client ist sehr groß und benötigt eine aktuelle Python3-Umgebung und enthält sehr viel Magie enthält (z.B. Zertifikate in Apache automatisch eintragen). Es gibt mittlerweile eine ganze Reihe von weiteren Clients, die z.B. nur aus 200 Zeilen Python-Code bestehen. Da könnte man noch sehr gut einen Code-Review machen und verstehen was das Tool wirklich macht. Siehe dazu auch:
community.letsencrypt.org/t/lis … tions/2103

Für die Verwendung von let’s encrypt muss das jeweilige System von extern erreichbar sein, damit die LE-Server das jeweilige System validieren können. Wildcard-Zertifikate werden nicht erlaubt, aber derzeit können bis zu 10 FQDNs/Subdomains für ein einzelnes Zertifikat eingetragen werden.

Jedes vergebene Zertifikat wird in eine öffentlich einsehbare Liste eingetragen, was bei internen UCS Systemen ist das vielleicht nicht unbedingt gewollt.

Mit freundlichem Gruß,
Jens Thorp-Hansen

t.gablunsky · January 27, 2016, 8:49am

Hallo,

also den Einwand mit den meist nicht extern erreichbaren Servern (u.a.) halte ich für nachvollziehbar.

Für unsere Anwendung (mit OpenXchange als Mailserver) sind die Server aber meist extern erreichbar. Und da Verschlüsselung heute nicht mehr optional ist, wäre ein solcher Schritt in Richtung Automatisierung hier sehr zu begrüßen! Die Möglichkeit, dieses Feature nicht zu benutzen, kann ja gern erhalten bleiben.

Schöne Grüße,
Tobias Gablunsky

digitec-san · March 19, 2016, 8:42am

Natürlich ist das Problem: Nicht von außen erreichbarer Host ein Problem aber ich sehe da einfache Möglichkeiten, z.B. mittels NAT und Reverse-Proxy.

Ich bin am Überlegen ob ich hierzu mal (privat) einen UCS Client entwickle. Aber ihr kennt das bestimmt mit der Zeit, die so ein Projekt verschlingt.

Interessant finde ich die Frage, ob man das ganze lieber zentral (die Zertifikats-Erstellung findet nur auf einem Rechner statt) oder dezentral (jeder der ein Zertifikat haben möchte erstellt es selbst) haben möchte.

Im Moment tendiere ich zu dem zentralen Ansatz, bei dem man den Zertifizierungs-Rechner mit dem Lets-Encypt Sign Key dann auch ausschalten kann und er in dieser Zeit nicht gehackt werden kann. Mittels wake-on-lan, Virtualisierung, Schaltzeituhr, (Papier-Kalender des Admins)… kann er dann einmal jeden Monat eingeschaltet werden, Updates installieren, Zertifikate erstellen, auf die Rechner verteilen und wieder ausgeschaltet werden.

Ich würde dann auf jedem Rechner eine Apache-Proxy-Rule einfügen. Ungefähr so:
ProxyPass “/.well-known/acme-challenge” ssl-siginin.domain.tld/letsencr … -challenge

Gibt es hierzu noch Anregungen?

tafkaz · September 8, 2016, 12:58pm

Moin!

Sind gerade auf der Suche nach einer guten Implementierung von Let’s encrypt für einen UCS / OX Master, der von aussen erreichbar ist.
Gibt es hierzu schon eine doku, oder einen Walkthrough?
Wollen möglichst unser UCS nicht durch etwaige Versuche zu einem Problembär werden lassen.
Danke
Sascha

tafkaz · September 9, 2016, 9:47am

hm,
nach ein wenig Recherche sieht es ja nicht so aus, als könnte man let’s encrypt einfach in Univention integrieren.
Weder python-letsencrypt-apache, noch certbot kommen wirklich ohne große Klimmzüge weiter.
Keine (einfache) Möglichkeit das zu nutzen?
Danke
Sascha

Schwardt · September 12, 2016, 4:18pm

Hallo Sascha,

Wir prüfen gerade die Möglichkeiten einer Veröffentlichung als Cool Solution. Stay tuned… (könnte aber noch den einen oder anderen Tag dauern).

Viele Grüße

Sönke

tafkaz · September 12, 2016, 4:19pm

Hi Sönke,
alles klar, wir freuen uns!

Danke
Sascha

ThorstenS · October 16, 2016, 7:43am

Ich habe die letzten Tage eine ansible Rolle dafür gebaut.
Zum Ausführen nehme ich unter debian/jessie ansible 2.1 aus den backports, sie sollte aber auch noch mit der 1.9 funktionieren.
Es wird das bash-Script (Version 0.3.1 ) von dehydrated.de benutzt - ohne weitere python Pakete, die der certbot verlangt.

Beim ucs System gibt es folgende Dinge, die man gegenüber einer normalen debian/ubuntu Installation beachten sollte:
[ul]
[li] bei aktiviertem apache2/force_https muss das Template /etc/univention/templates/files/etc/apache2/mods-available/ssl.conf eine Ausnahme für die URL /.well-known/acme-challenge/ bekommen¹[/li]
[li] die ucr Variablen apache2/ssl/certificate, apache2/ssl/key und apache2/ssl/ca müssen auf die letsencypt Dateien zeigen.² [/li][/ul]
Wie üblich muss gewährleistet sein, dass der Server per http und später https erreichbar ist. Das DNS System muss vorher alle gewünschten Servernamen auf die offizielle IP des Univention Systems auflösen.

In meiner ansible Rolle habe ich zum Testen per default die staging-API des letsencrypt Projekts aktiviert ( acme-v01.api.letsencrypt.org/directory die offz. Zertifikate anfordern.
Desweiteren lege ich einen cronjob an, der alle paar Tage ein dehydrated --cron ausführt. Aber erst nach 30 Tagen wird das Zertifikat wirklich erneuert, es besitzt ja eine Gültigkeit von 90 Tagen.
Für den URL http://$SERVERNAME/.well-known/acme-challenge/ lege ich einen Alias³ an, der nach /var/www/letsencrypt umleitet.
Ausserdem lese ich die ucr Variable mail/alias/root aus, um diese Mailadresse bei letsencrypt zu registrieren. Damit erhält man Statusmails wie z.B. dass die Zertifikate bald auslaufen.

Wenn Interesse an der Rolle besteht, gebe ich sie gerne weiter.
/thorsten

ad1)
Das hier kommt vor die Zeile mit dem server-status

Danach ein ucr commit /etc/apache2/mods-available/ssl.conf ausführen.

ad 2)

ucr set apache2/ssl/certificate="/etc/dehydrated/certs/first.domain.tld/cert.pem" ucr set apache2/ssl/key="/etc/dehydrated/certs/first.domain.tld/privkey.pem" ucr set apache2/ssl/ca="/etc/dehydrated/certs/first.domain.tld/chain.pem" service apache2 restart

ad3)
cat /etc/apache2/conf.d/letsencrypt-alias.conf

[code]
Alias /.well-known/acme-challenge “/var/www/letsencrypt”

vim: ft=apache ts=2:[/code]

alexboehm85 · October 18, 2016, 8:09am

Hallo Thorsten,

das klingt ja toll, endlich SSL verschlüsselte Kommunikation

Kannst du die Rolle hier posten?

Werde ich heute Abend direkt mal auf meinem System testen, und berichten, ob ichs hinbekommen hab

@Söhnke: Gibt es seitens Univention schon eine Lösung?

VG Alex

hbau · November 5, 2016, 9:55pm

Hallo Zusammen,

ich stand auch vor der Frage, wie ich letsencrypt nutzen kann.
Dabei habe ich folgendes zum laufen bekommen.
Mit dem alten letsencrypt Srcipt funktioniert es einwand frei.
Mit dem neuen certbot gibt es ettliche fehlende Packetabhängigkeiten.

Also habe ich unter mkdir /opt/letsencrypt den alten client installiert

git clone https://github.com/letsencrypt/letsencrypt

dann den verschiedenen einschlägigen Anleitungen folgen.

```
/etc/init.de/apache stop
```
```
/opt/letsencrypt/letsencrypt-auto
```

/opt/letsencrypt/letsencrypt-autp certonly -d your.domain.tld

Bei der Abfrage eMail angeben und den integrierten Webserver nutzen
neu erhaltene Zertifikate in Apache integrieren.
Dazu in der Univention Registry folgende drei Werte setzen:
appache2/ssl/ca = /etc/letsencrypt/live/your.domain.tld/chain.pem
appache2/ssl/certificate = /etc/letsencrypt/live/your.domain.tld/cert.pem
appache2/ssl/key = /etc/letsencrypt/live/your.domain.tld/privkey.pem
```
/etc/init.d/appache2 start
```

Danach noch die Autoerneuerung

in der weeklycron ein micro Script, welches den appache stoppt, das certifikat erneuert und appache wieder startet:

 vi /etc/cron.weekly/renw_ssl_letsencrypt

 #!/bin/bash
/etc/init.d/apache2 stop
/opt/letsencrypt/letsencrypt-auto renew
/etc/init.d/apache2 start

Viel Spass mit letsencrypt ssl Seiten.
Beste Grüße
HB

ThorstenS · November 7, 2016, 10:10am

wunderbar

Allerdings würde ich den neuen Namen des Scripts benutzen: dehydrated
Hier die Hintergründe: m.heise.de/security/meldung/Ino … 26837.html

Ein Hinweis noch für diejenigen, die ihrem Server den Zugriff nach aussen nur über einen Webproxy erlauben.
Man sollte eine /root/.curlrc mit folgendem Inhalt anlegen, damit die Aktualisierung auch über den cronjob erfolgen kann und nicht nur interaktiv, wenn eh die Umgebungsvariable http_proxy gesetzt ist

# /root/.curlrc proxy = http://proxyname.domain.tld:8080/

tafkaz · November 18, 2016, 2:36pm

hi, das klappt hier leider gar nicht…
/opt/letsencrypt/letsencrypt-auto und alles, was damit zusammenhängt gibt hier folgendes aus:

[code]Paket python-dev ist nicht verfügbar, wird aber von einem anderen Paket
referenziert. Das kann heißen, dass das Paket fehlt, dass es abgelöst
wurde oder nur aus einer anderen Quelle verfügbar ist.
Doch die folgenden Pakete ersetzen es:
python

Paket python-virtualenv ist nicht verfügbar, wird aber von einem anderen Paket
referenziert. Das kann heißen, dass das Paket fehlt, dass es abgelöst
wurde oder nur aus einer anderen Quelle verfügbar ist.

E: Für Paket »python-dev« existiert kein Installationskandidat.
E: Für Paket »python-virtualenv« existiert kein Installationskandidat.
E: Für Paket »dialog« existiert kein Installationskandidat.
E: Paket libffi-dev kann nicht gefunden werden.[/code]

hab ich was vergessen?

liebe Grüße

Sascha Zucca

SirTux · November 18, 2016, 2:51pm

ucr set repository/online/unmaintained=true

Später dann:

ucr set repository/online/unmaintained=false

tafkaz · November 18, 2016, 2:55pm

Ah, cool…
das scheint jetzt zu gehen.
Und an welcher Stelle in der Anleitung von hbau sollte ich jetzt den neuen Namen für das Skript (dehydrated) verwenden ?

Danke
Sascha

ThorstenS · November 21, 2016, 10:02am

anstelle von:
git clone github.com/letsencrypt/letsencrypt
besser:
git clone github.com/lukas2511/dehydrated

Das letztere Projekt ist aktiv betreut, das andere eben nicht mehr - der Autor ist beidesmal der gleiche.

tafkaz · November 21, 2016, 12:10pm

Perfekt,
Danke!
liebe Grüße

Sascha

tafkaz · November 25, 2016, 11:36am

hi,

nein leider doch noch nicht perfekt…
Wenn ich das mit dehydrated mache, dann hab ich keine letsencrypt-auto.
Muss ich mit dehydrated noch etwas kompilieren oder so?

Ich hatte mir folgenden funktionierenden Ablauf aufgeschrieben:

[code]- ucr set repository/online/unmaintained=true

cd /opt/
apt-get install git
git clone https://github.com/letsencrypt/letsencrypt
service apache2 stop
/opt/letsencrypt/letsencrypt-auto
/opt/letsencrypt/letsencrypt-auto certonly -d your.domain.tld
Bei der Abfrage eMail angeben und den integrierten Webserver nutzen
Neu erhaltene Zertifikate in Apache integrieren.
Dazu in der Univention Registry folgende drei Werte setzen:
apache2/ssl/ca = /etc/letsencrypt/live/your.domain.tld/chain.pem
apache2/ssl/certificate = /etc/letsencrypt/live/your.domain.tld/cert.pem
apache2/ssl/key = /etc/letsencrypt/live/your.domain.tld/privkey.pem
service apache2 start
vi /etc/cron.weekly/renew_ssl_letsencrypt
#!/bin/bash
/etc/init.d/apache2 stop
/opt/letsencrypt/letsencrypt-auto renew
/etc/init.d/apache2 start
ucr set repository/online/unmaintained=false
[/code]

Einfach den git Befehl ändern klappt aber dann so eben noch nicht.
Bin dankbar für Eure Hilfe

und noch etwas:
wie pflege ich dann diese Zertifikate auch für Dovecot / cyrus / postfix ein?

Danke
Sascha

tafkaz · November 28, 2016, 3:48pm

niemand?
Ein simples Howto für Let’s encrypt wäre doch grundsätzlich schon wünschenswert, oder?

Danke
Sascha

Atomius · February 3, 2017, 3:01pm

Würde mich grad auch interessieren, gibt’s da ne idiotensichere rund um sorglos Anleitung?