Lync 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.

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

CA-Name Webseite
Entrust http://www.entrust.net/microsoft/
Comodo http://www.comodo.com/msexchange
DigiCert http://www.digicert.com/unified-communications-ssl-tls.htm
GlobalSign http://www.globalsign.com/ssl/buy-ssl-certificates/unified-communications-ssl/

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:WebServices
Lync SimpleURL		 Extern
 CN=lyncweb.<sipdomain>
SAN=lyncweb.<sipdomain>
SAN=meet.<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.
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 ExchangeUM erforderlich. Dies funktioniert nur, wenn der Exchange Server ein Zertifikat gebunden hat, welches den FQDN des Servers hat.

Wildcard Zertifikate sind intern möglich, aber mit Einschränkungen verbunden (Kompatibilität mit OCS etc.).

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:

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.

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.

Weitere Links

Keywords:Lync Zertifikate