Lync Hosting: Edge und Federation

Das erste Problem, auf das ein Hoster immer stoßen wird ist die Festlegung der Zertifikate für den Edge-Server.

Das Problem mit den Zertifikaten

Damit Open Federation Partner auf den Server zugreifen können, muss der Domaininhaber drei DNS-Einträge im Internet eintragen

_sipfederationtls._tcp.<sipdomain.tld>  SRV  0 0 5061  sip.<sipdomain.tld>
                   sip.<sipdomain.tld>  A    <ip-adresse access edge>

Die Verbindung von einem Edge zu anderen erfolgt dann per SIP/TLS verschlüsselt und natürlich überprüfen Edge-Server das Zertifikat. per Default wird die Verbindung nicht aufgebaut, wenn der Name des Zielservers nicht auch im Zertifikat (CN oder SAN) enthalten ist. Die Probleme sind bekannt:

  1. Maximale Einträge im Zertifikat
    Das Feld in einem SAN-Zertifikat ist auf 1024 Bytes beschränkt. "sip.netatwork.de" ist schon 16 Zeichen lang und abhängig von den SIP-Domains passen überschaubar viele Kundendomains in ein Zertifikat
  2. Ausstellungsprozess 1
    Schlimmer ist aber, dass es ein öffentliches Zertifikat sein muss, und die Zertifizierungsstellen zum einen  Beschränkungen in der Anzahl der Namen vorgeben aber zudem jeden Domaininhaber vor der Ausstellung kontaktieren.
  3. Ausstellungsprozess 2
    Zudem erlauben nicht alle Zertifizierungsstelle eine nachträgliche Veränderung sondern behandeln eine Änderung als "Neuausstellung", was hohe Kosten bedeuten kann.

Sie könnte natürlich nun auf den Gedanken kommen, einfach den Namen zu ändern oder einen CNAME zu verwenden, z.B.:

_sipfederationtls._tcp.<sipdomain.tld>  SRV  0 0 5061  sip.<provider.tld>

oder:

_sipfederationtls._tcp.<sipdomain.tld>  SRV  0 0 5061  sip.<sipdomain.tld>
                   sip.<sipdomain.tld>  CNAME  <sip.provider.tld>

Leider funktioniert beides nicht. Microsoft hat in Lync 2013 diesen Trick nicht vorgesehen, sondern erfordert dass die SIP-Domain auch im DNS-Namen des Edge-Servers und damit im Zertifikat erscheint.

Zwischenstand: Explizite Federation

Viele meiner Kunden nutzen sowieso nicht die "Open Federation", sondern tragen noch die Partnerfirmen explizit ein. Das hat auch den Vorteil, dass diverse "Drosslungen" nicht zur Anwendung kommen, die ansonsten eine intensivere Federation behindern könnten. Dies ist natürlich damit auch eine Lösung, wie ein Kunde eine Federation mit einer anderen Lync Instanz erreichen kann auch wenn das Zertifikat keinen Hostnamen mit der SIP-Domain enthält

Lösungsweg Beschreibung

Manuelle Konfiguration der Federation

Sie sollten zuerst prüfen, ob "Open Federation" überhaupt gefordert ist. Sehr viele Firmen wollen sehr genau kontrollieren, mit welchen Partnern die Mitarbeiter kommunizieren können. Sie können über die Lync Einstellungen steuern, welche Domänen erlaubt oder geblockt werden. An der Stelle können Sie auch den Namen des Edge-Servers für diese Verbindung eintragen. Dieser Name kann auch in einer anderen Domäne liegen. So können Sie diese Einschränkung umgehen.

Sie sind aber auf die Mitarbeit des Administrators auf der Gegenseite angewiesen, Er muss ihren Edge-Server addieren, damit die Federation funktionieren kann.

Allerdings kann dies auch mit handfesten Vorteilen gewünscht sein. System, die einfach nur "Open" angebunden werden, unterliegen bestimmten Mengenbeschränkungen für SIP-Messages/Zeiteinheit. Wer also intensiv miteinander kommuniziert, wird schon daher die Domänen explizit eintragen.

Allerdings bedeutet das auch, das ich allen Partnern wieder Bescheid sagen muss, wen sich meine Lync-Plattform ändert.

Provider

Provider betreiben sehr viele und SIP-Domänen, die sowieso nie in ein SAN-Zertifikat passen würden. Office 365 macht es vor, indem Microsoft Online in Lync als "Provider" eingetragen wird. Wenn der Hosting Provider große genug ist, dann werden vielleicht Kunden den Provider als solches definieren.

Meines Wissens gibt es noch kein Programm bei Microsoft, über den sich Provider per Default in eine Lync Installation addieren lassen können.

Zugegeben, als kleiner Provider werden sie vermutlich nicht so schnell in den Genuss kommen, bei allen Lync Installationen der Welt "eingetragen" zu werden. Es ist aber ein möglicher Weg.

Wie macht es Microsoft mit Office 365 und Federation

Vor dem gleichen Problem steht natürlich auch das Office 365 Hosting von Microsoft. Wer allerdings schon einmal in die Lync Konfiguration geschaut hat, wird ein paar Einträge interessant finden: (Stand Mai 2014, Lync 2013) 

Microsoft definiert in Lync per Default einige Einträge, die z.B. einen Edge-Server mit dem Namen "sipfed.online.lync.com" als vertrauenswürdig erscheinen lassen.

Damit ist es natürlich deutlich einfacher, auf Office 365 weitere Kunden mit eigenen SIP-Domains aufzunehmen.

Federation mit Skype - Problemlos

Die Federierung mit Skype ist hingegen von dieser Einschränkung nicht betroffen, denn hier tragen Sie beim Beantragen die SIP-Adresse des Edge-Servers ein. Wenn Sie auf https://pic.lync.com gehen und die Federation beantragen, dann kommt im Laufe des Prozess die Eingabemaste für Edge-Server und SIP-Domains.

Für Skype reicht also einfach nur ein gültiger Edge-FQDN, der per DNS auflösbar ist.

Was machen andere ?

An der technischen Problematik lässt sich leider nichts ändern, dass der FQDN des Edge-Servers für eine Domain aktuell aus der SIP-Domain stammen muss. Daher gibt es für angehende Hoster nur folgende Optionen:

  • SAN Zertifikat mit freundlicher CA
    Sie suchen sich eine Zertifizierungsstelle, die nicht nur viele Namen im SAN-Zertifikat erlaubt, sondern auch eine nachträgliche Veränderung nicht neu berechnet und die bestehenden SAN-Namen nicht neu verifiziert
  • Weitere Edge-Server
    Wenn das SAN-Zertifikat "voll" ist, dann kommen Sie als Hoster nicht umhin, weitere Edge-Server für eingehende SIP-Verbindungen aufzubauen, um mit dem nächsten Zertifikat zu arbeiten

Sie könnten als Provider die Thematik vielleicht entschärfen, wenn sie ihre Kunden fragen, ob Sie "Open Federation" wirklich benötigen, denn nur dann ist ein einer Hostname für Federation erforderlich. Allerdings vermute ich, dass nur wenige Kunden mit Lync Hosting nur eine kleine TK-Anlage ersetzen wollen, sondern schon mit der gesamten Welt kommunizieren wollen.

Wann kommt ein Hosting Provider Programm ?

Microsoft macht es vor, indem Sie Office 365 schon als Hoster in dem Produkt integrieren. Es kann ja nur eine Frage der Zeit sein, bis andere Hoster gleich behandelt werden wollen. Microsoft hat ja schon Erfahrung mit entsprechenden Zertifizierungsprogramme. Insbesondere die Aufnahme von "Zertifizierungsstellen" als vertrauenswürdige RootCAs in das Betriebssystem ist ein bekannter und dokumentierter Prozess:

Es muss ja nicht automatisch gehen. Es würde ja reichen, wenn Microsoft entsprechende Hoster die gleichen Möglichkeiten einräumen würde, wie Office 365 und im Lync Updates, die mehr oder minder regelmäßig kommen, diese neuen Hoster verteilt oder ein eigenständiges Programm über Windows Updates verteilt, welches die Einträge nachpflegt.

Wann geht ein DNS-Alias (CNAME) ?

Die Pflege der Hoster könne man sich ersparen, wenn der Edge-Server nicht die strenge Namensüberprüfung durchführt, sondern auch mit einem CNAME auf einen anderen Server oder der Verweis des SRV-Records auf einen anderen Server toleriert werden würde. Dann könnte der Hoster einfach "sein Zertifikat" verwenden und dennoch viele Kunden darauf hosten.

Das Risiko dabei ist natürlich, dass jemand per DNS-Angriffen z.B. für eine Domain einen Federation-Eintrag vortäuschen oder umleiten könnte, um die Anfragen der Clients dieses Kunden zu erwischen

Können SNI-Zertifikate eine Lösung sein ?

Das Problem mit den Zertifikaten haben auch schon Webseiten-Betreiber bemerkt, wenn gerade auch hier Hoster hinter den knappen IP-Adressen mehrere Webseiten hosten. Zwar wird das ohne Verschlüsselung dank "HostHeader" schon heute intensiv genutzt, aber der TLS-Handshake finden ja vorher statt. Hier muss der Client den erwarteten Hostnamen schon mit dem TLS-Handshake mit senden (Lync 2013 auf Windows 7 macht das) und der Server passende dazu dann ein Zertifikat liefern. Das wäre aus meiner Sicht sogar der Königsweg, da damit jeder Kunde "sein" eigenes Zertifikat haben kann und dies vom Provider auf dem Edge-Server hinterlegt werden könnte. Das würde es auch erschweren, dass ich über die SAN-Einträge von einem Kunden auf den Hoster und dessen anderen Kunden schließen könnte.

Ein kurzer test mit einem Lync Communicator 2013 auf Windows 7 und einem Lync 2013 Edge auf Windows 2012 RTM ergab, dass beide beim SSL Client Hello das Feld "Server_Name" gefüllt haben. Ein einfacher NETMON-Filter hilft bei der Suche:

TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.ClientHello

Eventuell TLS-Proxy ?

Ich habe es noch nicht ausprobiert aber vielleicht muss man gar nicht gleich einen kompletten weiteren Edge Pools aufbauen, wenn man zu viele Namen für ein Zertifikat hat. Eventuell reicht es ja auch, dem Edge-Server weitere offizielle IP-Adressen zu geben und dann ein Programm zu nutzen, welches die Verbindungen dann zum existierenden Edge-Server weiter geben.

Auch dies könnte technisch eine Lösung darstellen, die aber deutlich weniger hübsch ist, als die SNI-Zertifikate

Weitere Links