SHA-256, SHA-1 Abschaltung und Keylänge

Langsam wird es Zeit, da schwache Verschlüsselungs- und Signierungsverfahren nach und nach geblockt werden. Wer also noch ein "schwaches" Zertifikat mit zu kurzen Schlüssel oder schwacher Codierung verwendet, sollte diese aus eigenem Interesse bald austauschen.

Achtung: Nicht alle Clients können mit SHA2 bzw. SHA256 umgehen. Dies betrifft einige ältere Mobiltelefone (z.B. Nokia ActiveSync), aber auch Windows 2003/XP-Clients)

Beachte dazu auch Get-TCPCert.

Die Problemstellung

Vielleicht ist es bei ihnen noch nicht angekommen, aber die Signierung mit dem SHA-1 Verfahren gilt als unsicher und es ist nur eine Frage der Zeit, bis Sie als Anwender bei einem Zugriff per HTTPS nicht mehr sicher sein können, dass nicht mitgelesen wird. Daher das das CA Council, ein Zusammenschluss der CAs schon 2013 das Ende von SHA-1 verkündet.

Mozilla und andere akzeptieren schon heute keine SHA-1 Zertifikate mehr, wenn diese nach dem 1. Jan 2016 ausgestellt wurden. Zum 1.1.2017 machen einige Browser und Clients ernst und per SHA-1 signierte Zertifikate werden nicht mehr vertrauenswürdig angesehen. Spätestens jetzt fällt jedem Anwender etwas auf und es wird Rückfragen im Support geben. Bitte sagen Sie den Anwendern nie, dass Sie die Warnung ignorieren sollen. Damit schwächen Sie das ohnehin schon angeschlagene System der CAs.

Sorgen Sie dafür, dass ihre WebServer alles ein aktuellen SHA-256-signiertes Zertifikat nutzen.

Ehe Sie das aber tun, müssen Sie ihre CA-Infrastruktur ggfls. anpassen und die Kompatibilität mit Servern und Clients sicherstellen. Das ist gar nicht so einfach. Ansonsten passiert nichts mehr.

  • Server, die kein SHA-2/SHA-256 unterstützen, bieten kein SSL mehr an bzw. starten die Dienste einfach nicht mehr.
  • Clients, die kein SHA-2/SHA-256 unterstützen, können sich nicht mehr per TLS mit dem Backend verbinden.

Nichts zu tun geht aber auch nicht, da dann sehr viele Clients ab dem 1. Januar.2017 mit Warnungen reagieren.

Die Logik der Warnung ist schon vor längerer Zeit durch Updates auf ihren Client gekommen. Die Warnung wird allein durch das Datum aktiviert. Es hilft nicht, wenn Sie nach dem 1.1.2017 keine Windows Updates mehr installieren würden.

Das Ziel ist also eine möglichst umfangreiche Umstellung mit eine Fall-Back Option für inkompatible Clients und Server

Eignung von Client und Server

Das Backend eines Servers muss mit den neuen Zertifikaten und dem aktuellen Hash-Verfahren zurecht kommen. Aber auch die Clients müssen die neuen Zertifikate natürlich verstehen. Leider ist es aber gute Praxis, dass immer noch viele "Alt-Geräte" im produktiven Einsatz sind, sei es aus Lizenzfragen oder einfach Kompatibilitätsanforderungen. Hier ist das Augenmerk insbesondere auf Windows XP und Windows Server 2003 zu lenken. Hier gibt es Updates und Patches

OS Eignung Bemerkung

Windows 2000 und früher

Nein

Keine Unterstützung von SHA-2, Kein Update oder Patch verfügbar

Windows XP

Vorbehalt

Servicepack 3 bringt die SHA-2 Unterstützung

Prior to Windows XP Service Pack 3, there was no SHA2 functionality within Windows XP. With the release of Service Pack 3 some limited functionality was added to the crypto module rsaenh.dll. This includes the following SHA2 hashes: SHA-256, SHA-384, SHA-512. SHA-224 was not included.
Quelle: https://blogs.technet.microsoft.com/pki/2010/09/30/sha2-and-windows/

Windows 2003

Vorbehalt

Windows Server 2003 Service Pack 2 hat noch keinen SHA2 Support. Es gibt aber einen Hitfix hierfür und ebenso für die Anforderung von Zertifikaten von einer Windows 2008 CA

Windows Server 2003 Service Pack 2 does not ship with support for SHA2. This limitation can become an important concern when processing smart card logons and for mutual TLS authentications to web servers. As unlike other technologies, smart card logon and mutual TLS both use strict revocation checking; so should either the certificate itself or the revocation information (CRL/OCSP) use SHA2, the logon would fail.
Quelle: https://blogs.technet.microsoft.com/pki/2010/09/30/sha2-and-windows/

  • KB 938397
    Though support SHA2 is not included in Windows Server 2003 Service Pack 2, it is available for download. KB938397 will bring Windows Server 2003 to the same level of functionality as Windows XP with Service Pack 3. KB 938397 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page. Note, KB 938397 is also offered for Windows Server 2003 Service Pack 1.
  • KB 968730
    With the release of Windows Server 2008 it was found that Windows XP Service Pack 3 and Windows Server 2003 Service Pack 2 with KB 938397 were unable to request certificates from a Windows Server 2008 (and 2008 R2) certificate authority (CA) who’s certificate was signed with a SHA2 hash. KB 968730 was release to address this issue. Incidentally, KB 968730 completely supersedes KB 938397; so if a Windows Server 2003 Service Pack 2 system would need to both enroll from a SHA2 certificate authority and process SHA2 certificates, only KB 968730 would need to be installed. As before, KB 968730 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page. Note, KB 968730 is not offered for Windows Server 2003 Service Pack.

Vista, 7,8,10, Server 2008 und höher

OK

SHA2/SHA-256 Support eingebaut.

In order to validate SHA2 messages, Windows Vista with Outlook 2003 (or newer) is needed. In order to both sign and validate SHA2 messages, Windows Vista or 7 with Outlook 2007 or 2010 is needed.
Quelle: https://blogs.technet.microsoft.com/pki/2010/09/30/sha2-and-windows/

IOS 10.2

OK

Ein manuell auf 15. März 2017 gestelltes Telefon hat auch  mit einem SHA-1 Zertifikat weiter ActiveSync ohne Warnung genutzt. Hier gibt es noch keine Deadline

Windows Phone 8.1

OK

Ein manuell auf 15. März 2017 gestelltes Telefon hat auch  mit einem SHA-1 Zertifikat weiter ActiveSync ohne Warnung genutzt. Hier gibt es noch keine Deadline

Windows Phone 10

OK

Ein manuell auf 15. März 2017 gestelltes Telefon hat auch  mit einem SHA-1 Zertifikat weiter ActiveSync ohne Warnung genutzt. Hier gibt es noch keine Deadline

Nokia Symbian

Nein

Ein manuell auf 15. März 2017 gestelltes E52 hat mit einem SHA-1 Zertifikat ActiveSync ohne Warnung genutzt. Eine Verbindung zu einer Sha-256 Site hat nicht funktioniert

Android

 

Offen

Andere Betriebssysteme und insbesondere Clients sind natürlich ebenfalls zu prüfen. Allerdings habe ich bislang wenige Drucker, Scanner, Router, ThinClients etc. gesehen, die Alarmmails per TLS versenden. Anwender werden solche System auch kaum ansurfen, so dass das Störpotential vermutlich geringer ist.

Timeline

Ich versuche die Zeitpunkte zu protokollieren, wann welche Schlüssellängen und Verfahren wo abgeschaltet werden:

Zeitpunkt OS Client Beschreibung

14. Feb 2017

Win7

SHA1-Code Signing ungültig

Starting on February 14th, 2017, Microsoft Edge and Internet Explorer 11 will prevent sites that are protected with a SHA-1 certificate from loading and will display an invalid certificate warning. Though we strongly discourage it, Users will have the option to ignore the error and continue to the website.
Quelle: https://blogs.windows.com/msedgedev/2016/11/18/countdown-to-sha-1-deprecation/#.WDFgR0M1-SA.twitter#y5jQqieuSscSVMPd.97
This will only impact SHA-1 certificates that chain to a Microsoft Trusted Root CA. 

Spätestens hier müssen auch Code-Entwickler ihre Programme, Installer und Makros mit SHA256 signieren.

1. Jan 2017

Chrome

SHA1-Code Warnung

Im Browser wird neben dem Schloss ein gelbes Dreieck angezeigt.

1. Jan 2016

Microsoft

SHA1 TLS

Server Authentication certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. Windows will no longer trust certificates signed with SHA-1 after January 1, 2017
Quelle: https://blogs.technet.microsoft.com/askds/2015/10/26/sha1-key-migration-to-sha256-for-a-two-tier-pki-hierarchy/

Sommer 2016

IE

Browser

Anzeige von SSL-Symbol mit SHA1

1. Jan 2016

CodeSigning

Installer

SHA1- nicht mehr unterstützt für neuere Betriebssysteme

1. Jan 2016

Windows

OCSP
  • Microsoft beendet das Vertrauen in Code Signing-Zertifikate mit SHA-1
  • GlobalSign deaktiviert alle SHA-1-Ausstellungsoptionen (Änderungen aufgrund aktualisierter Microsoft-Richtlinie vorbehalten).

31. Mrz 2014

CAs

Any

Am Beispiel von Global Sign (Andere auch)

  • Kunden können zu jedem Zeitpunkt während der Laufzeit des Zertifikats bestehende SHA-1-Zertifikate kostenlos mit SHA-256 neu ausstellen.
  • Neue Zertifikatsanträge, die sich für SHA-1 entscheiden, werden auf einen maximalen Gültigkeitszeitraum des Zertifikats von 3 Jahren begrenzt

26. Sep 2014

Chrome 39

SHA1-Code Warnung

Im Browser wird neben dem Schloss ein gelbes Dreieck angezeigt.

2011

Alle

SHA1 ist decpreciated.

SHA-1's use on the Internet has been deprecated since 2011,
Quelle http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

Eigene PKI umstellen

Die großen bekannten Zertifizierungsstellen haben ihre Infrastrukturen schon entsprechend umgestellt und die Stammzertifikate werden von Microsoft, Chrome, FireFox etc. auch schon verteilt. Wer aber eine eigene PKI betreibt, muss hier vielleicht tätig werden und erst einmal die Zertifizierungsstelle umkonfigurieren, damit sie SHA-256-Zertifikate ausstellt. Wenn die PKI halbwegs Standard installiert ist, dann geht das durch folgenden Dreizeiler:

net stop certsrv
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
net start certsrv

Danach sollte die PKI per Default Zertifikate mit SHA256 ausstellen. Ihr eigenes Stammzertifikat ist aber noch weiterhin SHA1 oder das, was sie damals bei der Einrichtung ausgewählt haben. Hier gibt es von Microsoft noch keine mir bekannte Frist. Sie können aber dennoch natürlich auch das Zertifizierungsstellen-Zertifikat auf SHA256 umstellen.

Das ist dann aber ein "neues" Zertifikate, welches auf allen Clients wieder als "Trusted" addiert werden muss. Insofern sollten Sie nach dieser Änderung möglich schnell das neue Stammzertifikat auf möglichst viele Clients bringen, ehe Sie Zertifikate mit diesem neuen Zertifikat signieren.

Es kann in diesem Zuge interessant sein, besser parallel eine neue PKI aufzubauen, bei der dann auch viele der früheren Fehler mit einer richtigen Planung nicht mehr gemacht werden. Dann haben Sie eine neue PKI, deren Stammzertifikat verteilt wird, während die alte PKI noch einige Zeit aktiv sein kann.

BRK3197 - Find out everything you wanted to know about SHA-1 to SHA-2 migrations (Microsoft Ignite)
https://channel9.msdn.com/Events/Ignite/2016/BRK3197

Webserver, Exchange, Skype for Business

Ihre eigene PKI hat sicherlich Zertifikate für ihre Dienste ausgestellt. Auch hier sollten Sie prüfen, ob diese Zertifikate noch SHA-1-Zertifikate nutzen. Allein mit der Umstellung der PKI ist es nicht getan. Die Clients verbinden sich per TLS mit dem Server und wenn die Clients dem Zertifikat nicht mehr vertrauen, weil es mit SHA1 aus deren Sicht zu "Unsicher" ist, dann muss das Zertifikat auf dem Server getauscht werden.

Wenn im Rahmen des SHA1-Wechsels auch die PKI getauscht wurde, sollte man das neuen "frische" Zertifikat der neuen PKI erst dann aktivieren, wenn alle Clients auch der neuen PKI vertrauen.

Vergessen Sie aber nicht die "alten Zertifikate" nach dem Tausch auch sauber zurück zu rufen.

Zertifikate "finden"

Bislang war ja alles eigentlich "gut verständlich" aber eine knifflige Frage bleibt natürlich immer: Wo kommen die Zertifikate denn überall zum Einsatz. Hier kommt ihnen zugute, dass die Zertifizierungsstelle eine Liste der ausgestellten Zertifikate führt, die auch exportiert werden kann. Per PowerShell kann diese Information anscheinend noch nicht ausgelesen werden aber CERTUTIL kann CSV-Dateien schreiben.

certutil -view -out "RequestID,RequesterName,RequestType,NotAfter,CommonName,Certificate Template" csv  > c:\temp\certlist.csv

Die CSV-Datei kann dann einfach per PowerShell (Import-CSV) , Excel oder andere Tools ausgewertet werden. So können Sie sich eine Liste der Zertifikate erstellen und Server für Server abgehen.

Es ist nicht hinreichend per PortScan ein Netzwerk nach TLS-Ports abzufragen. Zertifikate werden nicht nur auf den Port 443 und 5061 genutzt. Auch POP und IMAP (993/995) sind Kandidaten. Zertifikate kommen aber auch auf "Nicht Standard Ports" zum Einsatz oder sogar zur Client-Authentifizierung. Der einzige Weg ist hier wirklich die Bearbeitung der Liste. Dies ist übrigends auch ein guter Startpunkt zum Aufräumen nicht mehr vorhandener Systeme.

Weitere Links