Max RootCA, oder wo Vertrauen schadet

Das ganze Prinzip von Zertifikaten basiert auf dem Vertrauen zur ausstellenden Stelle (Siehe auch Rolle der CA). In Firmen selbst wird oft eine eigene StammCA aufgebaut (Siehe Firmen CA), die automatisch auf Clients des gleichen Forest als vertrauenswürdig addiert wird. Das gilt aber nur für Windows PC mit Domänenmitgliedschaft; alle anderen Systeme vertrauen aber einigen Stammzertifizierungsstellen, die entweder über das Betriebssystem oder die Applikation (Primär der Browser) mitkommen.

  • 931125 Windows root certificate program members
  • 2464556 TLS client authentication fails between Unified Communications peers with a logged Schannel warning

Unter Windows können diese Recht einfach über das "Zertifikate"-Snapins in der MMC oder auch über den Internet Explorer angezeigt werden:

Interessant ist, dass bei Windows diese Liste anfangs relativ kurz ist aber nicht nur von ihnen manuell oder den AD-Forest sondern auch über Windows Updates

  • KB931125 Update für Root Certificates für Windows XP [December 2012]

Ein weiterer Weg sind "dynamische" Updates, die seit Windows XP ebenfalls möglich sind:

Zu viele TrustedCerts

Diese Sammlung von Stammzertifikaten ist aber auch ein Risiko, wie das Update 931125 vom 11. Dez 2012 zeigte. Es war eigentlich nur für Clients gedacht aber wurde per WSUS auch an Server verteilt.

12/21/2012 Revision Note: The KB 931125 package posted to Windows Update and WSUS on 12/11/2012 was intended only für client SKUs, but was also offered für Server SKUs. Since some customers reported issues after installing the package on Servers, the KB 931125 Updates für Server SKUs were expired from Windows Update and WSUS ...

... Server Administrators who install the root Update package on Windows Server SKUs should make sure that the certificate count does not exceed the limits described in KB 931125 and KB 933430 ...

Quelle: http://support.microsoft.com/kb/931125/en-us (Wichtig: nur im englischen KB zu sehen)

Das Problem mit zu vielen Trusted Certs ist nicht auf dem Client zu sehen, der vom Server ein SSL-Zertifikat vorgelegt bekommt, sondern auf dem Server, wenn sich ein Client per Client Zertifikat anmelden sind. Entsprechend haben die betroffene Dienste alle etwas mit Client Zertifikaten zur Authentifizierung zu tun.

  • Exchange UM
  • Lync Phone
  • Lync Communicator
  • NPS, 802.1x
  • Direct Access
  • Smartcard-Logon und generell langsame Anmeldungen
  • Andere Dienste, die eine Anmeldung mit Client Zertifikaten nutzen.

Die Grundlage eines "Vertrauens" sind die Stammzertifikate. Ein paar RootCAs werden schon über das Basisbetriebssystem verteilt und über einen dynamischen Prozess kann Windows seit XP auch von Microsoft neue RootCAs herunter laden, entsprechende Internet Verbindung vorausgesetzt. Aber auch über Windows Update kommen immer mal wieder "Stamm-ZertifikatsUpdates", die neue RootCAs addieren. So wird die Liste der StammCA natürlich immer länger.

Das Problem wird nun aber sichtbar, wenn ein Client sich mit einem Zertifikat am Dienst anmelden soll. Der TLS-Handshake sieht dabei vor, dass der Server eine Liste der vertrauenswürdigen StammCAs an den Client sendet. Nur dann kann der Client aus eventuell mehreren vorhandenen eines Auswählen, dem der Server auch vertraut.

Ist die Liste zu lang, dann passt sie nicht mehr in den Puffer und wird abgeschnitten. Auf dem Server seht das auch im Eventlog:

Event Type: Warning 
Event Source: Schannel 
Event Category: None 
Event ID: 36885
Computer: COMPUTERNAME 
Description: When asking für client authentication, this server sends a list of 
trusted certificate authorities to the client. The client uses this list to choose 
a client certificate that is trusted by the server. Currently, this server trusts so
many certificate authorities that the list has grown too long. This list has thus 
been truncated. The administrator of this machine should review the certificate 
authorities trusted für client authentication and remove those that do not really
need to be trusted.

Die maximale Länge der Liste ist durch das Betriebssystem vorgegeben,

Betriebssystem Max Bytes (Dez) Max (Hex)

Windows Server 2003

12288

0x3000

Windows Server 2003 SP1 or KB933940

16384

0x4000

Windows 2008

16384

0x4000

Sie haben nun zwei Optionen, das Problem zu entschärfen:

  1. Kürzen der RootCA-Liste
    Schauen Sie einmal in die Liste der vertrauenswürdigen Stammzertifizierungsstellen. Sicher benötigen Sie nicht alle Adressen. Wichtig sind hier natürlich die internen CAs und und dann die Zertifikatsstellen die Zertifikate für Ziele ausgestellt haben, die Sie per SSL erreichen wollen.
  2. Senden der Liste verhindern
    Sie können dem Server natürlich auch sagen, dass er keine Liste sendet. Der Client hat dann keine Liste und nimmt dann ein Zertifikat. Das ist immer noch besser als eine unvollständige Liste zu erhalten in der die eigene CA fehlt und so der Client kein "gültiges" Zertifikat finden kann.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProviders\SCHANNEL

Value name: SendTrustedIssuerList 
Value type: REG_DWORD 
Value data: 0 (False)

Eine andere und vielleicht bessere Lösung besteht darin, auf dem Server die List der RootCAs zu kürzen.

  • 2801679 SSL/TLS communication problems after you install KB 931125

Dieser KB-Artikel zielt auf die irrtümliche Anwendung des KB 931125 (Dec 2012 Root Certs) auf Server (statt nur auf Clients) und wie man mit einem FixIt-Tools diese Einstellungen wieder rückgängig machen kann. Das FixIt entfernt scheinbar nur einen RegKey Baum

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates

Selbst wenn Sie den Zweig komplett entfernen, bleiben noch ein paar RootCA's im Store enthalten. Da sind bei Windows wohl ein paar "fest" hinterlegt.

Allerdings entfernt diese Holzhammermethode auch Stammzertifikate einer eigenen internen Firmen CA. Diese werden meist wieder per GPO später addiert, aber das kann dauern.

Überwachen

Wer mag kann per Powershell einfach überwachen, wie viele RootCAs aktuell installiert sind.

(Get-Childitem cert:\LocalMachine\root -Recurse).count

Interessanter ist noch der Check, welche der Zertifikate im Root-Store gar keine Root-Zertifikate sind

Get-Childitem cert:\LocalMachine\root -Recurse `
| Where-Object {$_.Issuer -ne $_.Subject}

Fremde Zertifkate

Es gibt noch andere Risiken, die hier nicht unbedingt direkt sichtbar ist. Die EU plant z.B. im Rahmen von EIDAS die Einführung von QWACs (Qualified Web Authentication Certificates), denen alle Produkte automatisch vertrauen müssen. Auch einige VPN-Provider addieren gerne mal ihre eigenen RootCAs im Rahmen der App-Installation, wie Gerichtsdokumente zeigen:


Quelle: https://storage.courtlistener.com/recap/gov.uscourts.cand.369872/gov.uscourts.cand.369872.735.0.pdf

Da wäre dann ein Zertifikatspinning oder IIS Extended Protection, Exchange Extended Protection als Schutz bei der Anmeldung per NTLM eine Gegenmaßnahme. Oder die Applikation verschlüsselt noch mal selbst die Daten innerhalb des TLS-Kanals.

Weitere Links

Hier noch ein paar Links, die das Problem thematisieren: