Update 12.01.17: Dieser Artikel ist veraltet, hier gibt es eine aktuelle Version: Exchange 2016: Kostenlose Zertifikate von Let’s Encrypt
Seit einigen Tagen befindet sich die neue CA „Let’s Encrypt“ in der öffentlichen Beta Phase. Ziel von Let’s Encrypt ist es,auf einfache Weise SSL Zertifikate auszustellen. Die Zertifikate sind obendrein auch noch kostenlos.
Die CA wird bereits durch die meisten Browser unterstützt, da die Let’s Encrypt CA durch Identrust signiert wurde (Cross Signing).
Auch wenn es sich aktuell um eine Beta Phase handelt lassen sich die Zertifikate bereits für Exchange Testumgebungen nutzen, allerdings ist es aktuell noch etwas umständlich in Verbindung mit Exchange Server. Es gibt zwar einen Windows Client, aber der wollte auf meinem Testsystem nicht wirklich laufen. Wahrscheinlich muss noch ein bisschen Zeit ins Land ziehen, damit die Programme reifen können.
Da die Windows Clients noch nicht soweit sind, habe für diesen Test eine Ubuntu Server VM mit installiertem LAMP Stack benutzt. Der LAMP Stack ist eigentlich nicht erforderlich, aber ich hatte gerade nichts anderes zur Hand :-)
Für meinen Test verwende ich meine Domain frankysweb.com. Ich möchte für meinen Exchange Server ein Zertifikat ausgestellt bekommen, welches die folgenden DNS-Namen enthält:
- outlook.frankysweb.com
- autodiscover.frankysweb.com
Also ein klassisches SAN-Zertifikat mit zwei DNS-Namen.
Let’s Encrypt funktioniert etwas anders, als eine gewöhnliche CA. Bei den meisten CAs gibt es ein Webportal bei dem eine Zertifikatsanforderung (CSR) eingereicht werden muss. Bei Let’s Encrypt erledigt das ein Client. Daher benötigen wir zuerst den Client. Mit dem folgenden Befehl wird der Client aus dem GIT Repository runtergeladen:
git clone https://github.com/letsencrypt/letsencrypt
Sobald der Download fertiggestellt ist, kann in das Verzeichnis „letsencrypt“ gewechselt werden. In dem Verzeichnis befindet sich der Client.
Zunächst kann der Client mit dem Parameter –help aufgerufen werden, es werden dann noch fehlende Abhängigkeiten installiert:
An dieser Stellt haben wir jetzt also den Let’s Encrypt Client und alle Abhängigkeiten. Es gibt allerdings in diesem Fall ein paar Besonderheiten:
Der PC oder Server der das Zertifikat anfordert, muss unter den angeforderten Domainnamen per Port 80 aus dem Internet erreichbar sein. So wird durch Let’s Encrypt sichergestellt, dass man auch im Besitz der Domain ist, für die das Zertifikat angefordert wird (Domain Validation). Andere CAs schicken meist eine E-Mail mit einem Link an eine E-Mail Adresse wie postmaster@domain.de. Bei Let’s Encrypt übernimmt diese Funktion der Client.
Da auf meinem Testserver bereits ein Apache Server auf Port 80 hört, muss der Apache zunächst beendet werden, damit Port 80 für den Let’s Encrypt Client frei wird.
sudo service apache2 stop
Damit der Testserver unter dem Domain Namen autodiscover,frankysweb.com und outlook.frankysweb.com erreichbar ist, habe ich bei meinem Hoster die beiden Subdomains angelegt und auf meine WAN IP zeigen lassen:
An der Firewall habe ich dann Port 80 per DNAT auf meinen Testserver weitergeleitet.
Hinweis: Port 80 wird nur für die Anforderung benötigt, danach kann der Port wieder geschlossen werden.
Somit ist der Let’s Encrypt Client erreichbar und das Zertifikat kann angefordert werden:
/letsencrypt-auto certonly --standalone -d outlook.frankysweb.com -d autodiscover.frankysweb.com
Für Benachrichtigungen muss nur eine E-Mail Adresse angegeben werden:
und dann denn Terms of Service zugestimmt werden:
Nachdem das Zertifikat ausgestellt wurde, wird es Ordner /etc/letsencrypt/live/<DomainName> gespeichert:
Auf das /live Verzeichnis hat normalerweise nur der Benutzer root Zugriff, also mit folgendem Befehl als root Benutzer anmelden:
su -
Jetzt kann in das entsprechende Verzeichnis gewechselt werden. Dort finden sich jetzt unter anderem der Private Key (privkey.pem) und das Zertifikat (cert.pem):
Mit Zertifikaten im PEM Format kann Windows jedoch erst einmal wenig anfangen. Also wird das Zertifikat und der Private Key in das PKCS Format umgewandelt:
openssl pkcs12 -export -in cert.pem -inkey privkey.pem -out frankyweb.p12
Das Zertifikat kann jetzt am besten in das Home Verzeichnis kopiert werden, dann lässt sich einfach per WinSCP oder ähnlichem darauf zugreifen, ohne das die Berechtigungen für /etc/letsencrypt/live angepasst werden müssen.
cp frankyweb.p12 /home/frank/frankysweb.p12
Die .p12 Datei kann nun auf den Exchange Server übertragen werden. Am Einfachsten funktioniert das wohl per WinSCP:
Jetzt kann das Zertifikat importiert werden. Dazu kann eine MMC mit dem „Zertifikate“ SnapIn (lokaler Computer)geladen werden:
Hier kann nun die .P12 Datei importiert werden:
Ein Blick auf der Zertifikat bestätigt, das es gültig ist. Aktuell werden Zertifikate mit 3 Monaten Laufzeit ausgestellt:
Beide DNS-Namen sind enthalten:
IdenTrust (DST Root CA X3) hat die Let’s Encrypt Authority X1 signiert, daher ist dieses Zertifikat auf den meisten Browsern und Geräten gültig:
Jetzt noch dem neuen Zertifikat die Exchange Dienste zuweisen:
Fertig:
Das Zertifikat ist erst einmal 3 Monate gültig. Eine Erneuerung funktioniert ebenfalls über den Let’s Encrypt Client. Mal sehen ob nach der Beta Phase auch längere Laufzeiten möglich sind. Es wird sich bestimmt noch viel tun.
Zum produktiven Einsatz ist es noch nicht gedacht, aber für die eigenen Tests und Spielerein, warum nicht!?
Und vor allem: Kostenlose SAN-Zertifikate einfach per Windows Client anfordern und ggf. noch den IIS gleich mit konfigurieren lassen? Das wäre doch zu schön um wahr zu sein, oder? Genau so ist es aber von Let’s Encrypt vorgesehen. Es bleibt spannend.
Update 12.01.17: Dieser Artikel ist veraltet, hier gibt es eine aktuelle Version: Exchange 2016: Kostenlose Zertifikate von Let’s Encrypt
Hallo zusammen! Toller Artikel.
Wie ist der aktuelle Stand bezüglich eines Windows Clients?
LG Michael
Thank a lot Franky!
You are a Boss!
It’s work like a charm ;)
Anleitung funktioniert allerdings hate ich folgendes Problem.
Da mein Exchange lief hate er immer auf das aktuelle Zertifikat ( via 443) zugegriffen und da er die internen Domänen logischerweise nicht überprüfen konnte gabe es immer ein Problem.
Da gibt es allerdings einen FIX :
–standalone-supported-challenges http-01 to use port 80
–standalone-supported-challenges tls-sni-01 to use port 443
Über Port 80 gehts dann obwohl schon ein Zert via 443 dranhängt.
Der Rest war wie beschrieben.
Vielen Dank!
Uil
Hallo,
muss jeder der Domainnames per HTTP-80 erreichbar sein, die ins SAN soo? Wenn ja sind die Let’s Encrypt-IPs bekannt wo, von denen die Anfragen überprüft werden (Habe auf der LE-Seite nichts gefunden)?
Ich denke hier an einen Kunden mit mehreren Standorten, verbunden mit VPN-Tunneln für den viele DNS-Records und Firewallregeln notwendig wären, damit StandortA.FirmaA.tld auf einem zentralen System ankommt, dass die Zertifikatsanfragen stellt und dann auf die Exchange-Server verteilt.
Grüße
Steve
Geht auf jeden fall mit letsencrypt winsimple soeben getestet mit Sophos Webadmin. Erstellt unter Win10 mit Miniwebserver und NAT auf Port 80
Das Zertifikat hast du dann manuell im Webadmin auf der UTM hinterlegt? Kennst du einen Weg die Zertifikate automatisch zur UTM zu bringen?
Coole Anleitung. Vielen Dank.
Soweit ich gehört habe, soll es wohl bei den 3 Monaten Zertifikatgültigkeit bleiben. Hier sollen die Zyklen verkürzt werden um dadurch die Zertifikatsicherheit zu erhöhen.
Eine Zertifikatsverlängerung kann man sicher unter LAMP scripten und dann per Freigabe auf Windows ablegen. Und dort vielleicht per Powershell und Task aktivieren, zumindest bis ein vernüftiger Windows Client existiert.
Was mir noch fehlt ist eine Unterstützung durch die Sophos UTM WAF. Denn mein Exchange ist auch hier veröffenticht und da bringen die Exchange Let’s Encrypt Zertifikate nach außen nur einen ersten Schritt.
Viele Grüße
Nathan
Hi Nathan,
vielen Dank für die Info. Ich denke sobald es einen stabilen Windows Client gibt lässt sich das auch wunderbar per Script direkt auf dem Exchange Server erledigen. Könnte mir vorstellen ein kleines Powershell Script, welches täglich durch den Taskplaner aufgerufen wird, das Ablaufdatum des Zertifikats prüft und ggf. per Let’s Encrypt Client erneuert, dann kurz das Zertifikat an die Exchange Services bindet und fertig. Denke das ist gerade für kleine Umgebungen eine schöne Lösung. Ich werde das mal etwas im Auge behalten.
Der Let’s Encrypt Client ist in manchen Situationen natürlich Fluch und Segen zugleich, gerade bei Geräten wie Firewalls oder ähnlichem lässt sich kein Client nachinstallieren der sich dann um Zertifikate kümmert und alle 3 Monate zig Zertifikate manuell tauschen will man auch nicht. Andererseits macht es der Client natürlich einfach an Zertifikate zu kommen und auf Servern auszurollen.
Ich hab ebenfalls privat die Sophos UTM WAF im Einsatz, von daher werde ich mal schauen, wie ich da was automatisieren kann.
Schönes Wochenende,
Frank