Let´s encrypt-Zertifikate automatisieren

Sparfüchse aufgepasst! 🙂 Sicher hat der ein oder andere schon von Let´s encrypt gehört: Eine tolle Sache! Kostenlose SSL-Zertifikate, die von allen gängigen Browsern als vertrauenswürdig angesehen werden, SAN support… ab 01/2018 sollen sogar Wildcard-Zertifikate unterstützt werden. Über z.B. SSLforFree lässt sich recht bequem arbeiten und man erhält vor Ablauf der Zertifikate eine Erinnerungsmail, praktisch. Mindestens mal für Test- und Entwicklungssysteme sehr interessant!

Nicht ganz so trivial ist dabei aber die Erbringung des Nachweises, dass man Besitzer der jeweiligen öffentlichen Domänen ist. Es stehen 3 Überprüfungsmethoden zur Verfügung: Upload von Infos zu einem FTP-Server (noch keine Erfahrung), Upload zu einem HTTP-Server oder Upload zum öffentlichen DNS. Wir schauen uns kurz die letzten beiden an.

  • DNS: Wenn ich ein Zertifikat für „sub.domain.com“ beantragen möchte, muss ich für diesen Namen im öffentlichen DNS einen speziellen TXT-Eintrag mit kryptischem Inhalt erstellen. Soweit, so gut. Wenn ich eine Reihe von SANs benötige, wird das schon etwas aufwändig und mühselig – je nach DNS-Provider und Güte des Tools kann es auch nervtötend werden.
  • HTTP: Wenn ich ein Zertifikat für „sub.domain.com“ beantragen möchte, muss ich einen unter diesem Namen per HTTP (ohne „s“) erreichbaren Web-Server bereitstellen (!) und dort im WWW-Root ein Verzeichnis namens „.well-known“ sowie einen Unterordner „acme-challenge“ anlegen. Dort hinein kommen spezielle Dateien mit kryptischen Namen. Klingt kompliziert? Ist es auch. Mal eben einen Web-Server für jeden Namen bereitstellen ist schon eine Herausforderung. Hier ist es ja nicht nur damit getan, z.B. ein zusätzliches Binding im IIS zu konfigurieren (wenn denn überhaupt IIS zum Einsatz kommt). HTTP-Anfragen müssen auch von extern hereinkommen können und an die richtige Stelle gelangen – ein geeignetes HTTP-Publishing ist also Pflicht. Wenn ich auch noch eine Reihe von SANs benötige, brauche ich für alle Namen auch jeweils ein Publishing. Dieses muss jeweils zu einem Web-Server zeigen, in dessen WWW-Root ein Ordner „.well-known“ existiert, usw.

Übrigens: Einmal präpariert, sind die Nachweise nicht von Dauer. Nach 90 Tagen verlieren sie ihre Gültigkeit und müssen erneuert werden.

Das wäre alles halb so schlimm, wenn die eigentlichen Zertifikate länger gültig wären. Sind sie aber leider nicht: Nach 3 Monaten ist auch hier Schluss und sie müssen erneuert werden. Dies gilt auch für die o.g. Autorisierungsnachweise. Und dann wäre da noch eine Kleinigkeit: Die neuen Zertifikate müssen ja auch noch den anhängigen Diensten wie z.B. Exchange, ADFS, WAP, RDS oder IIS bekannt gemacht werden, das war ja Ziel des Spiels. Natürlich kann man all das manuell machen. Mit einer guten Doku kann das sogar gut funktionieren. Aber bequem ist anders und wenn viele Dienste aktualisiert werden müssen, artet das in eine Menge Arbeit aus. Nun gut – ohne Herausforderungen wird es schnell langweilig. Es muss also eine bessere Lösung her…

Kann man das nicht irgendwie automatisieren?

Einige findige Leute haben sich diese Frage auch schon gestellt und bemerkenswerte Lösungen auf Powershell-Basis (ACMESharp Modul) entwickelt. Diese sind jeweils auf bestimmte Zielsysteme zugeschnitten, z.B.

a) für Exchange von Frank Zoechling,

b) für RDS-Server von Daniel Melanchthon oder

c) für IIS-WebServer von Marc Durdin.

Wohlgemerkt sind alle Lösungen auf exakt einen Server geeicht – also für jeden Server ein eigenes Zertifikat. Hat man mehr als 1 Exchange Server (z.B. in einer DAG) oder eine aus mehreren Servern bestehende RDS-Farm, muss man die Skripte nachfeilen.

Das Prinzip bei allen:

  1. Autorisierungsinfos für die öffentlichen Domänen erstellen
    • Der eine (b) favorisiert DNS , weil es simpler ist und weniger Anpassungen in der Infrastruktur erfordert. Allerdings ist hier die Automatisierung schwierig – je nach DNS-Provider mal mehr, mal weniger. Eine Standardlösung für alle DNS-Provider ist nur schwer vorstellbar.
    • Die anderen (a, c) favorisieren HTTP, weil es tatsächlich vollständig automatisierbar ist. Diverse Publishings mit geschickten Umleitungen etc. sind aufwändig und komplex, der Aufwand fällt aber bei gleichbleibenden Domänen nur einmal an.
  2. Anfordern des Zertifikats, dabei Überprüfung der in Schritt 1 erstellten Autorisierungsinfos
  3. Export des Zertifikats ins PFX-Format
  4. Einbinden des Zertifikats in die jeweiligen Dienste

Sofern man kein Problem mit der HTTP-Variante und ihren Nachteilen hat (und sich alles um Single-Server-Deployments dreht), lassen sich die Skripte a) für Exchange Server und c) für IIS-WebServer schon mal prima einsetzen. Gleiches gilt für RDS und b) wenn man mit einer Halbautomatik erst einmal zufrieden ist.

Ich für meinen Teil hatte für meine Testumgebung etwas speziellere Wünsche. Da ich dort nur eine öffentliche IP habe und einen großen Fuhrpark von Servern, Diensten und (sub-)domains versorgen muss, benötige ich ein SAN-Zertifikat mit sämtlichen DNS-Namen, das auf viele verschiedene Server zum Einsatz kommt. D.h. ich musste dafür sorgen, dass Autorisierungsinfos für alle Domänen zugreifbar sind. Nach einigen Modifikationen war das Skript von Frank Zoechling soweit, dass es im WWW-Root eines Web-Servers die Infos für alle Domänen ablegte.

2017-11-20_17h23_20

Nun noch eine Veröffentlichungsregel auf dem guten alten TMG, die incoming HTTP an diese Domänen zum obigen Web-Server leitet.

clip_image002

Damit war Punkt 1 erledigt, Punkt 2 und 3 funktionierten ohne weitere Modifikationen.

clip_image003

Punkt 4 sind eigene, separate Skripte auf den jeweiligen Zielservern (Exchange, ADFS, usw.), bislang noch nicht vollständig automatisiert. Bis hierhin zu kommen war schon eine Menge Arbeit, aber es hat sich gelohnt!

Es folgt eine Liste von Befehlen, die ich auf den jeweiligen Systemen abfeuere sowie ggf. weiterführende Infos.

Exchange 2016

  • Import-ExchangeCertificate -FileName \\centralserver\share\certnewest.pfx -FriendlyName „SAN domain.com“ -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force) -PrivateKeyExportable:$true | Enable-ExchangeCertificate -Services „SMTP, IMAP, POP, IIS“ -force

Exchange 2010

  • $ex=Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path \\centralserver\share\certnewest.pfx -Encoding byte -ReadCount 0)) -FriendlyName $ExchangeSubject -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force) -PrivateKeyExportable:$true
  • Enable-ExchangeCertificate -Services „SMTP, IMAP, POP, IIS“ -force -thumbprint $ex.Thumbprint

IIS

RDS

ADFS

  • Die Funktion „Set-CertificatePermission“ stammt auch aus den Tiefen des WWW
  • $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force)
  • $installedcert=Get-ChildItem Cert:\LocalMachine\My | ? {$_.Thumbprint -eq $certresult.Thumbprint}
  • Set-AdfsSslCertificate -Thumbprint $installedcert.Thumbprint
  • Get-AdfsSslCertificate
  • Set-CertificatePermission -pfxThumbPrint $installedcert.Thumbprint -serviceAccount „s_adfs“
  • Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint $certresult.Thumbprint
  • Restart-Service adfssrv

WAP

  • Hier fehlt noch die vernünftige Speicherung des „FederationServiceTrustCredential“, bislang nur interaktiv
  • $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force)
  • $installedcert=Get-ChildItem Cert:\LocalMachine\My | ? {$_.Thumbprint -eq $certresult.Thumbprint}
  • Install-WebApplicationProxy -FederationServiceTrustCredential (Get-Credential) -CertificateThumbprint $installedcert.Thumbprint -FederationServiceName ‚adfs.domain.com‘

Work Folders

  • $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString „HOCHGEHEIMESPASSWORT“ -AsPlainText -Force)
  • cmd /c netsh http delete sslcert ipport=0.0.0.0:443
  • cmd /c netsh http add sslcert ipport=0.0.0.0:443 certhash=$certresult.Thumbprint appid=“{CE66697B-3AA0-49D1-BDBD-A25C8359FD5D}“ certstorename=MY

Kemp VLM, SharePoint

  • Offen: Hier muss ich mir noch etwas überlegen/auf die Suche gehen

Fazit: Das Ganze ist noch eine offene Baustelle, von einer vollständigen Automatisierung bin ich noch ein Stück entfernt. Nichtsdestotrotz ist auch der aktuelle Stand mehr als nützlich und vereinfacht die Angelegenheit enorm. Let´s encrypt-Zertifikate sind eine tolle Sache. Aller Automatisierung zum Trotz sollten diese jedoch meiner Meinung nach Stand heute besser nicht in produktiven Umgebungen eingesetzt werden. Dann lieber ein paar Euro in ein 3 Jahre gültiges Zertifikat investieren. Für Test- und Entwicklungsumgebungen eignet sich das Ganze aber sehr gut!

Ich hoffe, diese Infos sind für den ein oder anderen nützlich.

PS: Danke an die genannten Quellen, ihr habt tolle Vorarbeit geleistet!

Quicktipp

Wer kennt das nicht – Sie befinden sich in Ihrem wohlverdienten Urlaub, aber Ihr Handy gönnt Ihnen keine freie Minute? Es erinnert Sie, trotz Abwesenheit, an Termine? Oder Ihr Kollege ruft Sie an, und fragt warum Sie nicht am Meeting teilnehmen, dabei liegen Sie krank zu Hause? 

Die Lösung für ein solches Problem: der Abwesenheitsassistent von Exchange Online!

Er kann Sie nicht vor Anrufen schützen, aber er kann im Zeitraum Ihrer Abwesenheit Ihren Kalender blocken oder auch Terminanfragen für Sie ablehnen oder auch absagen.

Schon wieder IPv6…

Vermutlich denken Sie jetzt – mit eingeschränkter Begeisterung, dass hier schon wieder jemand einen Artikel über die theoretischen Vorteile von IPv6 schreibt und damit das lesende Volk verunsichern will. Naja, im Prinzip richtig. Tatsächlich möchte ich hier ein Ergebnis zusammenfassen, dass wir in unserer eigenen iteracon-Infrastruktur erlebt haben. Wir sahen uns tatsächlich gezwungen, IPv6 selektiv einzuführen. Vielleicht ist ja dieser Bericht für den einen oder anderen Leser eine Unterstützung bei eigenen Überlegungen.

Wie also kam es dazu, dass wir (unfreiwillig) gezwungen wurden, IPv6 einzusetzen?

Ausgangspunkt ist die Verwendung von Skype for Business (S4B). Wir setzen als Microsoft Gold Partner natürlich S4B ein und ermöglichen unseren Mitarbeitern damit auch eine komfortable Erreichbarkeit an Heimarbeitsplätzen. Microsoft empfiehlt, in diesen Szenarien den S4B Verkehr nicht zusätzlich per VPN zu verschlüsseln, da hierdurch zusätzliches Delay und Jitter entsteht und die Sprachqualität entsprechend abnehmen kann. Siehe z.B. folgenden etwas älteren Artikel hierzu: https://blogs.technet.microsoft.com/nexthop/2011/11/14/enabling-lync-media-to-bypass-a-vpn-tunnel/. S4B verschlüsselt die übertragenen Daten bereits von Hause aus und unterstützt sichere Verfahren für die Authentisierung. Es besteht also keine unmittelbare Notwendigkeit S4B via VPN zu implementieren.

Wenn man dieser Microsoft-Empfehlung folgt, werden beim entfernten Teilnehmer (z.B. Heimarbeitsplatz) einige TCP-/UDP-Ports für die Verbindung benötigt und zwar auch in Richtung des Teilnehmers. Diese Ports werden teilweise dynamisch ausgehandelt und sind nicht im Vorfeld bekannt. Das STUN-Protokoll unterstützt hierbei den Verbindungsaufbau durch Firewalls und über NAT Devices. Sofern man über einen Anschluss mit (z.B. einer festen) IPv4-Adresse verfügt, der bezüglich der nutzbaren Ports nicht eingeschränkt ist, ist alles gut. Allerdings ist dies kaum der Standard; viele Heimarbeitsplätze verwenden dynamisch vom Provider vergebene IPv4-Adressen und bei diesen setzen immer mehr Provider Carrier Grade NAT Verfahren ein (CGN), um die Menge der zur Verfügung stehenden öffentlichen IPv4-Adressen optimal nutzen zu können. Es geschieht gelegentlich eine recht hohe Überbuchung der öffentlichen IPv4-Adressen der Provider. Es ist absehbar, dass mit solchen CGN-Verfahren S4B in Probleme laufen kann, wenn die öffentlichen IPv4-Adressen stark in Nutzung sind und damit die freien TCP/UDP Ports knapp werden.

So geschehen: Wir hatten bei einigen Mitarbeitern das Problem, dass sie nicht immer von zu Hause telefonieren oder Konferenzen nutzen konnten. Die Fehlersuche gestaltete sich schwierig, da keine offensichtlichen Fehler in der Infrastruktur gefunden werden konnten. Die Probleme traten zudem nicht konstant auf, sondern eher sporadisch. Nach einigen Analyse haben wir dann das Carrier-Grade-NAT in Verdacht gehabt und unterstellt, dass notwendige Ports beim entfernten Teilnehmer nicht immer frei waren / genutzt werden konnten.

Unsere Infrastruktur verwendet einen S4B Edge-Server in einer DMZ für die Kommunikation mit Teilnehmern außerhalb des Firmennetzes. Dieser Edge-Server authentisiert die Teilnehmer und bündelt die Kommunikation in Richtung S4B Front-End-Server im LAN. Um Probleme mit NAT auszuloten, haben wir folgende Änderungen durchgeführt:

  • Der Edge-Server hat eine zusätzliche IPv6-Adresse bekommen (Dual-Stack).
  • Wir haben auf der Firewall IPv6 in Richtung des Internets für den Edge-Server freigeschaltet.
  • Wir haben auf der Firewall auch eingehende S4B-Kommunikation über IPv6 zugelassen.
  • Schließlich haben wir im öffentlichen DNS einen zusätzliche aaaa-Record mit gleichem Namen wie beim vorhandenen a-Record gesetzt und diesen auf die IPv6-Adressee des Edge-Servers auflösen lassen.

 

Das Ergebnis: mit diesen Änderungen funktioniert die Telefonie nun auch bei allen Teilnehmern wieder zuverlässig. Insbesondere profitieren die Teilnehmer, deren Internet-Zugänge bereits IPv6 sprechen (also die meisten). Eine Analyse mit Wireshark zeigt: Hat ein S4B-Client eine IPv4- und IPv6-Konfiguration, versucht er, den Verbindungsaufbau über aaaa/IPv6 zu initiieren. Gelingt dies, ist IPv6 hier sogar der präferierte Weg! Eine Überbuchung von IPv6-Adressen bzgl. NAT ist bisher nicht in Sicht. IPv6 ist also in diesem Szenario die Lösung des Problems!

Das Szenario scheint mir deshalb akzeptabel, weil es mit relativ geringen Änderungen in der Infrastruktur umsetzbar ist. Wir setzen IPv6 nur bis in die DMZ ein, danach geht es per IPv4 weiter. Gegen eine weiter reichende Einführung von IPv6 (IPv6 bis zum Front-End-Server in unser lokales Netzwerk) hätte ich deutliche Vorbehalte, weil dies alle vorhandenen Kommunikationsregeln (Firewall, DNS, Routing) in Frage gestellt hätte und sich der übliche Aufwand für Fehlersuchen im Netz damit relativ schnell verdoppeln würde.

Unser Fazit: Es ist absehbar, dass uns an einigen Stellen IPv6 unerwartet begegnen wird und dass wir uns dann zwangsweise damit anfreunden müssen. Es scheint aus heutiger Sicht ratsam, diese Szenarien vorzubereiten und IPv6 bis an die Grenze des Unternehmensnetzes (Firewall, DMZ) schon einmal zu durchdenken und nutzbar zu machen.

Es grüßt, Harald Krause

 

DirectAccess Manage Out funktioniert nicht von internen Windows 10 Clients…

…Hallo Allerseits,

in 4 verschiedenen DirectAccess-Umgebungen haben wir Probleme von internen Windows 10 Clients festgestellt welche externe DirectAccess Clients via Manage Out (Stichwort: ISATAP) verwalten wollen. Die Problematik lässt sich auf das Nicht-Funktionieren der Namensauflösung einschränken. Wenn z.B. von einer der betroffenen internen Maschinen ein Ping (oder RDP oder sonstiges Protokoll) auf den NetBios-Namen des externen DA-Clients abgesetzt wird kommt ein “Host unbekannt” zurück – und das obwohl der externe Client sich korrekt (mit seiner v6-IP) am internen DNS registriert hat.

Im folgenden Screenshot kann man erkennen, das ein NSLOOKUP auf einen NetBios-Namen korrekt aufgelöst wird, der direkt folgende Ping auf denselben Namen scheitert:

clip_image002

Richard Hicks hat über dieses Verhalten/Phänomen bereits im November 2015 berichtet und auch einen Workaround in Form von Registry-Hacks online gestellt:

https://directaccess.richardhicks.com/2015/11/10/directaccess-manage-out-from-windows-10-does-not-work/

Einer unserer Kunden hat nun ein Ticket bei Microsoft geöffnet um eine Aussage des Herstellers dazu zu erhalten. Dort wurde uns signalisiert das dieser Case nun als Bug klassifiziert wurde.

Im übrigen kann das Verhalten als Workaround auch mit einem einzelnen Registry-Key gelöst werden und zwar wie folgt, hier ein Ausschnitt aus der Ticket-Konversation:

***********************************************

Hallo Herr Hentrup,

ich habe weitere Informationen.

Für das von mir in der vorigen Email angesprochene Verhalten (der Client sendet keine AAAA Queries) ist die aktuelle Lösung diesen Registry Key zu setzten.

HKLM\System\CCS\Services\DNSCACHE\Parameters

REG_DWORD „AddrConfigControl „
Value: 0

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name AddrConfigControl -PropertyType dword -Value 0 -Force

Die anderen beiden Registry Keys können somit auf Ihren Standartwerten bleiben. Wenn Sie sie zurücksetzten wollen:

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 0 -Force

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 0 -Force

Testen Sie das doch bitte.

Wenn es auch so funktioniert haben wir sicherlich das Problem. Dieses Verhalten zeigt auch Win10 1511.

***********************************************

Haben wir getestet – funktioniert!

Gruß,

Karsten Hentrup…

|<-|

iteracon bloggt…

…Ich freue mich hier ankündigen zu dürfen, dass wir von der iteracon GmbH nun ein eigenes Blog hegen und pflegen. Wir werden hier über unsere Erfahrungen zu verschiedensten Microsoft-Produkten, deren Implementation und Betrieb berichten.

Unsere aktuellen thematischen Highlights sind die Managed Services rund um Microsoft Azure und Office 365, Consulting zum modernen effizienten Arbeiten rund um Windows 10, Office 2016, und Skype for Business. Darüber hinaus beschäftigen wir uns mit einigen Spezialthemen wie Multi-Factor Authentication, DirectAccess und Active Directory Security mit Advanced Threat Analytics.

Natürlich wird sich hier auch das eine oder andere “klassische” Microsoft Thema wiederfinden wie die System Center Suite, Exchange, Active Directory, Hyper-V, PKI, etc.

Wir lesen uns!

Gruß, Karsten Hentrup…

|<-|