Immer mal wieder begegnet mir die Aussage, dass z.B. das RSS Anzeige Webpart sich „komisch“ verhält. Interne Feeds werden z.B. nicht angezeigt, obwohl Kerberos konfiguriert und aktiv ist. Externe Feeds funktionieren aber einwandfrei. Oder dass der FIM Sync der User Bilder aus dem User Profile Service ins Active Directory nicht funktioniert und keine Daten zurückgeschrieben werden, obwohl im Active Directory alle Berechtigungen gesetzt sind und die Property zum Export markiert ist.

Wenn Ihnen diese Probleme bekannt vorkommen und sie Ihren SharePoint 2010 mit einem SSL Zertifikat abgesichert haben, dann sollten Sie mal einen Blick in das Event Log werfen. Wenn dort viele Error-Events mit der ID „8311“ von der Quelle „SharePoint Foundation“ gelogt werden, dann sind Sie einem besonders fiesen Zertifikats Problem zum Opfer gefallen.

Der Eintrag im Event Log könnte z.B. so aussehen:

Event ID 8311 im Event Log

Der entscheidende Satz findet sich am Ende der Fehlermeldung: „The root of the certificate chain is not a trusted root authority“.

Wie kann dieses sein, wo doch die in der Domäne registrierten Clients das Zertifikat im Windows Certificate Store vorfinden und so z.B. im Internet Explorer nichts bemängeln. Auch der IIS hat an dem Zertifikat nichts zu beanstanden.

Der Fehler entsteht dadurch, das SharePoint seinen eigenen Certificate Store besitzt und den Windows Certificate Store schlicht ignoriert. Greift nun z.B. der RSS Viewer auf einen Feed zu, so zieht der den Certificate Store vom SharePoint an und da findet sich kein Hinweis auf die Vertrauenswürdigkeit der Root Zertifikates, in diesem Fall ausgestellt von Equifax. Das Gleiche gilt für die Bilder. Da der Profile Sync nicht die URL sondern die Bilder aus der versteckten Bildergalerie im MySite Host direkt ins AD hochlädt, greift auch dieser auf die verschlüsselte Verbindung zu und bemängelt das nicht vertrauenswürdige Zertifikat.

Abhilfe naht in Form einiger PowerShell Befehle, mit Hilfe derer man ein Zertifikat zum SharePoint Certificate Store hinzufügen kann. Dazu muss man erstmal an das Root Zertifikat kommen. Am einfachsten geht dieses über den IIS-Manager, wenn das Zertifikat als „exportierbar“ markiert wurde. Sollte das nicht gehen, besorgen Sie sich das Zertifikat aus der Zertifikatsstelle neu und importieren Sie es in den Windows Certificate Store, markieren es aber beim Importvorgang als „exportierbar“.

Zunächst öffnet man den IIS-Manager und geht in die Verwaltung der „Server Certificates“.

Wählen Sie die "Server Certificates" aus

Dort wählt man das SSL-Zertifikat aus und klickt nach einem Rechtsklick auf „Properties“. Im Reiter „Certification Path“ kann man die Zertifikatskette einsehen und markiert das oberste Zertifikat im Pfad. Danach klickt man auf „View Certificate“ um die Eigenschaften dieses Zertifikats einzusehen.

Das Root Zertifikat ansehen

Im Reiter „Details“ kann man die Eigenschaften des Zertifikats ansehen und das Zertifikat exportieren. Man klickt auf „Copy to File…“, belässt alle Einstellungen wie sie sind und gibt dem Zertifikat einen Namen, z.B. „root.cer“

Das Root Zertifikat exportieren

Danach öffnet man die SharePoint PowerShell Konsole oder gibt in der normalen PowerShell Konsole „Add-PSSnapin Microsoft.SharePoint.PowerShell“ ein und kann mit dem kleinen PS Script das Wurzel Zertifikat in den SharePoint Certificate Store importieren.

Eingabe der PowerShell Skripte

Hier nochmal das Script zum heraus kopieren:

$rootca = New-Object System.Security.Cryptography.x509Certificates.x509Certificate2(“<pfad zur root ca>:\<Dateiname der Zertifikatsdatei>”)

New-SPTrustedRootAuthority –Name “Equifax Root CA” –Certificate $rootca

Nach einem IISReset verschwinden die Fehler aus dem Event Log. Auch das RSS Anzeige Webpart und der FIM Sync funktionieren nun wieder wie gewohnt. Warum allerdings der SharePoint nicht einfach mal im Windows Certificate Store nachsieht ist mir ein Rätsel…