Office 365 Trusted Zertifikate

In den meisten Fällen machen sich Administratoren wenig Gedanken über erforderliche Zertifikate. Solange der Zugriff auf die Cloud erfolgt, muss Microsoft den SSL-Tunnel terminieren und das Zertifikat liefern. Und da achtet schon Office 365 darauf, dass alles korrekt ist. Diese Seite beschreibt aber die "Gegenrichtung", wenn Office 365 Dienste auf Services ihrer On-Prem-Umgebung zugreifen und dabei SSL erforderlich wird. Dann benötigen Sie ein Zertifikat, welches von den Office 365 Diensten als "vertrauenswürdig" eingestuft wird. Damit scheidet ihre "eigene PKI" aus und selbst die öffentlichen Zertifikate sind nicht immer alle gleich gut.

Dienste mit Office 365 Callback

Für einige Dienste ist ihnen sicher bekannt, dass Office 365 auch einen Zugriff auf ihre On-Prem-Umgebung braucht. Es gibt aber auch Dienste, da fällt es nicht sofort auf.

  • Exchange Hybrid mit SMTP
    Die direkte Verbindung des Office 365 Tenant mit ihrer On-Premises-Umgebung wird per M-TLS abgesichert, d.h. Office 365 sendet ihnen Mails an On-Prem-Benutzer per SMTP und erwartet dazu ihr Zertifikat. Wenn Exchange Online diesem Zertifikat nicht vertraut, bekommen Sie keine Mails von ihrem Office 365 Tenant an lokale Anwender. Mails von anderen Tenants sind hingegen durchaus möglich.
  • Exchange Hybrid EWS
    Für den Hybrid Mode ist EWS eine essentielle Komponenten, damit die Office 365 Benutzer auch die Frei/Belegt-Zeiten der On-Prem Postfächer einsehen können. Zudem ist EWS bei Hybrid der Zugang von Office 365 um Postfächer in die Cloud über die Replikation zu migrieren.
  • Skype for Business Edge
    Wenn Sie die Seite SIP-Wege gelesen haben, dann erkennen Sie, dass für die Federation mit Office 365 aber erst recht auch beim Hybrid-betrieb die Office 365 Edge Server dem Zertifikat auf ihrem Edge-Server vertrauen müssen.
  • SharePoint Hybrid
    Auch mit SharePoint gibt es durchaus einen Hybrid-Mode. So kann ein Anwender in Sharepoint Online "suchen" und die Ergebnisliste enthält auch Dokumente der "On-Prem-Umgebung. Dazu fragt der SharePoint Suchdienste über HTTPS eine On-Prem-Umgebung ab.
  • ADFS
    Vielen Administratoren ist nicht bekannt, dass ADFS durchaus auch von Office 365 angefragt wird. Normalerweise ist es ja so, dass ein Client vom angesprochenen Dienst auf den ADFS-Server verwiesen wird, damit dieser ein Ticket ausstellt und der Client dann zum Service zurück geht. Es gibt aber Clients wie z:B. Outlook, die dieses Verfahren noch nicht unterstützen. Dann erwartet Office 365 vom Anwender dass er sein Kennwort noch einmal eingibt und an die Cloud sendet. Office 365 geht dann im Auftrag des Anwender an den ADFS-Server um ein Ticket für die nachgelagerten Dienste zu erhalten. Dies ist bei Exchange z.B. der Fall

Bislang hatte ich mit diesen vier Diensten entsprechende "Erfahrungen" mit falschen Zertifikaten auf der On-Prem-Seite gemacht. Schauen wir uns die Dienste etwas genauer an:

Das "richtige" Zertifikat"

Die meisten Zertifikate sind dahingehend "richtig", dass Sie die folgenden Punkte erfüllen.

  • Name im Zertifikat (CN und SAN)
    Die Office 365-Dienste greifen immer über einen öffentlichen FQDN auf die Dienste zu, den sie im DNS auch eingetragen habe. Interne Namen oder IP-Adressen funktionieren schon daher nicht, weil sie keine öffentliche PKI finden, die solche Zertifikatsanforderungen signiert.
  • Zeitraum
    Zertifikate haben ein Start und ein Ende-Datum. Diese Anforderung ist auch kein Problem, da eine PKI immer ab heute bis zum Laufzeitende signiert. Legen Sie sich aber eine Erinnerung an, wenn das Zertifikat abläuft.
  • CRL erreichbar
    Office 365 prüft, ob das Zertifikat vielleicht nicht doch zurückgezogen wurde. Auch das ist kein Problem mit öffentlichen PKIs, die die CRL veröffentlichen
  • Usage
    Office 365 nutzt keine "besonderen" Usages. Quai jedes "WebServer Zertifikat" ist ausreichend
  • SHA256 Key (Statt SHA-1)
    Auch die Abkehr von schwachen SHA1-Signierungen haben die öffentlichen PKIs schon im Jahre 2014/2015 begonnen. Sie bekommen von hier gar keine SHA1-Zertifikate mehr, die Office 365 vielleicht nicht mehr als vertrauenswürdig einstufen könne.
  • Zwischenzertifikate in der Chain
    Hier müssen Sie noch mal ein Auge drauf haben, dass die Zwischenzertifizierungsstellen ihres Zertifikats auch im richtigen Zertifikatsspeicher ihres Computers liegen., so dass der IIS die Kette mit zum Client, in dem Fall ja ein Office 365 Server, ausliefern kann

Aber ein Punkt in dieser Liste fehlt noch und das ist der maßgeblich für die Akzeptanz durch Office 365:

  • RootCA
    Schlussendlich muss die Zertifikatskette aber bis zu einer Stammzertifizierungskette zurück gehen, die von Office 365 als "vertrauenswürdig" gelistet ist.

Office 365 und Stammzertifizierungsstellen

Auf der Suche nach einer Liste der von Office 365 vertrauenswürdig eingestuften Stammzertifizierungsstellen habe ich feststellen müssen, dass es keine einheitliche Liste (Stand Dez 2016) dazu gibt. Ich habe aber sehr wohl gemerkt, dass nicht jede StammCA auch wirklich "geeignet" ist.

Am besten lassen Sie sie sich von ihrer PKI bestätigen, dass Sie auf einer StammCA aufbaue, die von Office 365 als "Trusted" geführt wird

Beachten Sie dazu auch die Seite CA-Auswahl

Kein "Automatic Root Certificates Update" in Office 365
Anscheinend nutzt Office 365 nicht die eingebaute Funktion, eventuell fehlende Stammzertifikatsstellen dynamisch zu installieren.

Insofern ist die Liste der "Microsoft Trusted Root Certificate" -Mitglieder auch keine gute Hilfe:

Aktuell kann ich nur dazu raten bei Diensten, die von Office 365 auch eingehende erreicht werden müssen (Exchange EWS, SfB Edge, ADFS) sich auf eine der folgenden RootCAs zu beschränken:

Diese Zertifikate sind auf einem Windows 2012R2 Server "per Default" installiert und ich gehe erst mal darin aus, dass diese StammCAs auch auf den Office 365 Servern als vertrauenswürdig installiert sind.

Exchange Hybrid

Microsoft veröffentlicht für Exchange Federation Trusts zumindest eine Liste der Stammzertifizierungsstellen, denen die Exchange Frontend Server vertrauen.

Zertifikate von anderen Stammzertifizierungsstellungen dürfte demnach nicht gehen. Ich habe grade keinen Trace einer solche Konfiguration vorliegen und kann daher nicht sagen, wie dieses Problem erkannt werden kann. Ich könnte mir aber vorstellen, dass eine EWS-Anfrage an die Frei/Belegt-Zeiten vielleicht im ErrorCode einen Hinweis darauf gibt.

Skype for Business Edge

Auf der Seite SIP-Wege habe ich beschrieben, welche Wege ein SIP-Paket geht. Sowohl bei der Federation einer Skype for Business Online Only Firma  zu einer anderen Firma, die On-Premises arbeitet als auch für die Hybrid-Funktion innerhalb einer Firma ist das "richtige" Zertifikat erforderlich.

Das ein Office 365 User im Hybrid-Mode über den On-Prem Edge geht, ist auch gut daran zu sehen, dass ein "falsches" Zertifikat auf dem lokalen Edge zu Zustellproblemen führt. Hier ein UCCAPI-Trace auf dem Client eines Skype for Business Online Anwenders, der zu einem anderen föderierten Benutzer etwas senden will (Daten gekürzt)

IP/2.0 504 Server time-out
ms-User-logon-data: RemoteUser
Authentication-Info: TLS-DSK qop="auth", opaque="xx", srand="xx", snum="xx", rspauth="xxx", targetname="AM30E08FES03.infra.lync.com", realm="SIP Communications Service", version=4
Via: SIP/2.0/TLS 10.1.29.18:49855;received=10.21.15.254;ms-received-port=44015;ms-received-cid=8A4FF00
Content-Length: 0
From: "O365User"<sip:o365User@uclabor.de>;tag=xx;epid=xx
To: "TestUser1"<sip:testUser1@msxfaq.de>;tag=xx;epid=xx
Call-ID: xxx
CSeq: 4 MESSAGE
ms-diagnostics: 1010;reason="Certificate trust with another server could not be established";
   ErrorType="The peer certificate is not chained off a trusted root";
   tls-target="sip.uclabor.de";
   PeerServer="sip.uclabor.de";
   HRESULT="0x800B0109(CERT_E_UNTRUSTEDROOT)";
   source="sipfed0A.online.lync.com"
ms-telemetry-id: 7182D6D0-7443-5BEE-BD8D-66FADFAF3E53
Server: RTC/7.0

Es ist gut zu sehen, dass der Office 365 Edge "sipfed0A.online.lync.com" an den Client meldet, dass das Zertifikat der Gegenstelle nicht "Trusted" ist. Würde der Office 365 Edge aber direkt den DNS-Eintrag "_sipfederationstls._tcp.<sipdomain>" abfragen und zum entsprechenden Edge-Server gehen, dann wäre er nie an das nicht vertrauenswürdige Zertifikat der On-Prem-Umgebung gekommen. Aus Sicht des Edge-Servers war das Zertifikat in Ordnung.

Aus Sicht von Office 365 ist die "T-TeleSec GlobalRoot Class 2"-CA anscheinend noch nicht "Trusted". Leider habe auch ich keine Liste der Stammzertifikate, die auf den Skype for Business Edge Server on Office 365 als "Trusted" anerkannt sind. Hier sollten Sie die PKI darauf festlegen, dass die ausgestellten Zertifikate auch akzeptiert werden.

Microsoft hat in einem Blog-Artikel im Jahr 2013 einmal veröffentlich, welcher StammCA Partner vertrauen müssen, damit eine "lync-Federation" mit Microsoft möglich ist.

Leider hilft dieser Artikel für Office 365 nicht weiter. Ich habe noch keine andere Quelle gefunden, auf der die vertrauenswürdigen Stammzertifizierungsstellen der Office 365 Edge Server beschrieben sind.

SharePoint Hybrid

Ich bin nicht der SharePoint Experte, um hier eine verlässliche Antwort zu liefern. Es gibt bei SharePoint auch einen Hybrid Mode aber meines Wissens nach ist die wesentliche Funktion die, dass eine Suche nach Inhalten beide Welten durchsucht. Dazu soll es einen Service On-Prem geben, der die indexierten Metadaten entweder in die Cloud hoch lädt oder von der Cloud erreichbar macht. Ich kann aktuell nicht sagen, bei welcher Version dies wie im Detail gelöst ist und ob dazu ein Zugriff von Office 365 auf den On-Prem SharePoint erfolgt. Solche Lösungen verändern sich auch gerne mal. Sobald ich neue Erkenntnisse habe, werde ich die hier nachtragen.

ADFS

Ich habe noch keine zuverlässige Quelle für die Stammzertifizierungsstellen gefunden. Aus meiner Sicht dürfte aber hier die Applikation maßgeblich sein. Wenn ein Outlook Client den Exchange Frontend in Office 365 erreicht und dieser dann die Zugangsdaten erhält um damit den ADFS-Server der Firma anzusprechen, dann ist die Liste der vertrauenswürdigen Stammzertifizierungsstellen auf dem Exchange Frontend in der Cloud maßgeblich.

Weitere Dienste

Es gibt durchaus noch andere Dienste, die auf Quellen einer On-Prem-Umgebung zugreifen können. In den meisten Fällen wird Microsoft aber ein Modell von On-Prem zur Cloud favorisieren. So gibt es z.B. für PowerBI entsprechende Gateways, die On-Prem gestartet werden und die Daten in die Cloud senden. Mir sind außer Exchange, Skype for Business und ADFS keine Dienste bislang aufgefallen, für die Zertifikate für On-Prem-Server erforderlich sind.

Weitere Links