Archive for the ‘Zertifikate’ Category

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.

Werbeanzeigen

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.

Zertifikatsspeicherbezeichnungen in Deutsch, Englisch und Powershell Bezeichnung gegenübergestellt

21 Mai 2011

Da die englische Bezeichnung zu den Zertifikatsspeicherstellen nicht immer so einfach ableitbar ist, bzw. die internen Zertifikatsspeichernamen, die in Powershell verwendet werden, nicht immer einfach zuordenbar sind, hier eine kleine Tabelle die hilft:

Deutsch Englisch Powershell
Eigene Zertifikate Personal My
Vertrauenswürdige Stammzertifizierungsstellen Trusted Root Certification Authorities Root
Organisationsvertrauen EnterpriseTrust Trust
Zwischenzertifizierungsstellen Intermediate Certification Authorities CA
Active Directory-Benutzerobjekt Active Directory User Object UserDS
Vertrauenswürdige Herausgeber Trusted Publisher TrustedPublisher
Nicht vertrauenswürdige Zertifikate Untrusted Certificates Disallowed
Drittanbieter-Stammzertifizierungsstellen Third-Party Root Certification Authorities AuthRoot
Vertrauenswürdige Personen Trusted People TrustedPeople
Andere Personen Other People ADDRESSBOOK
Zertifikatregistrierungsanforderungen Certificate Enrollment Request REQUEST
Smartcard vertrauenswürdige Stämme Smart Card Trusted Roots SmartCardRoot
  Automatic Certificate Request Settings ACRS
Remote Desktop Remote Desktop Remote Desktop
Vertrauenswürdige Geräte Trusted Devices TrustedDevices
Windows Live ID Token Issuer Windows Live ID Token Issuer Windows Live ID Token Issuer

Einige Speicher gibt es nur beim “Lokalen Computer”.

MSDN beschreibt auch die Stellen in der Registrierung wo die Zertifikate zu finden sind: http://msdn.microsoft.com/en-us/library/aa388136(v=vs.85).aspx#remarks. Wichtig dabei ist, dass immer der Fingerprint des Zertifikats als Registrierungsschlüssel unterhalb des Schlüssels Certificates eingetragen wird.

Beispiel:

HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\Root\
Certificates\<Fingerprint>

wird angelegt, wenn man ein Zertifikat unter Vertrauenswürdige Stammzertifizerungsstellen beim aktuellen Benutzer abspeichert. Interessant: Es sind darunter nicht alle Zertifikate zu finden, sondern die vom System vorgegebenen sind mit ProtectedRoots verlinkt!

Wenn man einen Rechner upgraded oder die Daten auf einen anderen Rechner mittels USMT (wahrscheinlich auch Easy Windows Transfer) umzieht, werden nur die Standard-Zertifikatsspeicher mit übernommen: http://msdn.microsoft.com/en-us/library/bb204781(v=VS.85).aspx

Sollte man mal im Auge behalten, Zertifikate werden im falschen Speicher installiert: http://social.msdn.microsoft.com/Forums/en/windowssecurity/thread/
adf8008f-0503-4b76-9a41-5785825777c7

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