Archive for the ‘PKI’ Category

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/.

Werbeanzeigen

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‘))" && 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.

Zertifikate manuell über Gruppenrichtlinien verteilen

23 April 2013

In der heutigen Zeit kommt man nicht mehr ohne Zertifikate aus. Um die Verteilung von speziellen Zertifikaten zentral steuern zu können, macht es Sinn, diese über Gruppenrichtlinien zu verteilen.

Eine schöne bebilderte Beschreibung findet man unter http://unixwiz.net/techtips/deploy-webcert-gp.html.

Hier eine Beschreibung für Windows Server 2008 R2: http://technet.microsoft.com/en-us/library/cc772491.aspx

Bei Verwendung des Remote Desktop unter Windows erscheint ständig eine Zertifikatswarnmeldung obwohl man bereits das Zertifikat installiert hat

26 August 2012

Wenn man mit den Standardeinstellungen eine Verbindung zum Remotedesktop eines anderen Windows-Rechners aufbaut der nicht in derselben Domäne sitzt, wird man mit Warnhinweisen traktiert. An sich ist die Sache ja gut, nur leider führt die Art wie die Dialoge reagieren zu dem Ergebnis, dass die Anwender genervt sind und im Zweifel ihre Sicherheitseinstellungen reduzieren um zum Ziel zu kommen.

Hier sind die Masken (noch Win7) schön dargestellt und die Situation gut beschrieben: http://serverfault.com/questions/7653/remote-desktop-keeps-asking-me-to-accept-a-certificate

Blöd an der Sache ist, dass selbst wenn man sagt, man möchte das Zertifikat installiert bekommen, dass es dann beim nächsten Aufruf wieder nicht klappt. Das verwirrt und sorgt für die Konditionierung, dass einfach immer alles weggeklickt wird, Hauptsache es funktioniert irgendwie. Aber das kann es nicht sein!

Was passiert hier effektiv? Wenn man die Installation des Zertifikats dem System überlässt, wird das Zertifikat beim aktuellen Benutzer abgespeichert und zwar unter den Zwischenzertifizierungsstellen. Damit das Zertifikat seiner Bedeutung gerecht werden kann, muss es aber im Computerkonto unter Vertrauenswürdige Stammzertifizierungsstellen enthalten sein. Warum das so ist? Keine Ahnung, aber ich spekuliere mal darauf, dass auch bestimmte Dienste (Netzwerk) zur Absicherung der Verbindung benutzt werden und diesen das Zertifikat vom Benutzer nicht zur Verfügung steht.

Lösung unter Windows 8 und Server 2012
Windows 8 und Windows Server 2012 bringen eine Verbesserung der Situation. War seither beim Importassistent immer nur die Installation des Zertifikats beim aktuellen Benutzer möglich, erscheint nun nach Auswahl von “Zertifikat installieren” zuallererst die Rückfrage nach dem Speichertort, wo man zwischen “Aktueller Benutzer” und “Lokaler Computer” wählen kann. Leider ist aber der Rest des Assistenten genauso unübersichtlich wie früher. D. h. am Ende des Importvorgangs ist nicht klar wo das Zertifikat gelandet ist!

Denn das dumme daran ist, dass das Zertifikat nicht im Speicher der Vertrauenswürdigen Stammzertifizierungsstellen gespeichert wird, auch wenn man den lokalen Computer zuerst ausgewählt hat. Wie vor Windows 8 wird es, bei Verwendung der Vorgabe den Zertifikatsspeicher automatisch zu wählen, im Speicher der Zwischenzertifizierungsstellen gespeichert! Ob Bug oder Feature kommt noch hinzu, dass das Zertifikat nicht nur beim lokalen Computer landet sondern auch noch beim aktuellen Benutzer. Beim Testen wurde bereits Windows 8 RTM verwendet!

Das Zertifikat wird also nur sauber gespeichert wenn man “Lokalen Computer”, “Alle Zertifikate in folgendem Speicher speichern” und als Speicherort “Vertrauenswürdige Stammzertifizierungsstellen” auswählt.

Lösung für Windows 7, Server 2008 R2 und davor
Man kann nun mittels MMC und dem Zertifikats-Snapin einmal das Computerkonto und den Zertifikatsspeicher des aktuellen Benutzer öffnen und dann das betreffende Zertifikat vom einen Speicher in den anderen verschieben. Lästig aber ist so.

Zertifikate mit Subject Alternative Names anstatt Common Name im Subject ausstellen

26 April 2010

Wie es funktioniert erklärt der Technetbeitrag “How to Request a Certificate With a Custom Subject Alternative Name”:  http://technet.microsoft.com/en-us/library/ff625722(WS.10).aspx.

Zur Kompatibilität für SANs findet man hier was: http://www.digicert.com/subject-alternative-name-compatibility.htm