In einem Fall konnte von einem Server nicht auf die SSL geschützte Webseite eines anderen Servers zugegriffen werden. Die Standardfehler wie unvertrautem Zertifikat, fehlerhafte IE Einstellungen konnten ausgeschlossen werden. Daher blieb nur der beherzte Griff zum Netzwerkmonitor und Google.

Mit Unterstützung dieses Artikels (

http://blogs.msdn.com/b/sudeepg/archive/2009/02/16/debugging-ssl-handshake-failure-using-network-monitor-a-scenario.aspx) konnte der eigentliche SSL Fehler aus dem Mitschnitt ermittelt werden:

Der letzte Hex Wert (blau hinterlegt, 28 = Dez 40) ist der Fehlercode:

Fedora bases upon Red Hat Enterprise linux which is supported by SCOM. Fedora Core 3 was the base of  RHEL 4 and Fedora Core 6 RHEL 5. In this blog posts I will try to convince SCOM that the Fedora 4 based Asterisk telecom system is a RHEL 4.

First we have to install the RHEL4 scom agent manual onto the systems. In this case we had to install the OpenSSL library, too. Additional we add the scom user account to the system.

After that we sign the local created certificate by the scom server and replace it on the Fedora system.

Now we can test the connection from the SCOM server with this winrm command:

winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx -username:scomuser -password:yourpassword -r:https://your.fedora.system:1270/wsman -auth:basic -encoding:UTF-8

The output shows detail information about the OS:

Das von Agentsetup automatisch erstellte Zertifikat auf einem Linux Client kann u.U. auf den falschen Hostnamen ausgestellt sein. Um das SCOM Zertifikat zu überprüfen kann folgende Kommandozeile auf dem Linux/Unix System ausgeführt werden:

openssl x509 -in /etc/opt/microsoft/scx/ssl/scx-host-.pem -noout –text

So sieht dann die Ausgabe aus:

Certificate:

    Data:

        Version: 1 (0x0)

Online Passwort Speicher gibt es wie Sand am Meer (vielleicht etwas weniger). Ich persönlich finde momentan https://www.clipperz.com sehr gut. Übertragung ist wie bei den meisten per SSL gesichert. Aber die kompletten Benutzernamen und Passwörter werden mittels des Loginkennwortes lokal mit Javascript verschlüsselt. Dadurch kennt der Server nie die eigentlichen Daten. Auch für die Anmeldung ist die Angabe der Email Adresse nicht erforderlich (oder möglich).
Und da alles per JavaScript Clientseitig abläuft (ausser die Speicherung der Verschlüsselten Daten auf dem Server) kann man sich auch eine Offline Version erstellen lassen (bei der die Daten nicht auf dem Server sondern direkt und verschlüsselt in die Offline HTML Datei eingebetet werden), so dass man an seine Passwörter auch ohne Internetzugang aber trotzdem gesichert drankommt.
Das automatische Login ist bei Clipperz ebenfalls möglich. Dafür muss man im Gegensatz zu anderen Diensten nicht ein Bookmarklet für die Anmeldung verwenden, sondern verwendet das Bookmarklet im Vorfeld um das Logonform auszulesen und als kleine Beschreibungsdatei in Clipperz einzufügen. Daraus erstellt das System direkt die benötigten Felder und kann dann clientseitig das Login simulieren.

Um schnell ein Zertifikat eines ADDS Servers zu überprüfen, bietet sich überraschender Weise ein Webbrowser wie der Firefox auf. Trägt man dort in der Adressleiste https://dns-name-des-domänencontrollers:636 ein. Beim Aufruf erscheint unten links das bekannte SSL-Schloss, dass man zur genaueren Inspektion nutzen kann.

Aber: Neuere Firefoxversionen verhindern https Verbindungen auf ungewöhnlichen Ports. Daher muss hier eine Ausnahme für ldaps eingetragen werden:
Um in die erweiterten Einstellungen des Firefoxes zu gelangen muss man in die Adressleiste about:config eingeben. Dort als zusätzlichen Eintrag network.security.ports.banned.override hinzufügen und als Wert den Port 636 hinterlegen (weitere Ports kann man durch Komma getrennt eingeben):