Archive for the ‘Zertifikate’ Category

Warum kann man in Windows 10 das Datum nicht mehr per Eingabeaufforderung ändern?

14 Februar 2019

Die Krux mit der Zeit bei Windows 10 oder warum zum Teufel kann ich meinem Windows nicht so einfach das Datum vorgeben, das ich möchte? Ach waren das noch schöne DOS-Zeiten. Man gab DATE ein, setzte das gewünschte Datum, startete seine Anwendung und konnte gemütlich arbeiten.

Vista brachte mit der UAC schon einige Änderungen mit, dass man zwingend Adminrechte zum Datumändern braucht usw. Aber Windows 10 in der aktuellen Ausführung (mind. seit 1607) treibt die Sache nochmal auf die Spitze! Dort gibt es sogenannte sichere Zeiten. Wehe, man befindet sich nicht in der “sicheren” Zeit, dann gibt es ganz schnell Chaos, Windows greift ein und stellt die richtige Zeit wieder her.

Im Grunde läuft die Geschichte so, man macht eine Admin-Eingabeaufforderung auf, gibt

DATE 10.10.18

ein, prüft diese mittels

DATE /t

bekommt meist das korrekte Datum angezeigt. Aber wehe die Zeitgötter sind gegen einen, dann startet man seine Anwendung mit der man in der Vergangenheit arbeiten möchte, doch unversehens hat man wieder die korrekte aktuelle Zeit.

Profis kommen dann und sagen: Ja man muss ja auch den Windows-Zeitgeberdienst W32Time ausschalten, also führt man noch ein

SC.EXE stop w32time

aus und probiert danach nochmal sein Glück. Klappt meist nicht, wenn definitiv nicht, liegt es vielleicht daran dass man sich in einer virtuellen Maschine befindet, da muss man z. B. noch den Hyper-V-Dienst für Zeitsynchronisierung ausschalten, also

SC.EXE stop vmictimesync

Vielleicht klappt es nun aber die meisten werden feststellen, Windows ist so schnell zurück bei der alten Zeit so schnell kann man manchmal gar nicht schauen.

Für die Behandlung von Daten seien hier noch der Vollständigkeit halber der Aufruf der GUI für die Datumsänderung genannt:

timedate.cpl

Und um in Powershell das Datum zu ändern, ohne die aktuelle Uhrzeit zu verlieren verwendet man:

set-Date "10.10.2018 $((Get-Date).ToLongTimeString())"

Die Abfrage der Zeitdienste in Windows sind mittels

get-service *time*

zu erhalten, wo W32Time, TimeBrokerSvc und bei Hyper-V VMs VMIcTimeSync auftauchen. Wobei mir die Rolle des TimeBrokerSync noch nicht klar ist.

Aber nun weiter im Thema. Um die Zufälligkeiten der Datumsrückstellung besser in den Griff zu bekommen, muss man Windows abgewöhnen bei der Kommunikation mit dem Internet SSL-Zertifikate zur Berechnung der Uhrzeit herzunehmen. Das Prinzip nennt sich Secure Time Seed of High Confidence (STSHC). Dabei handelt es sich nicht um ein typisches Microsoft Marketingbuzzword sondern eher um eine interne, und wie so oft, offiziell undokumentierte Sache. Einzig ein MS-Angestellter hat über das Prinzip ein paar Dinge geschrieben: https://blogs.msdn.microsoft.com/w32time/2016/09/28/secure-time-seeding-improving-time-keeping-in-windows/.

Kurz gesagt: Mit jeder verschlüsselten Kommunikation ins Internet kann Windows die Zeit korrigieren. Und das findet in Windows 10 mehr als häufig statt und erklärt auch das erratische Verhalten, welches man meist beobachten kann.

Man kann die aktuelle Einstellung durch folgende Zeile abfragen:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData

wird der Wert 1 geliefert ist die Zeitkorrektur durch SSL-Zertifikate aktiv, bei 0 ist sie ausgeschaltet.

Aktivieren (Vorgabe) kann man das Verhalten mit

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 1

und mit

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0

abschalten.

Läuft der W32Time-Dienst und aktiviert man das Logging z. B. mittels

w32tm /debug /enable /file:C:\temp\w32tm.log /entries:0-300 /size:1000000

dann findet man in w32tm.log solche Eintragungen, wenn STSHC eingreift und die Zeit umstellt:

152670 12:34:36.6488208s – Setting the system time because it is outside the secure time limits.
152670 12:34:36.6488464s -  Current system time:  12:34:36.648 10/10/2018
152670 12:34:36.6488666s -  Target system time:  12:34:36.455 2/11/2019
152712 12:34:36.4608379s -  (AUDIT) Time Jump of 3628799 seconds.
152712 12:34:36.4608764s – ClockDispln Discipline: *SET*SECURE*TIME*

Bei dem STSHC-Komplex sei auch noch dieser Registry Key genannt:

Get-ItemProperty HKLM:\System\CurrentControlSet\Services\W32Time\SecureTimeLimits\

der da die Properties

SecureTimeConfidence : 7
SecureTimeEstimated  : 131945739321311682
SecureTimeHigh       : 131945775321311682
SecureTimeLow        : 131945703321311682
SecureTimeTickCount  : 29139718

auflistet. High, Low und Estimated sind wieder interessant und sind zwei Stunden auseinander. Man kann die Werte in normale DateTime-Variablen konvertieren, muss aber noch 1600 dazu addieren, um aktuelle Werte zu erhalten. Die Vorgehensweise sieht so aus

([DateTime](Get-ItemProperty HKLM:\System\CurrentControlSet\Services\W32Time\SecureTimeLimits\ -Name SecureTimeHigh).securetimehigh).AddYears(1600)

und ist hier beschrieben: http://byronwright.blogspot.com/2016/03/windows-10-time-synchronization-and.html.

Wenn man nun die SecureTimeLimits aus der Registry hernimmt, dann scheint immer gegen diese Verglichen zu werden, ob die Uhrzeit angepasst werden muss. Ist die aktuelle Uhrzeit des Rechners also außerhalb von Low und High wird sie auf Estimated gesetzt. Doch wie und wann werden High und Low gesetzt? Scheinbar beim Rauf- und Runterfahren des Rechners: http://byronwright.blogspot.com/2016/03/more-on-secure-time-for-windows-10.html. Wobei ich dies bisher noch nicht getestet habe.

Interessante Geschichte was mit der Zeitgebung durch SSL-Zertifikate passieren kann: https://www.reddit.com/r/sysadmin/comments/61o8p0/system_time_
jumping_back_on_windows_10_caused_by/
. Daraufhin gab es auch noch einen offiziellen KB-Artikel: https://support.microsoft.com/en-us/help/3160312/a-computer-that-is-running-windows-10-version-1511-reverts-to-a-previo.

Das ist sicherlich noch nicht alles was man zum Thema wissen müsste und sollte aber zumindest ein Anfang…

Ach, noch ein Dokument wegen Zeitsynckorrektheit von MS: http://windocs.blob.core.windows.net/windocs/WindowsTimeSyncAccuracy_Addendum.pdf, der Verweis auf den wichtigsten Zeit-Blog von MS: https://blogs.msdn.microsoft.com/w32time/ und noch die aktuelle MSDN-Doku zum Windows Zeitgeber Dienst: https://docs.microsoft.com/de-de/windows-server/networking/windows-time-service/windows-time-service-top.

Werbeanzeigen

Software für Hardware Token Provider auf Rechner über Remote Desktop zu installieren, ist keine gute Idee

3 März 2016

Wir befinden uns im Jahr 2016. Im Jahr 2006 erblickte Windows Vista die Welt und brachte damals für die Windowswelt nach Windows XP größere Veränderungen mit. Aber selbst heute bekommt man noch Auswirkungen von damals zu spüren, durch unsachgemäße Fehlermeldungen und faule Programmierer!

Aktuelles Beispiel, es sollte der SafeNet Authentication Client Version 9.0 installiert werden, damit ein Zertifikat auf einem USB eToken gespeichert werden kann.

Es wurden mehrere Rechner probiert jeweils mit Windows 7 SP1 und Windows 8.1 mit allen aktuellen Updates, auch 64-Bit und 32-Bit war dabei. Am Ende wurde auch die Installation nur in Englisch durchgeführt, wäre nicht das erste Mal, dass es nur so funktioniert. Aber jedes Mal kam es zu der Fehlermeldung:

There appears to be a problem with the Smart Card Resource Manager configuration on this computer. \nThe installation will be completed, but may not work correctly.\nPlease contact your System Administrator to solve the problem.

Wie die Meldung schreibt funktioniert danach die Sache einfach nicht.

Der Support verwies nur auf dieses Dokument und den Admin: https://kb.safenet-inc.com/kb/index?page=content&id=S438&actp=LIST_POPULAR

Wenn man sich die Log-Dateien anschaut, dann taucht in der eTCoreInst.LOG, welche sich im %TEMP%-Verzeichnis befindet dieser Eintrag auf:

(ThID:2360): Err in RMTable::snapshot, SCardEstablishContext fails, rv=0x8010001d
(ThID:2360): RMTable::snapshot: exit , rv=0x8010001d
(ThID:2360): Err in RMTable::listReaders, snapshot() fails, rv=0x8010001d
(ThID:2360): RMTable::listReaders: exit , rv=0x8010001d
(ThID:2360): Trace in snapshotScardDevice, Cannot list readers

Recherchiert man damit etwas, stolpert man über diesen Artikel: https://blogs.msdn.microsoft.com/alejacma/2011/05/19/scardestablishcontext-fails-with-scard_e_no_service-error/

Da steht dann etwas von:

SCardEstablishContext API is returning that error because it gets an Access Denied error when trying toopen an event called “Global\Microsoft Smart Card Resource Manager Started” with OpenEvent API. The default security for that event on Vista and Windows 7 specifies that only SYSTEM, LOCAL SERVICE and INTERACTIVE users have access to it. NETWORK SERVICE or non-interactive users won’t be able to access the event.

OK, dann ist alles klar. Das ist ein aus XP-Zeiten geerbtes Problem. D. h. man muss physisch angemeldet sein, damit es funktioniert.

Alle obigen Versuche, wo es nicht klappte, wurden per Remote Desktop durchgeführt! Siehe da, einmal physisch am Rechner und schon funktionierte es!!

Gilt für alle, die Zertifikate von DigiSafe, GlobalSign, TrustZone, Entrust und wie sie alle heißen benutzen, welche die Hardware von Safenet einsetzen. Daneben gibt es auch noch Banken…

Noch ein interessanter Blogeintrag, wie man ein normales Zertifikat auf den USB Token bekommt kann: https://blogs.msdn.microsoft.com/ieinternals/2015/01/28/authenticode-in-2015/.

Probleme mit Transportverschlüsselung, Zertifikaten oder Passwörtern bei SMTP-Servern mittels Powershell überprüfen

23 August 2015

Gestern hatte ich schon im Artikel um den Telnet-Client-Ersatz https://newyear2006.wordpress.com/2015/08/22/der-kleine-telnet-client-in-powershell/ ein Beispiel angeführt, wie man einen SMTP-Server anfahren kann. Am entscheidenden Punkt mit dem TLS-Handshake hatte ich aber aufgehört. In der heutigen Zeit, wo im Prinzip alles über ein abgesichertes Transportprotokoll übertragen werden sollte, ein absolutes NoGo. Aus diesem Grund hier die Fortsetzung, wie der TLS-Handshake durchgeführt werden kann.

Vorab noch eines: Die Skripte sind Testskripte um entweder die Funktion oder einen einzelnen Problemfall nachvollziehen zu können. Sie sind nicht dazu gedacht bei irgendwelchen Automationsprojekten eingesetzt zu werden. Denn es fehlen Fehlerabfragen und die ordentliche Freigabe der verwendeten Ressourcen. In diesem Zusammenhang sei auch darauf hingewiesen, wenn mal etwas nicht klappt, einfach das Powershellfenster schließen und ein neues aufmachen, damit die belegten Ressourcen beim Prozessbeenden freigegeben werden. Hier nochmal der Link zum STARTTLS-Kommando und was dabei zu beachten ist: https://tools.ietf.org/html/rfc3207. So nun aber los.

Zunächst nochmal der grundsätzliche Verbindungsaufbau:

# Verbindung zu Web.de aufbauen
$c=Test-NetConnection smtp.web.de -Port 587

# Antwort vom SMTP-Server holen und ausgeben
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# Begrüßung durchführen
$buffer=[System.Text.Encoding]::ASCII.GetBytes("EHLO $Env:Computername`r`n")
$c.TcpClientSocket.Send($buffer)
Sleep -Seconds 1

# Antwort vom SMTP-Server holen
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# STARTTLS-Anfrage starten
$buffer=[System.Text.Encoding]::ASCII.GetBytes("STARTTLS`r`n")
$c.TcpClientSocket.Send($buffer)
Sleep -Seconds 1

# Bei dieser Antwort sollte 220 rauskommen,
# sonst gibt es ein Problem
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

An diesem Punkt kommt wieder der TLS-Handshake ins Spiel, der nun erfolgen sollte. Wenn man sich so die üblichen Dokus durchschaut, dann würde man meinen, man könnte direkt SslStream-Konstruktor mit dem TcpClientSocket aufrufen. Doch dies klappt leider nicht. Statt dessen muss zunächst ein Networkstream für den Socket erzeugt werden  https://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx. Dieser Punkt ist minimal aber der entscheidende Baustein, denn danach ist alles einfach. Sobald man dann den Socket als SslStream https://msdn.microsoft.com/en-us/library/system.net.security.sslstream.aspx hat, findet man wieder massig Informationen im Netz wie es weitergeht.

# für den weiteren Gang ist entscheidend, dass man einen Stream braucht
# vom Socket erhält man einen Stream, durch Weitergabe an NetworkStream-Klasse
$n=New-Object System.Net.Sockets.NetworkStream $c.TcpClientSocket

# über den Networkstream kann man nun SslStream aktivieren:
$ssl = New-Object System.Net.Security.SslStream $n, $true

Fast geschafft, der eigentliche Handshake https://msdn.microsoft.com/en-us/library/system.net.security.negotiatestream.authenticateasclient(v=vs.110).aspx beginnt hiermit:

# nun kann man den eigentlichen TLS Handshake starten, dazu muss nochmal der Host angegeben werden
$ssl.AuthenticateAsClient($c.ComputerName)

Ab jetzt hat man im Normalfall in $ssl alle Informationen, die man braucht. Somit lässt sich die Verbindung nun grob debuggen. Apropos debuggen, man kann bei Problemen auch das .Net-Tracing-System aktivieren, um mehr Infos bei Problemen zu erhalten, hier hab ich schon mal etwas darüber geschrieben: https://newyear2006.wordpress.com/2014/12/13/fr-powershell-net-framework-tracing-aktivieren/. Wer sich konkret dafür interessiert, was beim TLS-Handshake alles passiert, der möchte diesen Artikel lesen: https://www.simple-talk.com/dotnet/.net-framework/tlsssl-and-.net-framework-4.0/.

Hier nun die Ausgabe von $ssl:

TransportContext          : System.Net.SslStreamContext
IsAuthenticated           : True
IsMutuallyAuthenticated   : False
IsEncrypted               : True
IsSigned                  : True
IsServer                  : False
SslProtocol               : Tls
CheckCertRevocationStatus : False
LocalCertificate          :
RemoteCertificate         : System.Security.Cryptography.X509Certificates.X509Certificate
CipherAlgorithm           : Aes256
CipherStrength            : 256
HashAlgorithm             : Sha1
HashStrength              : 160
KeyExchangeAlgorithm      : 44550
KeyExchangeStrength       : 256
CanSeek                   : False
CanRead                   : True
CanTimeout                : True
CanWrite                  : True
ReadTimeout               : -1
WriteTimeout              : -1
Length                    :
Position                  :
LeaveInnerStreamOpen      : True

Die interessanten Eigenschaften hab ich mal gelb markiert. Hier fällt vor allem auf, dass beim KeyExchangeAlgorithm momentan 44550 steht, welche selbst im .Net-Framework 4.6 nicht dokumentiert ist. Allerdings gibt es eine Erklärung dazu: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/d0298622-a7cc-40e8-a4bf-8b74696ff548/sslstreamkeyexchangealgorithm-44550?forum=netfxbcl. Kurz: Beim Wert 44550 handelt es sich um einen ECDH Ephermal. Weitere Infos dazu: https://tools.ietf.org/html/rfc5753#section-3.1.

Weiter wäre zu bemerken, dass die Eigenschaft SslProtocol auf Tls steht, was gleichbedeutend mit TLS 1.0 ist. Aktuell sollte immer TLS 1.2 verwendet werden. Hier stellt sich die Frage, liegt es am Server oder liegt es am Client, sprich in diesem Fall am .Net Framework? Diese Frage wollen wir ein anderes Mal betrachten.

Man kann auch das erhaltene Zertifikat abfragen:

$ssl.RemoteCertificate.ToString($true)
[Subject]
  CN=smtp.web.de, E=server-certs@1und1.de, L=Montabaur, S=Rhineland-Palatinate, OU=WEB.DE, O=1&1 Mail & Media GmbH, C=DE

[Issuer]
  CN=TeleSec ServerPass DE-1, STREET=Untere Industriestr. 20, L=Netphen, PostalCode=57250, S=NRW, OU=T-Systems Trust Center, O=T-Systems Internatio
nal GmbH, C=DE

[Serial Number]
  00A684C2D320436B39

[Not Before]
  21.08.2013 10:35:51

[Not After]
  27.08.2016 01:59:59

[Thumbprint]
  40051058DE6797D8ACFAF55224CF5282F44E0B5D

Falls beim TLS-Handshake etwas schief gehen sollte, dann hat dies meist mit den Zertifikaten zu tun. Wie man diesem Problem auf den Grund gehen kann, habe ich in einem früheren Blogartikel bereits beschrieben: https://newyear2006.wordpress.com/2014/01/04/ssltls-fehler-in-powershell-bzw-wie-man-zertifikatsprobleme-unter-windows-analysieren-kann/.

OK jetzt sind wir schon so weit gekommen, wäre schön, wenn man jetzt noch prüfen könnte, ob der Benutzer tatsächlich seine SMTP-Zugangsdaten kennt. Dazu richten wir einen Reader- und Writer- vom SSL-Stream ein, senden nochmals das obligatorische EHLO und anschließend die gewünschte Authentifizierungsmethode, hier LOGIN:

# für die weitere Kommunikation richtet man sich am besten zusätzliche Streams ein:
$reader = New-Object System.IO.StreamReader $ssl
$writer = New-Object System.IO.StreamWriter $ssl
$writer.AutoFlush = $true

# damit wird die weitere Kommunikation einfacher und das Spiel beginnt von vorne:
$writer.WriteLine("EHLO $Env:Computername")
while ($reader.Peek() -gt -1) {
    $reader.ReadLine()
}

$writer.WriteLine("AUTH LOGIN")
$reader.ReadLine()

Nun liefert der Server ein kryptisches VXNlcm5hbWU6, was ganz einfach Base64 kodiert für Username: steht. Man kann dies ganz einfach prüfen, wenn man diesen Befehl ausführt:

[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("VXNlcm5hbWU6"))

Man sollte nun also den Benutzernamen liefern, z. B. so:

$user = "meinewebdeadresse@web.de"
$cred = Get-Credential -UserName $user -Message "Bitte Passwort eingeben"
$pass = $cred.GetNetworkCredential().Password
$userBytes = [System.Text.Encoding]::ASCII.GetBytes($user)
$userBase64 = [System.Convert]::ToBase64String($userBytes)
$writer.WriteLine($userBase64)
$reader.ReadLine()

$passBytes = [System.Text.Encoding]::ASCII.GetBytes($pass)
$passBase64 = [System.Convert]::ToBase64String($passBytes)
$writer.WriteLine($passBase64)
$reader.ReadLine()

Es wird noch mittels UGFzc3dvcmQ6 nach dem Passwort gefragt, welches, wie der Benutzername auch per Base64 Kodierung geliefert wird. Am Ende sollte man ein

235 Authentication succeeded

sehen, dann weiß man, dass alles korrekt ist.

Möchte man die Verbindung ordentlich beenden, schiebt man noch dieses hinterher:

# damit wird die weitere Kommunikation einfacher und das Spiel beginnt von vorne:
$writer.WriteLine("QUIT")
$reader.ReadToEnd();

# Streams und Sockets schließen
$ssl.Close()
$n.Close()
$c.TcpClientSocket.Close()

Hier nochmal alles als GIST zur besseren Lesbarkeit, bzw. bei Erweiterungen: https://gist.github.com/newyear2006/2a6a3fb0cea8dc1063ba

Durch all diese Möglichkeiten zum Debuggen erübrigt sich langsam der Griff nach OpenSSL s_client https://www.openssl.org/docs/manmaster/apps/s_client.html zum Testen von SMTP-Verbindungen.

Neue Parameter für New-SelfSignedCertificate

21 August 2015

Per Zufall bin ich heute über eine interessante Sache gestoßen. Bereits mit Windows 8 wurden die PKI-Powershell Cmdlets eingeführt. Mit enthalten ist New-SelfSignedCertificate. Das Problem dabei war, dass das Anwendungsgebiet des Cmdlets wegen fehlender Paramater ziemlich limitiert war.

Als ich heute unter Windows 10 New-SelfSignedCertficate verwendete und mittels TAB-Taste die Parametervervollständigung nutzte, wunderte ich mich nicht schlecht, als auf einmal eine Fülle von unbekannten Parametern auftauchte. Darunter waren so Dinge Extension, KeyUsage, KeyProtection.

Durch die Fülle der Parameter war ich etwas überfordert und mich interessierte vor allem eine komplette Auflistung der Parameter. Wie in Powershell üblich verwendet man dazu Get-Help:

PS > get-help New-SelfSignedCertificate

NAME
    New-SelfSignedCertificate

ÜBERSICHT
    Creates a new self-signed certificate for testing purposes.

SYNTAX
    New-SelfSignedCertificate [-CertStoreLocation <String>] [-CloneCert <Certificate>] [-DnsName <String>] [-Confirm]
    [-WhatIf] [<CommonParameters>]

BESCHREIBUNG
    The New-SelfSignedCertificate cmdlet creates a self-signed certificate for testing purposes. Using the CloneCert

Mmmhh, das war irgendwie nicht das was ich erwartet hatte. OK, vielleicht hilft ein Update der Hilfe, also Update-Help durchgeführt. Leider war das Ergebnis unverändert. Nun noch der Versucht online etwas mehr Infos zu bekommen, mittels

Get-Help New-SelfSignedCertificate –Online

Aber wieder nix. Ganz im Gegenteil, man landet momentan noch auf der Hilfeseite von Windows Server 2012 R2 und Windows 8.1 Hilfe. Mal wieder ein ganz mieses Qualitätsmanagement von Microsoft. Auf der anderen Seite kann man sagen, das ist so gewollt, weil vielleicht doch noch Beta.

Da Powershell wegen seiner flexiblen Innereien so genial ist, gibt es vielleicht noch eine andere Möglichkeit herauszufinden, was Sache ist. Wenn schon Get-Help die falsche Syntax hat, aber die TAB-Vervollständigung die ganzen Parameter kennt, dann kann man diese Parameter sicher auch abfragen. Dem ist tatsächlich so:

PS > $P= get-command New-SelfSignedCertificate
PS > $p.Parameters

Key                         Value
—                         —–
SecurityDescriptor          System.Management.Automation.ParameterMetadata
TextExtension               System.Management.Automation.ParameterMetadata
Extension                   System.Management.Automation.ParameterMetadata
HardwareKeyUsage            System.Management.Automation.ParameterMetadata
KeyUsageProperty            System.Management.Automation.ParameterMetadata
KeyUsage                    System.Management.Automation.ParameterMetadata
KeyProtection               System.Management.Automation.ParameterMetadata
KeyExportPolicy             System.Management.Automation.ParameterMetadata
KeyLength                   System.Management.Automation.ParameterMetadata

Um die Sache etwas übersichtlicher zu machen, verwendet man besser:

PS > $p.Parameters.keys | sort
AlternateSignatureAlgorithm
CertStoreLocation
CloneCert
Confirm
Container
CurveExport
Debug
DnsName
ErrorAction
ErrorVariable
ExistingKey
Extension
FriendlyName
HardwareKeyUsage
HashAlgorithm
InformationAction
InformationVariable
KeyAlgorithm
KeyDescription
KeyExportPolicy
KeyFriendlyName
KeyLength
KeyLocation
KeyProtection
KeySpec
KeyUsage
KeyUsageProperty
NotAfter
NotBefore
OutBuffer
OutVariable
Pin
PipelineVariable
Provider
Reader
SecurityDescriptor
SerialNumber
Signer
SignerPin
SignerReader
SmimeCapabilities
Subject
SuppressOid
TestRoot
TextExtension
Type
Verbose
WarningAction
WarningVariable
WhatIf

Alle fett dargestellten Parameter sind neu hinzugekommene. Wie man sieht, eine ganze Menge. Nun weiß man was es gibt aber welche Parameter kann man konkret füttern? Man kann hergehen und alles ausprobieren. Denn es gibt aktuell keinen einzigen Google Suchtreffer mit z. B. New-SelfsignedCertificate mit KeyUsage: https://www.google.com/search?q=new-selfsigncertificate+keyusage&oq=new-selfsigncertificate+keyusage&aqs=chrome..69i57.7167j0j7&sourceid=chrome&es_sm=93&ie=UTF-8#q=%22new-selfsigncertificate%22+%22keyusage%22
Man kann aber auch nachdenken und entdeckt:

Es kam diese Woche die Server 2016 Technical Preview 3 heraus. Was liegt also näher dort mal die Lage zu checken. Gesagt, getan. Tatsächlich sind hier bei Aufruf von Get-Help die Parameter alle verfügbar:

SYNTAX
New-SelfSignedCertificate [-SecurityDescriptor <FileSecurity>]
[-TextExtension <string[]>] [-Extension <X509Extension[]>] [-HardwareKeyUsage <HardwareKeyUsage[]> {None | SignatureKey | EncryptionKey | GenericKey | StorageKey | IdentityKey}] [-KeyUsageProperty <KeyUsageProperty[]> {None | Decrypt | Sign | KeyAgreement | All}] [-KeyUsage <KeyUsage[]> {None | EncipherOnly | CRLSign | CertSign | KeyAgreement | DataEncipherment | KeyEncipherment | NonRepudiation | DigitalSignature | DecipherOnly}] [-KeyProtection <KeyProtection[]> {None | Protect | ProtectHigh | ProtectFingerPrint}] [-KeyExportPolicy <KeyExportPolicy[]> {NonExportable | ExportableEncrypted | Exportable}] [-KeyLength <int>] [-KeyAlgorithm <string>] [-SmimeCapabilities] [-ExistingKey] [-KeyLocation <string>] [-SignerReader <string>) [-Reader <string>] [-Si gnerPin <securestring>] [-Pin <securestring>] [-KeyDescription <string>] [-KeyFriendlyName <string>] [-Container <string>] [-Provider <string>] [-CurveExport <CurveParametersExportType> {None | CurveParameters | CurveName}] [-KeySpec <KeySpec> {None | KeyExchange | Signature}] [-Type <CertificateType> {Custom | CodeSigningCert | DocumentEncryptionCert | SSLServerAuthentication | DocumentEncryptionCertLegacyCsp}] [-FriendlyName <string>] [-NotAfter <datetime>] [-NotBefore <datetime>] [-SerialNumber <string>] [-Subject <string>] [-DnsName <string[]>] [-Suppressoid <string[]> [-HashAlgorithm <string>] [-AlternateSignatureAlgorithm] [-TestRoot] [-Signer <Certificate>] [-CloneCert <Certificate>] [-CertStoreLocation <string>] [-whatlf] [-Confirm] [<CommonParameters>]

Ja das ist doch mal was.

Es geht noch besser, alle Parameteroptionen die beim Server aufgeführt werden, sind auf Windows 10 auch verfügbar! Ja dann kann man ja was daraus machen.

Eine weitere Hilfe stellt die Implementierung von Vadim Podans dar, welcher bereits früher für eine umfassende PKI-Unterstützung in Powershell gesorgt hat. Er hat in der Powershell Script Gallery bereits ein New-SelfSignedCertificate Skript veröffentlicht: https://gallery.technet.microsoft.com/scriptcenter/Self-signed-certificate-5920a7c6.

So das war es zunächst, sinnvolle Anwendungen kommen bei Gelegenheit…

Neues RFC 7468 welches die Textcodierung von Zertifikaten beschreibt

10 Juli 2015

In der heutigen Zeit hat man oft mit Zertifikaten zu tun. Mal abgesehen von der lästigen Arbeit diese regelmäßig austauschen zu müssen, wenn mal wieder OpenSSL hoch geht, gibt es hin und wieder auch Probleme und Ungereimtheiten, warum etwas nicht funktioniert.

Licht ins Dunkel bringt das RFC 7468 – Textual Encodings of PKIX, PKCS and CMS Structures – https://tools.ietf.org/html/rfc7468.

Es erläutert die Grundstruktur von Zertifikaten in Textform, wie z. B.:

-----BEGIN CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQ
swCQYDVQQGEwJCRTEPMA…

oder

-----BEGIN CMS-----
MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhv
cNAQkQAwgwXgYJKoZIhvcNAQcBoFEET3icc…

Dabei ist der Aufbau immer derselbe und beginnt mit

-----BEGIN

danach folgt durch Leerzeichen getrennt eines dieser Labels:

CERTIFICATE, X509 CRL, CERTIFICATE REQUEST, PKCS7, CMS, PRIVATE KEY, ENCRYPTED PRIVATE KEY, ATTRIBUTE CERTIFICATE, PUBLIC KEY

Labels mit Links zu den tiefergehenden RFCs: https://tools.ietf.org/html/rfc7468#section-4.

Das Dokument geht in Anhang A auch auf nichtkonforme Labels ein und bringt ein paar Beispiele wie ein preeb (preeb steht für “pre-encapsulation boundary”) nicht aussehen sollte, obwohl diese hin und wieder anzutreffen sind. https://tools.ietf.org/html/rfc7468#appendix-A:

Negativbeispiele sind:

—–BEGIN X509 CERTIFICATE—–

—–BEGIN X.509 CERTIFICATE—–

—–BEGIN NEW CERTIFICATE REQUEST—–

—–BEGIN CERTIFICATE CHAIN—–

OpenSSL z. B. erlaubt die Verwendung von “BEGIN X509 CERTIFICATE”: https://openssl.org/docs/apps/x509.html. Auch Chrome scheint die Negativvarianten zu unterstützen: https://code.google.com/p/chromium/issues/detail?id=136534.

OpenSSL unter Windows einrichten

30 März 2015

Eine schöne Anleitung OpenSSL unter Windows einzurichten und sich Zertifizierungsstellen einzurichten, findet man hier: http://blog.didierstevens.com/2015/03/30/howto-make-your-own-cert-with-openssl-on-windows/

Malware-Plage und jetzt auch noch Superfish

22 Februar 2015

Es wird immer schlimmer und keiner blickt mehr richtig durch. Das ganze TLS und Zertifikatsgedöns ist nicht nur kompliziert, sondern kann auch schön ausgehebelt werden. Aktuelles Beispiel Visual Search bzw. Visual Discovery von Superfish.

Nicht nur, dass es Leute gibt, die sich bewusst oder unbewusst irgendwelche schrottigen Onlinevergleichstools auf den Rechner laden und dadurch massiv ausspioniert werden bzw. tolle Werbeeinblendungen bekommen, nein jetzt werden auch noch Rechner ab Werk mit solchen Programmen ausgeliefert.

Heise Online meldet:

Ab sofort können sich Cyber-Gangs online gegenüber Besitzern von vielen Lenovo-Laptos mit einer beliebigen Identität ausweisen und gefährliche Man-in-the-Middle-Angriffe tätigen.
http://www.heise.de/newsticker/meldung/Lenovo-Laptops-Sicherheitsluecke-erreicht-kritisches-Stadium-2555934.html

Die Vorgehensweise, die Sache ausnutzen zu können ist dabei recht einfach. Robert Graham zeigt mit einfachsten Mitteln, wie es geht. http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html. Er startet einfach die Malware und erzeugt mittels Procdump von Sysinternals einen Speicherdump des Prozesses. Danach holt er sich wiederum mittels Sysinternals-Tool Strings alle Strings aus dem Dump. Schwupps hat er den privaten Schlüssel des Zertifikats. Normalerweise müsste man nun das Passwort für den privaten Schlüssel brutforcen. Aber das kann dauern. Also geht er einfach her und verwendet eine Dictionary-Attacke. Doch zunächst ohne Erfolg. Dann denkt er sich, vielleicht ist das Passwort ja im Stringdump enthalten und schwupps hat er es: “komodia”.

Warum ist dies nun alles so gefährlich? Ein schöner einleitenden Artikel bringt wiederum Robert Graham: http://blog.erratasec.com/2015/02/some-notes-on-superfish.html. Die Quintessenz daraus ist, auch wenn man die Malware deinstalliert, dass Stammzertifikat bleibt immer noch auf dem Rechner und erlaubt später problemlos “Man in the middle”-Attacken.

Damit nicht alles graue Theorie bleibt, geht wiederum Robert Graham zum Beweis über und bastelt mittels Raspberry Pi ein plastisches Beispiel. Mittels eines Pi für 40€, einem WLAN-Modul für 15€, einer Speicherkarte für 5€ bastelt er einen Man in the Middle Proxy. dazu verwendet er SSLSplit und die Zertifikate und Passwörter von Superfish und kann nun problemlos seine verschlüsselte TLS-Kommunikation mitlesen. http://blog.erratasec.com/2015/02/exploiting-superfish-certificate.html. Natürlich muss es nicht ein Pi sein, sondern kann jede x-beliebige Maschine sein, es geht nur darum deutlich zu machen, dass so ein kleines Stück Hardware für solche Attacken nicht teuer sein muss.

Ach und aus Erfahrung kann ich sagen, dass Rechner, bei denen so eine Spionagesoftware mal nicht richtig funktioniert, massiv Probleme mit ihrer Internetverbindung haben und der unbedarfte Benutzer ständig komische Fehlermeldungen zwecks Proxy und so Gedöns an den Latz geknallt bekommt.

Hier noch ein paar Powershell-Befehle mittels derer man das Superfish-Zertifikat ermitteln kann:

dir cert:\ -Recurse| where {$_.Subject -match "Superfish"}

oder direkt per Fingerprint:

dir cert:\ -Recurse| where {$_.Thumbprint -eq "C864484869D41D2B0D32319C5A62F9315AAF2CBD"}

Wer braucht da noch nen Staatstrojaner, wenn die Computerhersteller bereits alles dafür tun, die Geräte mit Malware auszustatten. Interessant in diesem Zusammenhang ist noch dieses: http://blog.fefe.de/?ts=aa16d2ff. Der große Bruder lässt grüßen…

Zertifikatsdialoge aus Powershell heraus anzeigen

28 Dezember 2014

Beim beschäftigen mit Zertifikaten in Powershell wäre es manchmal hilfreich ein Zertifikat in der üblichen Darstellung unter Windows angezeigt zu bekommen. Dank der nahen Anbindung zum .Net Framework ist dies recht einfach möglich.

Hier ein Beispiel, es wird ein beliebiges Zertifikat zu Demonstrationszwecken ermittelt:

$c=dir cert:\CurrentUser\My| select –First 1

Das Zertifikat in $c kann nun mittels dieses Aufrufs im üblichen Windows Dialog angezeigt werden:

[System.Security.Cryptography.X509Certificates.X509Certificate2UI]
::DisplayCertificate($c)

Beide Zeilen gehören direkt aneinander in eine Zeile!

Aber es geht noch besser. Man kann auch einen Auswahldialog öffnen, mit einer Auswahl von Zertifikaten und dann dem Benutzer einen Dialog anzeigen, wo er das passende Zertifikat auswählen kann.

Zunächst brauchen wir ein paar Zertifikate:

$cs=dir cert:\CurrentUser\My

Leider handelt es sich bei $cs nun um ein Array von Zertifikaten. Damit der Auswahldialog funktioniert, muss eine Zertifikatkollektion vom Typ X509Certificate2Collection übergeben werden. Diese erhält man aber ganz einfach, durch diesen Schritt:

$col=[System.Security.Cryptography.X509Certificates.
X509Certificate2Collection]::new($cs)

Bei obiger Zeilen muss wieder alles in eine Zeile hintereinander geschrieben werden.

Nun hat man auf jeden Fall eine Zertifikatskollektion in $col. Damit kann man nun diesen Aufruf durchführen:

$c=[System.Security.Cryptography.X509Certificates.
X509Certificate2UI]::SelectFromCollection($col,"Überschrift", "Hinweistext", [System.Security.Cryptography.X509Certificates.
X509SelectionFlag]::SingleSelection)

Man bekommt nun alle Zertifikate in $col angezeigt und kann sogar noch die Überschrift und einen Hinweistext beeinflussen. Nach der Auswahl bekommt in $c das ausgewählte Zertifikat zugewiesen.

Hier noch die API-Links:
DisplayCertificate:
http://msdn.microsoft.com/de-de/library/ms223201(v=vs.110).aspx
SelectFromCollection:
http://msdn.microsoft.com/de-de/library/ms223189(v=vs.110).aspx
X509Certificate2Collection:
http://msdn.microsoft.com/de-de/library/system.security.cryptography.x509certificates.
x509certificate2collection(v=vs.110).aspx

SSL/TLS Fehler in Powershell, bzw. wie man Zertifikatsprobleme unter Windows analysieren kann

4 Januar 2014

Beim Herumspielen mit Chocolatey, dazu ein anderes Mal mehr, gab es Probleme auf einem Windows XP-Rechner. Der Windows XP Rechner war für Chocolatey noch nicht vorbereitet, d. h. er hatte zwar .Net 1, 2 und 3.5 bereits aber noch kein .Net Framework 4. Powershell 2 war bereits installiert.

Ausgangslage
Der Aufruf von

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString(‚https://chocolatey.org/install.ps1&#8216;))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

für die Installation, führte zu folgender Fehlermeldung:

Exception calling "DownloadString" with "1" argument(s): "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."
At line:1 char:47
+ iex ((new-object net.webclient).DownloadString <<<< (‚https://chocolatey.org/
install.ps1′))
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

Der entscheidende Punkt ist oben rot markiert. Aber was macht man jetzt? Die Meldung ist leider doch zu allgemein.

Erster Versuch mehr Infos zum Fehler zu bekommen
Powershell kennt das $error Objekt. In diesem ist immer der letzte Fehler enthalten. Aber gleichzeitig sind bestimmte Randbedingungen und tiefergehende Infos zum Fehler abrufbar. Wichtig: Wenn man beim Rumspielen einen neuen Fehler verursacht, dann gehts schnell durcheinander und man untersucht nicht den eigentlichen Fehler, sondern einen nachfolgenden! Also geht man zuerst her und sichert den Fehler:

$myE = $error[0]

Damit kann nun nichts schiefgehen und mittels verschiedenen Abfragen kommt man dann irgendwann dazu:

((($myE).Exception).InnerException).Innerexception
The remote certificate is invalid according to the validation procedure.

Aha, wir haben also ein Zertifikatsproblem.

Prüfung mittels Browser
Aber welches Zertifikat macht nun die Probleme? Wie kann man dies überprüfen? Ein einfacher Versuch ist mittels Browser, in diesem gibt man einfach im aktuellen Fall https://chocolatey.org ein und schaut was passiert. Wer jetzt Chrome benutzt, der ist fein raus und bleibt verdutzt zurück, wer es aber mit dem Internet Explorer probiert, welcher den gleichen Weg einschlägt wie eben Powershell, bekommt diese Meldung:

Es besteht ein Problem mit dem Sicherheitszertifikat der Website.

Das Sicherheitszertifikat dieser Website wurde für eine andere Adresse der Website ausgestellt.

Die Sicherheitszertifikatprobleme deuten eventuell auf den Versuch hin, Sie auszutricksen bzw. Daten die Sie an den Server gesendet haben abzufangen.

Es wird empfohlen, dass Sie die Webseite schließen und nicht zu dieser Website wechseln.

Klicken Sie hier, um diese Webseite zu schließen.

Laden dieser Website fortsetzen (nicht empfohlen).

Weitere Informationen

Ja das kennen wir schon. Wenn man aber “Laden dieser Website fortsetzen (nicht empfohlen)” anklickt, bekommt man den bekannten roten Balken des IE mit dem Zertifikatsfehler. Dort kann man nun auf Zertifikatsfehler klicken und sich die Sache etwas genauer anschauen. Blöd nur das, dass es nicht offensichtlich ist, wo das Problem wieder genau liegt. Auf jeden Fall bekommt man raus, dass es sich in diesem Fall um Geotrust-Zertfikate handelt. Übrigens bekommt man diese Info auch von Chrome geliefert, wenn man auf das Schloss in der Adresszeile klickt und das Register Verbindung auswählt. Aber Hallo! Hier wird ein Go Daddy Zertifikat für chocolatey.org genannt! Ja was denn nun? GeoTrust oder Go Daddy? Des Rätsel Lösung nennt sich SNI und wird am Ende aufgelöst.

Tiefergehende Suche mittels Powershell
Wie kann man die Geschichte aber mittels Powershell besser in Griff bekommen? Da zu unterst immer irgendwo eine TCP-Verbindung aufgebaut werden muss, kann nur der direkte Aufruf über TCPClient etwas bringen.

Die einfachste Variante wäre nun:

$host = "chocolatey.org"
$port = 443
$conn = New-Object System.Net.Sockets.TcpClient ($host, $port)
$stream = New-Object System.Net.Security.SslStream($conn.GetStream())
$result=$stream.AuthenticateAsClient($host)
$conn.Close()

aber hier kommt nur wieder die Fehlermeldung wie oben bei der doppelten InnerException. Also was tun?

Der Konstruktor von SslStream kennt noch weitere Parameter. Unter anderem den RemoteCertificateValidationCallback Delegaten. http://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback(v=vs.110).aspx. Dieser wird üblicherweise benutzt, um bestimmte Fehlermeldungen in Verbindung mit Zertifikaten zu unterdrücken. Ab Powershell 2.0 ist dies ohne weiteres möglich, wie dieser Artikel hier schön beschreibt: http://www.nivot.org/blog/post/2009/07/18/PowerShell20RCWorking
WithNETCallbacksPart1Synchronous
. Der Callback kennt aber alle relevanten Informationen, so dass man diesen nun so nutzen kann:

$conn = New-Object System.Net.Sockets.TcpClient($host,$port)
$stream = New-Object System.Net.Security.SslStream($conn.GetStream(), $null, {
                    Write-Host "Sender: $($args[0])";
                    Write-Host "Certificate: $(($args[1]).gettype())";
                    Write-Host "CertificateChain: $($args[2])";
                    Write-Host "PolicyErrors: $($args[3])"; 
         })
$result = $stream.AuthenticateAsClient($host)
$conn.Close()

nun bekommt man als Ergebnis dies geliefert:

Sender: System.Net.Security.SslStream
Certificate: System.Security.Cryptography.X509Certificates.X509Certificate2
CertificateChain: System.Security.Cryptography.X509Certificates.X509Chain
PolicyErrors: RemoteCertificateNameMismatch

Also genau was auf MSDN als Parameter dokumentiert steht. Vor allem interessant ist nun die Aussage mit RemoteCertificateNameMismatch. Jetzt wird die Sache schon etwas klarer. Sollte chocolatey.org nicht im Zertifikat genannt sein?

Hier nun das Script welches die richtigen Infos ausgibt:

$conn = New-Object system.net.sockets.tcpclient($host, $port)
$stream = New-Object system.net.security.sslstream($conn.getstream(), $null, {
                    Write-Host $args[2].ChainElements[0].Certificate.Subject;
                    Write-Host "PolicyErrors: $($args[3])";
         })
$result = $stream.authenticateasclient("chocolatey.org")
$conn.Close()

Als Ausgabe erhält man:

CN=*.apphb.com, O=AppHarbor Inc, L=San Francisco, S=California, C=US, SERIALNUMBER=MyGg//QgdanmdPPqqfNR5JjsvbrKA/uJ
PolicyErrors: RemoteCertificateNameMismatch

Aha, nun wird es klarer. Wir wollen auf die Seite chocolatey.org bekommen aber ein Zertifikat vom Server für AppHarbor. Findet hier eine Attacke statt? Oh Gott, alle Schotten dicht!

Zusammenfassung
Ich wollte nur mal schnell Chocolatey installieren und bin dann wegen den Sicherheitsanforderungen von Chocolatey bei einer Attacke gelandet, wo mir irgendjemand falsche Zertifikate unterjubeln möchte. Oder ist doch alles ganz anders?

Aufklärung
Die Lösung des Dilemmas lautet SNI “Server Name Indication”. Ein schöner Artikel dazu findet man auf der deutschen Wikipedia unter http://de.wikipedia.org/wiki/Server_Name_Indication. Dort wird im Zusammenhang von SNI darauf hingewiesen, dass Windows XP kein Server Name Indication unterstützt. Warum ist dies wichtig? Weil Powershell mittels der Systembibliotheken von Windows XP seine HTTPS Verbindung aufbauen möchte und ebenso wie der IE8 Probleme bekommt. Hintergrund dafür ist, dass chocolatey.org bei HTTPS-Verbindungen auf SNI angewiesen ist, wie dieser Test zeigt: https://www.ssllabs.com/ssltest/analyze.html?d=chocolatey.org.

Dort ist dann zu lesen:

This site works only in browsers with SNI support.

Dies erklärt nun auch die unterschiedlichen Zertifikate. Denn IE8 auf Windows XP kann kein SNI, Chrome jedoch kann es, obwohl Windows XP zum Einsatz kommt. Der Grund dafür ist, dass Chrome seine eigene Crypto-Library mitbringt.

Beim Versuch also die Verbindung ohne SNI aufzubauen, landet man nicht auf dem gewünschten Server sondern bekommt ein allgemeineres Zertifikat des Hosters zurück. Dies erklärt nun den Punkt mit den unterschiedlichen Zertifikaten von GeoTrust und Go Daddy.

Man kann die Sache sehr schön nachverfolgen, wenn man Fiddler einsetzt. http://fiddler2.com/. Damit kann man, wenn der HTTPS-Mitschnitt aktiviert ist, sehr schön sehen, dass Powershell 2.0 diesen Aufruf generiert:

Version: 3.1 (TLS/1.0)

Extensions:
renegotiation_info 00
Ciphers:
[0004] SSL_RSA_WITH_RC4_128_MD5
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[0009] SSL_RSA_WITH_DES_SHA
[0064] TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
[0062] TLS_RSA_EXPORT1024_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[0006] SSL_RSA_EXPORT_WITH_RC2_40_MD5
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0012] SSL_DHE_DSS_WITH_DES_SHA
[0063] TLS_DHE_DSS_EXPORT1024_WITH_DES_SHA

Compression:
[00] NO_COMPRESSION

Während Chrome dies zustande bringt:

Version: 3.1 (TLS/1.0)

Extensions:
 server_name chocolatey.org
renegotiation_info 00
elliptic_curves secp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19]
ec_point_formats uncompressed [0x0]
SessionTicket TLS empty
NextProtocolNegotiation empty
ALPN  spdy/2; spdy/3; spdy/3.1; http/1.1;
channel_id empty
status_request 01 00 00 00 00
Ciphers:
[C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[009E] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[0039] TLS_DHE_RSA_WITH_AES_256_SHA
[0035] TLS_RSA_AES_256_SHA
[C011] TLS_ECDHE_RSA_WITH_RC4_128_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
[002F] TLS_RSA_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA

Compression:
[00] NO_COMPRESSION

Der Extensions-Eintrag server_name chocolatey.org ist genau der Punkt, welcher beim Powershell-Aufruf fehlt und die Sache zum Scheitern bringt. Gleichwohl auch Chrome innerhalb von Fiddler Probleme mit dem Aufruf bekommt, denn Fiddler2 basiert auf .Net Framework 2.0 und damit ist der weitere Fortgang zum Scheitern verurteilt und man bekommt am Ende nicht das Go Daddy Zertifikat sondern wieder das falsche GeoTrust Zertifikat.

Übrigens geht genau dieser Artikel auf das aktuelle Problem ein und bestätigt nochmal alles: https://groups.google.com/forum/#!searchin/chocolatey/geotrust$20/chocolatey/r9EdhJdPjWM/FavaGm07VtoJ

Zu guter Letzt noch die Bestätigung, dass Powershell 4.0 unter Windows 8.1 problemlos damit umgehen kann:

A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.1 (TLS/1.0)

Extensions:
renegotiation_info 00
 server_name chocolatey.org
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
SessionTicket TLS empty
Ciphers:
[002F] TLS_RSA_AES_128_SHA
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5

Compression:
[00] NO_COMPRESSION

Also alles halb so wild, wenn man weiß, wie es zusammenhängt!

Abgelaufene Zertifikate am Small Business Server 2011 erneuern

24 April 2013

Wenn man am SBS2011 Probleme mit Zertifikaten bekommt, in der Regel nach ein oder zwei Jahren spätestens nach fünf Jahren, dann hilft ein Assistent bei der Erneuerung der Zertifikate.

Zur Lösung ruft man die Windows Small Business Server 2011 Standard Konsole auf. Dann klickt man oben auf Netzwerk, auf das Register Konnektivität, nun findet man rechts die Konnektivitätstasks. Hier findet man den Punkt “Beheben von Netzwerkproblemen” oder “fix my network”. Ruft man diesen Punkt auf, startet ein Assistent der Probleme im Netzwerk ausfindig macht. Am Ende konzentriert man sich in der Regel nur auf das abgelaufene Zertifikat und lässt dieses automatisch reparieren.

Hat der Assistent erfolgreich das Zertifikat erneuert, findet sich auch unter Verwaltung->Zertifizierungsstelle unter “Ausgestellte Zertifikate” ein neuer Eintrag mit einer neuen Anforderungs-ID sowie das neu ausgestellte Zertifikat.