Windows 2012 und TLS

Mit Windows 2012 und Lync 2013 ist ein verändertes Verhalten von Windows 2012 das erste mal offensichtlich geworden, das bei Windows 2008R2 und früher kein Problem dargestellt hat. Es geht um die Zertifikate im lokalen Zertifikatspeicher in Verbindung mit TLS-Authentifizierungen.

Die Fehlerbilder

Folgende Fehler konnte ich bislang darauf zurück führen:

  • Lync 2013 Frontend Server starten nicht
  • CMS-Replikation zum Edge Server funktioniert nicht
    Siehe auch Lync CMS

Ich denke es werden noch weitere Dienste zukünftig davon betroffen sein, wenn Microsoft das Standardverhalten nicht ändert.

Grundlagenforschung TLS

Es dreht sich alles um die Verwendung von Zertifikaten bei der Verbindung zwischen Servern und Diensten. Lync ist da sicher eines der ersten Systeme, die betroffen sind, da alle Kommunikationen untereinander per TLS mit Computerzertifikaten gesichert sind. dazu sind zwei Dinge erforderlich:

  • TLS anbieten
    Dienste die per TLS erreichbar sind, benötigen lokal ein entsprechendes Zertifikat samt private Key. Zudem ist es erforderlich, dass auch eventuell erforderliche "Intermediate CAs" im richtigen Speicher auf dem Server liefen, damit er sich im Rahmen des TLS-Handshake mit übermitteln können. Das Root-Zertifikat muss auf dem Server natürlich auch vorhanden sein.
  • TLS nutzten
    Wenn ein Dienst eine Verbindung zu einem anderen Dienst aufbauen, wird er von dort erst mal ein Zertifikat anfordern, damit die Verbindung verschlüsselt ist. Zudem kann er sich aber auch mit einem eigenen Zertifikat an der Gegenseite ausweisen. Dazu sendet ihm die Gegenstelle aber erst eine Liste ihrer "RootCAs", denen sie vertraut, damit der Client ein passendes Zertifikat zur Anmeldung übermitteln kann.

In diesem Bild ist es also wichtig, dass die Endpunkte ein Zertifikat mit privatem Schlüssel haben und die ausstellenden Zertifizierungsstellen bekannt, vertrauenswürdig und überprüfbar sind.

Personal, Intermediate, Root

Für die Verwendung von Zertifikaten sind heute fast immer drei Ablageorte interessant, die es auf jedem "Local Computer" gibt. Wenn Sie auch TLS für die Anmeldung an Webseiten nutzen, dann kommen auch Zertifikate im "Personal Store" des Benutzers und eventuell im Smartcard-Store des Benutzers zum Einsatz. Die Ablageorte sind aber klar definiert:

  • Eigene Zertifikate (Personal)

    Hier liegen ausschließlich meine eigenen Zertifikate oder die Zertifikate des Computers mit dem privaten Schlüssel. Dass der private Schlüssel vorhanden ist, sehen sie an dem kleinen Schlüsselsymbol. Die rot hier eingezeichneten Zertifikate sind hier falsch. Sie werden hier sowieso nicht genutzt, aber könnten Programme verwirren. Also raus damit
  • Stammzertifizierungsstellen /Root
    Hier müssen alle Zertifikate (natürlich ohne Privatekey) liegen, denen dieser Computer vertraut.

    Dieser Auszug zeigt in Grün die Microsoft-RootCAs und eine FirmenCA. Rot markiert sind das "Intermediate-Zertifikat von GoDaddy" und persönliche Zertifikate (sogar mit Privatekey) die hier definitiv nichts verloren haben. Ehe Sie diese aber hier löschen, sollten Sie diese erst zu Sicherheit exportieren. Per "Drag and Drop" wurden diese vielleicht unabsichtlich dort hin verschoben.

Hinweis: Die Liste der Stammzertifikate wird bei der Installation von Windows "vorgefüllt". Es ist also wichtig eine "vertrauenswürdige" Installationsquelle zu nutzen. Zudem werden neue Zertifikate über Windows Update, über Gruppenrichtlinien oder den automatischen Download von Microsoft erweitert. Achten Sie aber darauf, dass speziell auf Servern diese Liste nicht mehr als ca. 120 Elemente enthält, da ansonsten die RootListe zu lange wird, um diese beim TLS-Handshake zu übertragen.
Siehe auch MaxRootCA und Automatic Root Certificates Update Configuration (http://technet.microsoft.com/en-us/library/cc734018(WS.10).aspx)

  • IntermediateCA
    Die Liste der IntemediateCAs ist in der Regel sehr kurz. Denn normalweise sendet der Server, auf den sich ein Dienst hin verbindet die komplette "Chain" mit. Dieser Speicher muss daher nur die Zwischenzertifikate enthalten, die man selbst an Clients versenden muss. Nur wenn die Gegenstelle warum auch immer keine Chain sendet, sollte man diese Zwischenzertifikate importieren.

Fallen beim Zertifikat Import

Wer nun sagt, dass bei ihm alles richtig ist da er ja nie in diesen Strukturen herum administriert hat, wird dennoch bei Windows 2012 eventuell auf unstimmigkeiten stoßen. Denn viele Administratoren "importieren" Zertifikate über den Assistenten oder einfach einen Doppelklick. Und allzu oft wird das Zertifikat dann nicht im richtigen Speicher abgelegt.

Interessanterweise funktionieren die meisten Zertifikate dann doch, da Windows selbst sich z.B. bei einem Zertifikat einer offiziellen CA das dazugehörige RootCA selbst herunter landen kann. Aber zumindest bei Windows 2012 ist dies kein sicherer Weg.

Falsche Zertifikate per PowerShell finden

PowerShell erlaubt einen sehr einfachen Zugriff auf die Zertifikatsspeicher, so dass eine Auswertung sehr einfach ist.

# PowerShell Einzeiler um "falsche" Zertifikate in der Root zu finden

Write-host "Root Store: Zertifikate, die keine Stammzertifikate sind
Get-Childitem cert:\LocalMachine\root -Recurse | `
   Where-Object {$_.Issuer -ne $_.Subject} | `
      Format-List * 

Write-host "Intermediat Store: Zertifikate mit Private Key"
Get-Childitem cert:\LocalMachine\ca `
   | Where-Object {$_.HasPrivateKey } | `
      Format-List

Write-host "Intermediate Store: Stammzertifikate "
Get-Childitem cert:\LocalMachine\ca -Recurse | `
   Where-Object {$_.Issuer -eq $_.Subject} | `
      Format-List * 


Write-host "Zertifikate in \MY" ohne private Key
Get-Childitem cert:\LocalMachine\my `
   | Where-Object {!$_.HasPrivateKey } | `
      Format-List

Wer die Probleme durch "Löschen" automatisch lösen will, hängt einfach ein "| remove-item" statt des "Format-List" an.

Andere Tricks

Da dieses neue (strenge) Verhalten von Windows 2012 eigentlich nicht deutlich dokumentiert ist, haben sich einige andere Personen "Workarounds" einfallen lassen, die ich hier der Vollständigkeit halbe mit beschreibe.

Diese Krücken lösen nicht das Problem, sondern umgehen die Symptome. Ich rate davon ab, diese Einstellungen ohne genauer Prüfung und Dokumentation vorzunehmen

Ein Hinweis verweist auf den ClientAuthTrustMode. Wenn Sie diesen Key, der per Default nicht vorhanden ist, auf 2 (ExclusiveCATrust) stellen, dann scheint der Fehler so nicht mehr aufzutreten

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"ClientAuthTrustMode"=dword:00000002

mögliche Werte sind:  0=Machine Trust,  1=Exclusive Root Trust und 2=ExclusiveCATrust. Allerdings sind die Informationen über deren Funktion sehr beschränkt.

Eine andere Version besteht darin die Liste der RootCAs gar nicht an den Client zu senden. Der Client sollte dann aber nur ein Zertifikat haben, welches vom Server auch anerkannt wird, da der Client nicht zuverlässig ein akzeptierbares Zertifikat erhalten kann.

  • MaxRootCA
  • 2464556 TLS client authentication fails between Unified Communications peers with a logged Schannel warning

Applikationsfehler

Bis sich das Verhalten von Windows 2012 vielleicht doch noch mal ändert und falsche Zertifikate im falschen Speicher doch ignoriert werden, habe ich hier die betroffenen Produkte mit den Fehlermeldungen dokumentiert. Vielleicht hilft es verzweifelten Administratoren bei der Suche per Suchmaschine diese Seite anhand der Fehlermeldungen zu finden

Lync 2013 Frontend Server auf Win2012 startet nicht

Die Lync 2013 Frontenddienste starten nicht da die Windows Fabric die User nicht platzieren kann. Manchmal scheinen die Dienste erst nach einigen Reboots nicht mehr zu starten. Es zeigt sich in folgenden Eventlog Meldungen:

Failed to sync data für Routing group {0D51A9AA-ABD9-5470-87FA-349556503C9F} 
from backup store.
Cause: This may indicate a problem with connectivity to backup database or 
some unknown product issue.
Resolution:
Ensure that connectivity to backup database is proper. If the error 
persists, please contact product support with server traces.
Log Name:      Microsoft-Windows-WindowsFabric/Admin
Source:        Microsoft-Windows-WindowsFabric
Event ID:      18465
Task Category: FM
Level:         Warning
Keywords:      None User:          NETWORK SERVICE
Computer:      lync2013.msxfaq.net
Description:
Replica on b6277d62e11a4e816f7179f3d6b8e7:129970606058458545 für FailoverUnit 6aebabd3-c487-445e-8450-11c522ec93a8 service 
fabric:/lync/routing/0D51A9AAABD9547087FA349556503C9F [0-0] 
partition name  build error OperationFailed

Per PowerShell sieht man, dass Lync mit sich noch nicht im Reinen ist.

PS C:\> Get-CsPoolFabricState -PoolFqdn lync2013.msxfaq.net
Replica Instances für MCUFactory Service
    Address: lync2013.msxfaq.net - primäry: 6 Secondary: 0
 
Replica Instances für ConferenceDirectory Service
    Address: lync2013.msxfaq.net - primäry: 1 Secondary: 0
 
Replica Instances für Routing Service
Service:  (P) fabric:/lync/routing/0D51A9AAABD9547087FA349556503C9F has no primäries.
 
Replica Instances für LYSS Service
Service: fabric:/lync/storage/0D51A9AAABD9547087FA349556503C9F has no primäries.
 
Global Service Count Summary:
Fqdn: lync2013.msxfaq.net - primäry: 7 Secondary: 0

Workaround für Eilige: Lync 2013 auf Win2008R2 installieren. Aber Achtung: Späteres „Inplace upgrade von Win2008R2 auf Win2012 ist nicht supportet!

Weitere Links