Lync Server Zertifikate

Wer Lync und Exchange installiert, wird das Thema Zertifikate nicht vermeiden können. Bis auf wenige Rollen (z.B. Monitoring) benötigen alle Server ein Zertifikat, da sich die Lync-Server auch untereinander damit authentifizieren. Das geht schneller als Anmeldungen mit Computername und Kennwort und vor allem können die Verbindungen per TLS auf Gegenseitigkeit verschlüsselt und signiert werden.

Beachten Sie das auf Lync Planung beschriebene Tool, welches nach Eingabe von Daten ihnen die erforderlichen Zertifikate aufführt.

Achtung:
Auf Windows 2012 gibt es ein paar Besonderheiten zu beachten;
Lync 2013 Enterprise Pool Front-End Service don't start
http://social.technet.microsoft.com/Forums/en-US/lyncdeploy/thread/e1c7be2e-c922-4efe-9e47-b08ce63d2320/
Lync 2013 not starting on Windows 2012
http://blogs.technet.com/b/lync_tips_and_tricks/archive/2012/12/21/lync-2013-not-starting-on-windows-2012.aspx

Verwenden Sie intern für die Server nie ein gemeinsames gleiche Zertifikat mit allen Namen. Lync identifiziert den Kommunikationspartner per TLS und wenn z.B. Edge-Server und Frontend das gleiche Zertifikat nutzen, dann kann der Frontend nicht unterscheiden, ob die Kommunikation von Intern oder Extern ist. Schlimmer noch: Die externe Gegenstelle wird wie die gleichnamige interne "Trusted Application" behandelt und hat viel zu viele Rechte. Im Extremfall kann Jeder von Extern ohne Anmeldung sich als legitimer Anwender ausgeben. Zumindest das "Edge Internal Zertifikat" sollte nur den Namen des Edge Servers enthalten, der auch nicht als Trusted Application oder Trusted Applicationpool definiert sein darf.

Aussteller

Natürlich können Sie auf jedem Server ein "Selbstzertifikat" erstellen und diese auf allen anderen Servern und Clients als "Trusted Root" addieren. Praktikabel ist das aber nicht. Ab besten fahren Sie, wenn sie intern private Zertifikate einer eigenen Firmen CA verwenden und auf den ausgewählten externen Ports entsprechend "offizielle" Zertifikate. Sie können natürlich auch intern mit offiziellen Zertifikaten arbeiten, was aber natürlich zusätzliche Kosten bedeutet. Allerdings ist auch der Betrieb einer Firmen CA nicht kostenfrei. Mein Favorit ist natürlich trotzdem die Firmen CA , weil Sie damit auch Zertifikate für nahezu alle Funktionen (Router, Switches, Firewall, 802.1x, Smartcard, Webserver etc.) ausstellen können. Lync verwendet einfache Zertifikate vom Typ "Webserver". Trotzdem sollten Sie ein eigenes Template verwenden (Windows Enterprise CA erforderlich) um die Gültigkeitsdauer der Zertifikat auf mehr als ein Jahr zu setzen.

Für extern erreichbare Dienste sollten Sie aber immer Zertifikate von "Trusted Roots" heran ziehen. Es gibt von Microsoft ein Zertifizierungsprogramm mit "UC-kompatiblen" Zertifizierungsdiensten.

Im März 2011 waren hier vier CAs gelistet. 2018 waren es schon 8 CAs

Sie können aber auch jede andere CA wählen. Allerdings sollte sie SAN-Zertifikate ausstellen können, damit sie nicht für die Vielzahl an Namen je eine eigene IP-Adresse benötigen.

Insofern sollten Sie die Möglichkeit für Testzertifikate nutzen. Fast jede CA stellt ihnen ein "Domain Validated" Zertifikat für 30 oder 45 Tage aus.

Erforderliche Zertifikate

Folgende Namen sollten Sie über Zertifikate haben, wenn Sie genau eine SIP-Domain und eine SimpleURL in der form "meet.<sipdomain>/dialin und /join bedienen:

Server CA Namen Beschreibung

Lync Frontend
Lync Standard

Intern

CN=Poolfqdn
SAN=Poolfqdn
SAN=ServerFQDN
SAN=UCUpdates-R2
SAN=UCUpdates-R2.<DNSdomain>
SAN=sip.<sipdomain>
SAN=meet.firma.tld (SimpleURL)
SAN=lyncweb.firma.tld(LyncWS)

Der Standard Server hat natürlich keinen PoolFQDN, da hier der Server zugleich auch Pool und zumindest intern auch die Webservice URL ist

Anders ist dies, wenn Sie einen Pool haben. Dann muss das Zertifikat auf den Poolnamen ausgestellt werden aber auch die individuellen Servernamen müssen enthalten sein. Sie können sicher ein Zertifikat auf einem Server anfordern, in dem auch die anderen Server schon enthalten sind und dann dieses Zertifikat exportieren und auf den anderen Server importieren. Sie haben dann genau ein Zertifikat. Individuelle Zertifikate gehen aber auch und würden ihnen es einfacher machen, den echten Server z.B.: per OpenSSL zu identifizieren.

Beachten sie auch, dass Sie beim Einsatz von Lync Telefonen auch die beiden Namen UCUpdates-R2 und UCUpdates-R2.<dnsdomain> addieren und auch von intern die "Simple URLs addiert werden. Wer einen Pool mit LoadBalancer für Webservices benutzt, muss auch für diese gesonderte Webservice-URL einen Eintrag addieren.

Monitoring

kein

kein Zertifikat erforderlich

Die Monitoring-Rolle alleine braucht kein Zertifikat, weil die Frontend Server ihre Daten per MSMQ an die Monitoring-Rolle senden. Diese trägt die Daten dann in der SQL-Datenbank ein

SQL Reporting Services
IIS

Intern

CN=<servernamefqdn>

Um die Daten des Monitoring auszuwerten, dienst das SQL Reporting, welches per Browser angesprochen wird. Hier ist ein SSL-Zertifikat ratsam, damit Anmeldung und Daten nicht mitgeschnitten werden können. Dies kann auch ein DNS Alias sein.

Lync Edge extern
Access + WebConf

Extern

CN=sip.<sipdomain>
SAN=sip.<sipdomain>
SAN=webconf.<sipdomain>

Für den Edge Server sind zwei offizielle Namen samt Zertifikat erforderlich. Dies können zwei eigene Zertifikate sein oder ein SAN-Zertifikat mit beiden Namen.

Achtung: Wenn Sie mehrere SIP-Domains bedienen, dann benötigen sie mehrere SIP-Einträge, einen je Domain.

Lync Edge extern
AVEdge

Intern

CN=avedge.<sipdomain>

Für die dritte Funktion des Edge Server (AVEdge) reicht ein internes Zertifikat.

Lync Edge intern

Intern

CN=pool.<dnsdomain> oder CN=<servernamefqdn>

Auf der internen Seite des Edge Servers wird ein Zertifikat mit dem Namen des Pools als CN benötigt. Wenn es ein einzelner Server ist, dann ist der FQDN des Servers zu verwenden.

Lync:WebServices
Lync SimpleURL

Extern

CN=lyncweb.<sipdomain>
SAN=lyncweb.<sipdomain>
SAN=meet.<sipdomain>
SAN=lyncdiscover.<sipdomain>

In der Regel werden die Lync Webdienste und die Simple URLs über einen Reverse Proxy veröffentlicht. Dann bietet es sich an, diese Namen alle zusammen zu fassen.
LyncDiscover ist nicht "zwingend", da der mobile Clients auch mit HTTP arbeitet.

Lync: Alle anderen

intern

CN=ServerFQDN

Alle anderen Zertifikate sind für die internen Lync Server erforderlich und geben einfach die entsprechenden Funktionen der Server wieder, z.B. Direktoren, Groupchat etc. Diese führe ich nicht weiter auf, da es sowieso interne Zertifikate sind.

Exchange CAS
Intern

intern

CN=ServerFQDN
SAN=autodiscover.<maildomain>

Der Lync Client nutzt "Autodiscover" und "Exchange WebServices", um im Postfach des Benutzers nach Kalenderinformationen und Voicemails zu suchen. Dazu muss es intern einen Zugriff auf "autodiscover.<maildomain> durchführen können. Auch die URL für den Zugriff auf die Exchange Web Services muss per SSL gesichert sein. In der Regel verwenden Sie dazu interne Zertifikate auf den CAS-Servern, die auch den Autodiscover-Namen enthalten.

Exchange Internet
Autodiscover/EWS

Extern

CN=owa.<maildomain>
SAN=autodiscover.<maildomain>

Die gleiche Funktion ist erforderlich, wenn Lync Clients auch aus dem Internet ohne VPN arbeiten und auf Exchange zugreifen wollen. Der Name "Autodiscover" ist gesetzt. Die WebserviceURL ist meist identisch mit der URL für Outlook Web App.

ExchangeUM

intern

CN=ServerFQDN

Beim Einsatz von Exchange UM ist eine TLS-Verbindung von Lync zu Exchange-UM erforderlich. Dies funktioniert nur, wenn der Exchange Server ein Zertifikat gebunden hat, welches den FQDN des Servers hat.

Eine Firma mit genaue einem Adressraum könnte also sogar mit einem SAN-Zertifikat mit zwei Namen für den Edge und einen SAN-Zertifikat für den Reverse Proxy auskommen. Wenn Sie sich dann die Tabelle anschauen, dann sehen sie einen Bedarf für mindestens zwei Zertifikate:

Even though the certificate subject name is equal to the access Edge FQDN, the subject alternative name must also contain the access Edge FQDN because Transport Layer Security (TLS) ignores the subject name and uses the subject alternative name entries für validation.
Quelle: Certificate Requirements für External User Access http://technet.microsoft.com/en-us/library/gg398920.aspx

  • HTTPS-Reverse Proxy: Drei Namen in einem Zertifikat, eine IP-Adresse
    OWA, ActiveSync und Lync Webservices werden idealerweise über einen Reverse Proxy veröffentlicht und können mit einem SAN-Zertifikat damit über eine gemeinsame IP-Adresse veröffentlicht werden. Allerdings muss der Proxy dann die Zugriffe je nach URL an den richtigen Backend Server verteilen. Es ist aber problemlos möglich die Dienste von Exchange und Lync über einen Zugang zu veröffentlichen. Wenn Sie "owa.firma.de" für Outlook WebApp nutzen, dann könnten sie Sogar die Webservices unter dem Namen veröffentlichen. Nur die SimpleURL muss ein eigener FQDN sein, so dass ein Zertifikat mit drei Namen (webmail, autodiscover, meet) ausreichend wäre.
  • Lync Edge: zwei Namen in einem Zertifikat, drei IP-Adressen
    Für den Lync Edge brauchen Sie drei Namen, wovon zwei Namen in einem SAN-Zertifikat zusammen gefasst werden können und von einer externen CA ausgestellt sein müssen. Das dritte Zertifikat für die AVEdge-Rolle kann hingegen von einer internen CA ausgestellt sein.

Eine einfache Umgebung mit einem Exchange UM und OWA-Server, einem Lync Standard Server, einem Edge-Server und einem Reverse Proxy (z.B. TMG) kann wie folgt aussehen:

Auch wenn ich mir viel Mühe gegeben habe, das Thema Lync Zertifikate verständlich zu beschreiben, so kann es aufgrund der Komplexität kein narrensicheres "How-To" geben. Dazu sind zu viele Dinge möglich und von ihrer Umgebung abhängig. Diese Beschreibung sollte eine Firma mit einer "Single Domain" abdecken. Da Zertifikate aber nicht mehr der kritische Kostenfaktor sind, kann es manchmal sinnvoller sein, Funktionen über Namen zu trennen statt aus wilder Sparwut (Geiz ist nicht geil !) alles in SAN-Zertifikaten und IP-Adressen zu konzentrieren. Das kann auch aus Sicherheitsaspekten und zur Lastverteilung sinnvoll sein.

Unterstützung durch Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach an.

Wildcard-Zertifikate

Um Zertifikate zu sparen stellt sich immer die Frage nach dem Einsatz von Wildcard-Zertifikate. Das ist insbesondere für extern veröffentlichte Dienste interessant wie z.B. Lyncdiscover, LyncWeb, Office WebApps etc..

Auf den Lync Servern selbst ist es in der Regel nicht erlaubt, einen Wildcard-Eintrag als "CN" zu nutzen. Es ist hingegen unproblematisch zusätzlich einen "*.<domain>" als Eintrag im SAN-Feld zu addieren. Nur bringt er da nicht immer sehr viel.

Die komplette Lync/SkypefB-Plattform ist auf Sicherheit ausgelegt und nutzt intensiv nicht nur TLS zum Verschlüsseln, sondern auch MTLS um sich gegenseitig zu authentifizieren. Und dazu ist der CN natürlich wichtig, damit ein Server sich beim der Gegenseite ausweisen kann und eingehende Verbindungen zuverlässig identifiziert werden können. Dies gilt um so mehr, als eine Kompatibilität mit älteren Clients und Servern gefordert ist. Allerdings sterben diese Clients und Server (z.B. OCS und alte Phone Edition Versionen) langsam aus. Problematisch hier ist vielleicht noch das Thema Update, wenn sie ein ganz altes Telefon nicht auf eine neue Firmware bringen können, weil der Lync Server eben schon ein Wildcard-Zertifikat hat.

Firmen, die SkypeFB On-Prem einsetzen, werden in den meisten Fällen auch eine eigene Firmen CA betreiben. Damit ist die Bereitstellung von Zertifikaten für interne Server und URLs natürlich sehr einfach. Dies ist sogar erforderlich, wenn Sie intern eine DNS-Domäne nutzen, für die sie nie Zertifikate von einer öffentlichen PKI bekommen.

Für die externen Zertifikate habe ich für Exchange Autodiscover und EWS, für Lync Web, Join, Meet und Office Web Apps bislang keine negativen Auswirkungen von WildCard-Zertifikaten feststellen können. Diese drei HTTP-Dienste lassen sich damit wunderbar auch über einen Reverse Proxy hinter eine IP-Adresse veröffentlichen, wenn der Reverse Proxy oder Loadbalancer anhand des Hostheader die Anfragen zum richtigen Backend weitergeben kann.

Für den EdgeServer hingegen habe ich bislang immer öffentliche Zertifikate genutzt, die auch auf den DNS-Namen ausgestellt sind, damit ich hier keine Kompatibilitätsprobleme mit anderen Gegenstellen zu erwarten habe. Dies ist speziell bei bestimmten Clients und Federation nicht auszuschließen. Sie können natürlich den Selbstversuch wagen und auch hier das Wildcard-Zertifikat verwenden und einfach darauf warten, was nicht geht.

Besonderheit "Policy Identifier"

"Eigentlich" können Sie jede Zertifizierungsstelle für die Ausstellung von Lync-Zertifikaten nutzen. Allerdings ist es mir im März 2011 z.B.: mit AlphaSSL passiert, dass der Lync-Edge mich das Zertifikat nicht per GUI zuweisen lies und selbst nach einer Konfiguration per Lync PowerShell das Zertifikat immer noch als "invalid" in der GUI angezeigt wurde':

Bei einer genaueren Untersuchung der beiden Zertifikate konnte ich nur einen unterschied ausmachen. Das sieht gut zu sehen, wenn die beiden Zertifikate gegenüber gestellt werden.

[1]Certificate Policy:
     Policy Identifier=1.3.6.1.4.1.4146.1.10.10
     [1,1]Policy Qualifier Info:	
          Policy Qualifier Id=CPS
          Qualifier:
               http://www.alphassl.com/repository/

[1]Certificate Policy:
     Policy Identifier=1.3.6.1.4.1.6449.1.2.2.7
     [1,1]Policy Qualifier Info:
          Policy Qualifier Id=CPS
          Qualifier:
               http://www.positivessl.com/CPS

Der einzige für mich erkennbare unterschied war der "Policy Identifier". Alle anderen Einstellungen, die aus meiner Sicht überhaupt relevant gewesen wären, wie die "Key usage", "Enhanced Keys usage" oder auch der Antragstellername etc. waren ohne Befund. Letztlich war der Fehler aber das falsche Intermediate CA und die Verwendung des Testzertifikats. Die "richtigen" Zertifikate unterliegen nicht einer solchen Einschränkung.

Jedes Kettenglied an seinem Platz - Chains

Wenn Sie Zertifikate installieren, dann sind diese in der Regel nicht von einer Stammzertifizierungsstelle sondern eine Zwischen-CA ausgestellt. Damit ein Zertifikat auf dem Server korrekt verwendet werden kann, muss dieser Server das Stammzertifikat aber auch alle Intermediate-Zertifikate vorhalten. Beim TLS-Handshake sendet der Server nämlich die komplette Zertifikatkette zur anderen Seite. Nur dann reicht es der Gegenseite das Stammzertifikat zu kennen. Damit da aber alles funktioniert, müssen die Zertifikate alle an dem richtigen Ort sein. Wenn Sie die MMC für Computer-Zertifikate öffnen, dann sehen Sie sehr viele Ablageorte:

Relevant sind da eigentlich nur

  • Eigene Zertifikate
    Da liegt ihr Zertifikat samt dem privaten Schlüssel drin. Hier haben aber ZwischenCAs oder Root CAs nichts drin verloren!. Es gibt aber leider Import-Vorgänge, die beim Import einer P12 der PFX-Datei mit allen Zertifikaten auch die ZwischenCAs und RootCAs hier rein importieren. Diese müssen Sie in den passenden Ordner verschieben.
  • Zwischenzertifizierungsstelle
    Hier müssen alle Zertifikate (haben keinen privaten Key) rein, die in der Kette ihres Zertifikats enthalten sind. Ihr eigenes Zertifikat hat hier nichts verloren und auch das RootCA ist hier nicht richig
  • Vertrauenswürdige Stammzertifizierungsstellen
    Hier sind die Root-CAs und nur diese CAs drin. Also weder ihr Computer-Zertifikat noch die Zwischen CAs

Ob das so ist, kann recht einfach per PowerShell geprüft werden

# Alle hier aufgelisteten Zertifikate sind "falsch"

# Listet alle falschen Zertifikate in der RootCA Liste
Get-ChildItem cert:\localmachine\root | where {$_.issuer -ne $_.subject}

# Listet alle RootCAs im intermediate Store
Get-ChildItem cert:\localmachine\ca | where {$_.issuer -eq $_.subject}

# Listet alle Cert im My-Store, die Root oder selSigned sind
Get-ChildItem cert:\localmachine\my | where {$_.issuer -eq $_.subject}

Im Idealfall werden keine Zertifikate ausgegeben.

Zertifikate und CRL

Bei einer jüngst vorgenommenen Lync 2013 Standard Server Installation als "Proof of Concept" in einer TestUmgebung bin ich auf einen Effekt gestoßen. Die Installation selbst war fast problemlos und nach einigen Stunden warten auf die VMs konnte ich die Zertifikatsanforderungen erstellen und von der Firmen-CA ausstellen lassen und in Lync importieren. Einige Fehler haben mich aber stutzig gemacht:

  1. Mediation Server konnte sich nicht mit dem Frontend verbinden
  2. Callpark ist nicht gestartet
  3. Lync 2013 Client konnte sich nicht mit dem Server verbinden

Ein "telnet Server 5061" und eine Anmeldung mit dem Lync 2010 Client hat aber funktioniert und auch NETMON zeigte den Anfang eines TLS-Handshake. Auch der Zugriff mit einem Browser auf https://lyncserver/cscp" hat ohne Warnung funktioniert. Ich habe mir dann das Zertifikat genauer angeschaut und erstaunt festgestellt, dass es zwar von einer Unternehmens-CA ausgestellt wurde aber diese keine CRL eingefügt hat. Damit habe ich nun vier Varianten, warum eine SSL Verbindung nicht von Lync 2013 hergestellt werden kann

  1. CRL hinterlegt und erreichbar und nicht zurück gezogen
  2. CRL hinterlegt und erreichbar und zurück gezogen
  3. CRL hinterlegt und nicht erreichbar
  4. CRL gar nicht vorhanden
    In dem Fall kann der Client und Mediation Server die CRL nicht prüfen und stoppt die Verarbeitung

Nachdem das Zertifikat durch eines mit einer CRL ersetzt wurde, waren alle Probleme verschwunden. Ich muss natürlich nicht darauf hinweisen, dass der Betrieb einer CA ohne Bereitstellung einer CRL nicht gerade professionell ist.

Fremde Zertifikate im Store

Speziell auf den Edge-Servern können Sie auch mal im Zertifikatsspeicher auf sehr viele Zertifikate stoßen. Das liegt wohl auch daran, dass der Edge Server von der Gegenseite empfangene Zertifikate bei sich speichert. Ich sehe zwar erst mal keinen direkten Sinn darin aber es könnte ja eine Art "Caching" sein. Bei einer eingehenden Verbindung kann der Access Edge-Server dann direkt mal nachschauen, ob er das Zertifikat schon kennt und sich so den ein oder anderen CRL-Check sparen. Genau genommen sollte er aber das gerade nicht machen. Sei es drum: Mein Edge-Server sah z.B. wo aus:

In meinem Beispiel sind es fast 1000 Zertifikate. Genau genommen könnte man ja nun über diese Liste Auswertungen fahren, z.B. welche Firmen wohl einen Edge-Server für welche Domänen betreiben, welche ausstellende CA wohl das meiste Geld verdient und welche Zertifikate vielleicht demnächst auslaufen. Das lasse ich aber. Wenn es auch aus Sicht des Skype Edge Servers zu viele Zertifikate sind, dann erscheint sogar eine Warnung im Eventlog.

Event: Warning 
EventID 14374
Source: LS Access Edge

The server certificate store for holding partner certificates is full.
The number of certificates written to the store (RtcSrv\Accepted Certificates) reached the configured limit. 
No more certificates will be written to the store until the next restart.

Cause: The server certificate store for holding peer certificates already has the maximum number of certificates permitted by configuration.

Resolution:
Delete the certificates from that store using Certificate Manager or 
using the LCSCertUtil tool supplied as part of the resource kit.

Leider gibt es schon die ein oder anderen Probleme, wenn hier zu viele Zertifikate vorhanden sind

Zertifikate im AD

Erst einige Zeit später habe ich auch noch eine Stelle gefunden, die vermutlich kaum bekannt ist. Auch in der AD-Domain werden Informationen über Zertifikate hinterlegt:

OU=LyncCertificates,OU=Distributed KeyMan,OU=Microsoft,OU=Program Data,DC=msxfaq,DC=net

An der gleichen Stelle hinterlässt z.B. auch ADFS einige Einstellungen

Weitere Links