OCS Zertifikate

Auch wenn vermutlich die meisten Verbindungen im Internet "unverschlüsselt" sind und gerade VoIP-Übertragungen sehr einfach abgehört werden können (Siehe VoIP Sniffer), so nutzt Microsoft hier konsequent SSL zur Verschlüsselung der Kommunikation, zumindest solange es im gleichen System bleibt. Das bedeutet natürlich für Sie als Administrator, dass die Server allesamt mit Zertifikaten ausgestattet werden müssen.

Man kann OCS natürlich auch absichtlich "unsicher" einstellen und das kann durchaus sinnvoll sein, um zur Fehlersuche die Daten auf dem Netzwerk gezielt mitzuschneiden. Aber man kann OCS auch ganz ohne mit aktivierter Verschlüsselung debuggen (siehe OCS Debugging), so dass es keinen Grund gibt, auf die Verschlüsselung zu verzichten. Der einzige Grund wäre der, dass Sie nicht wissen wie es geht. dann wäre folgendes ratsam zu lesen:

Sie sehen schon, dass sich sehr viele Seiten auf der MSXFAQ um Zertifikate und Sicherheit drehen. Es müssen ja auch am Anfang gar keine "gekauften" Zertifikate sein. Sie sollten aber keine Zertifikate mit SelfSSL erstellen, da dies mehr Mühe macht, diese später auf allen Clients als "trusted" zu addieren. Eine eigene Zertifizierungsstelle im Active Directory sollte aber ausreichend sei. Die ist dann zumindest auf allen Windows Systemen im gleichen Forest nach kurzer Zeit auch "Vertrauenswürdig".

Friendly Name
Bei der Ausstellung eines Zertifikats kann man als Administrator auch einen "Anzeigename" angeben, der in den Auswahlboxen sichtbar ist. Es ist durchaus ratsam, hier den gleichen Namen wie den Antragsteller zu pflegen, da einige Clients ansonsten ein Problem bekommen.

öffentliche Zertifikate werden aber sinnvoll, wenn Sie einen OCS-EDGE-Server über das Internet betreiben oder Clients angebunden werden, deren Stammzertifikate nicht automatisch vom Active Directory gefüllt werden, z.B. Telefone oder Clients, die nicht Mitglied des Forest sind. Dann kann auch intern ein öffentliches Zertifikat ratsam sein.

Die Planung, welche Namen und "Subject Alternate Names" auf welchem Server installiert werden müssen, kann ich im Rahmen der MSXFAQ aber nicht erbringen. Dazu sind die Aufgabenstellungen zu vielfältig. An vielen Stellen unterstützt bzw. fordert der Installationsassistent die Einrichtung und Zuweisung der Zertifikate.

Aussteller und Verfallszeit von Zertifikaten

In den folgenden Abschnitten werden ich Zertifikate in "privat" und "offiziell" unterscheiden.

  • Privates Zertifikat
    Diese Zertifikat wird von ihrer eigenen Zertifizierungsstelle ausgestellt und kann ganz normal genutzt werden. Die einzige Einschränkung ist die, dass vermutlich nur die Computer in ihrem Active Directory Forest diesem Zertifikat vertrauen. Andere Systeme werden eine Zertifikatswarnung erhalten und können sich natürlich das Stammzertifikat manuell installieren. Schön ist dies aber nicht. Dafür "kostet" Sie dieses Zertifikat kaum mehr als ein paar Minuten Arbeit.
  • öffentliches Zertifikat
    Solche Zertifikate "kaufen" sie von einer der verfügbaren Zertifizierungsstellen. Der unterschied zu einem privaten Zertifikat besteht darin, dass die Aussteller auf den meisten Systemen schon als "vertrauenswürdig" vorinstalliert sind und damit ohne Warnungen genutzt werden können.

Technisch gesehen sind beide Zertifikattypen natürlich absolut identisch. Sie unterscheiden sich nur im Aussteller

Beachten Sie die Gültigkeit ihrer Zertifikate und sorgen sie rechtzeitig für eine Erneuerung bzw. Verlängern der eingesetzten Zertifikate.

Wo kommen Zertifikate zum Einsatz ?

Verschiedene Rollen haben eigene Zertifikate. Dazu zählen:

Rolle Funktion Zertifikat

Standard oder Frontend Server/Pool

Verschlüsselung des internen SIP-Verkehrs

privates Zertifikat einer eigenen CA problemlos möglich

Mediation Server

Verschlüsseln zwischen Mediation Server und internen Teilnehmern bzw. dem OCS-Serverpool.
Seltener genutzt zur Verschlüsselung zwischen Telefonie-Gateway und Mediation Server.

privates Zertifikat einer eigenen CA problemlos möglich

Edge Intern

Zugriff von Clients aus dem internen LAN

privates Zertifikat einer eigenen CA problemlos möglich

Edge Access extern

Zugriff von Clients aus dem Internet und Verschlüsselung der Daten, Verschlüsselung von Federation

Extern: Offizielles Zertifikat

Edge WebConf

Zugriff von Clients aus dem Internet und Verschlüsselung der Daten, Verschlüsselung von Federation

Extern: Offizielles Zertifikat

Edge AV-Edge

Zugriff von Clients aus dem Internet und Verschlüsselung der Daten, Verschlüsselung von Federation

privates Zertifikat einer eigenen CA problemlos möglich

Edge AV-Authentication

Ausstellen von Authentifizierungstokens

Privates Zertifikat

CWA

Verschlüsselung des Zugriffs per Webbrowser

Intern: private Zertifikate funktioneiren
Extern: Offizielle Zertifikate (Beachten Sie die zusätzlichen DNS-Aliasse (av. Und download.).

Publishing CWA

Der CWA ist ein "Webserver" und als solches kann er ganz einfach über z.B. eine Webveröffentlichungsregel eines ISA-Server, aber auch über andere Firewalls und Reverse Proxies im Internet freigeschaltet werden.

Offizielles Zertifikat

UM Gateway

Auch die Verbindung zwischen Mediation Server und Gateway können per TLS verschlüsselt werden. Prüfen Sie aber, ob ihr Gateway dies unterstützt.

Meist privates Zertifikat.

Für den Anfang sollen diese wichtigen Zertifikate ausreichen.

Frontend/Standardserver mit WebServices

Jede OCS-Installation startet mit einem OCS-Standardserver oder einem Enterprise Frontend Server, welcher natürlich ein Zertifikat benötigt.

Dieser Server ist in der Regel nur von internen Clients anzusprechen, so dass ein  Zertifikat einer internen CA in den meisten Fällen ausreichend ist.

Mediation Server

Der Mediation Server vermittelt die Telefonie-Verbindungen zwischen OCS Clients und der klassischen SIP-Welt, die in den meisten Fällen zu einem Gateway weiter geht. Der Mediation Server benötigt für die interne Kommunikation ein Zertifikat.

Dieses Zertifikat kann auch zur Verbindung zum Gateway verwendet werden, wenn das Gateway diese Funktion (SIP over TLS) unterstützt. Die meisten Gateway-Anbindungen verzichten aber auf TLS und nutzten einfach SIP over TCP was toleriert werden kann, wenn die Verbindung zwischen Mediation Server und Gateway z.B. ein eigenes VLAN oder ein eigenes Netzwerksegment ist.

Edge Server

Für Zugriffe aus dem "Internet", z.B. für Heimarbeiter, mobile Benutzer (z.B. Communicator Mobile) aber auch Federation zur anderen Firmen ist ein Edge-Server erforderlich. Dieser muss ein offizielles Zertifikat haben, wenn Sie eine Verbindung mit anderen Kunden anstreben. Nur wenn Sie ganz sicher sind oder gerade testen und sicher alle Endgeräte und externe Firewalls einem internen Zertifikat vertrauen, können Sie auf dem Edge mit privaten Zertifikaten arbeiten.

Die komplette Konfiguration der Ports und Zertifikate erfolgt bei der Einrichtung über den Assistenten.

Communicator Web Access und CWA-Veröffentlichung

Eine weitere losgelöste Rolle, die in den meisten Umgebungen sogar zwei Zertifikate benötigt ist der Communicator Web Access. Die CWA-Rolle wird natürlich auf einem internen Server installiert. Auf dem IIS sollte natürlich ein Zertifikat installiert werden, damit die Kennworte und übertragenen Daten verschlüsselt werden können.

Wird der Zugriff auch aus dem Internet erforderlich, dann sollten Sie den CWA-Server sicher nicht einfach über eine Port-Veröffentlichung komplett frei geben, sondern es ist eine gute Praxis, mit einem ISA-Server davor das Web zu veröffentlichen. Natürlich können Sie auch andere Gateways verwenden, die einen Webserver sicher veröffentlichen können. Auf diesem Server sollten Sie dann aber ein offizielles Zertifikat einsetzen, um Warnungen bei den Anwendern zu vermeiden.

Zertifikate zuweisen

Bei fast allen Rollen mit Zertifikaten gibt es einen Assistenten, welcher Sie bei der Anforderung, der Verarbeitung und der Konfiguration für die jeweilige OCS-Rolle aktiv unterstützt.

OCS Zertifikatassistent

Nutzen Sie diese Assistenten, denn in den meisten Fällen sind die damit angeforderten Zertifikate auch passend. Wenn Sie unsicher sind, dann sollten Sie bei internen Zertifikaten einfach einen Versuch starten. Wer offizielle Zertifikate beantragen muss, sollte sich eine Zertifizierungsstelle suchen, welche Test und Probe-Zertifikate ausstellt, die z.B. nur wenige Tage gültig sind. So können Sie aber den gesamten Prozess schon einmal durchspielen.

Liste der Zertifikate

Selbst bei einem einfachen OCS-Deployment kommen sehr schnell einige Zertifikate zusammen. Wenn Sie nur einen Standard Server, einen Edge, einen CWA und einen Mediation-Server installieren, dann sind folgende Zertifikate in ihrem System verteilt:

Server CA Name:Port

Standard/Frontend

Intern oder Extern

Enterprise Pool: FQDN des pool:5061
Standardserver: FQDN des Servers:5061

Mediation intern

Intern oder Extern

intern:FQDN des Servers:5061
extern:FQDN des Servers:5062

Gateway

meist kein Zertifikat (5060 TCP)
Sprachverschlüsselung mit TLS möglich Intern oder Extern

FQDN des Gateway:5061

CWA

Extern

internetname1:443

Edge AV

Extern

internetname2:443

Edge WebConf

Extern

internetname3:443

Edge Access

Extern

internetname4:443

Edge Federation (kann mit Access identisch sein)

Extern

internetname4:5061

Wer auf dem Edge auf die Nutzung der Ports 443 verzichtet, kann die drei Dienste natürlich auch auf andere Ports legen und dann mit einem Zertifikate alle drei Dienste abdecken und wer mit einem ISA unterwegs ist, kann das gleiche Zertifikat auch noch für CWA verwenden. Aber es könnte sein, dass diverse Firewalls diese portfremden Zugriffe blocken.

Weitere Server und Rollen in der Umgebung erfordern natürlich weitere Zertifikate. Solange die Dienste aber nur von "intern" genutzt werden und Sie alle Clients mit dem Stammzertifikat ihrer internen CA ausstatten können (z.B.: per GPO), können Sie die Kosten für externe Zertifikate sparen.

Ablauf von Zertifikaten

Natürlich haben Zertifikate auch nur eine begrenzte Gültigkeit. Der OCS-Server erkennt demnächst ablaufende Zertifikate. Wie viele andere Dienste wird die Meldung im Eventlog eingetragen:

OCS Verfallszeit

Wohl dem, der zumindest eine kleine Eventlog-Überwachung hat, so dass er rechtzeitig davon erfährt.

Zertifikatfehler

Da OCS auch Zertifikate zwischen den Servern zur Authentifizierung nutzt, kann ein defektes oder "falsches" Zertifikat natürlich Probleme hervor rufen. Dazu gibt es die einfachsten drei Fehler

  • Gültigkeit
    Es wäre nicht das erste und letzte mal, dass ein Zertifikat einfach nur "abgelaufen" ist.
  • Name und SAN-Name
    Gerade wenn ein Server mehrere Namen hat (z.B.: den echten Namen und mehrere Aliasnamen wie sip.domain.tld), ist es wichtig den physikalischen Namen als "Antragssteller" im CN= zu haben undin den SAN-Namen.
  • Aussteller
    Natürlich muss auch die ausstellende CA vertrauenswürdig sein. Das ist in Firmennetzwerken mit einer einzelnen Firmen CA nicht allzu schwer. Extern können Intermediate CAs aber schon das Leben schwerer machen.
  • Groß/Kleinschrift
    Auch wenn es selten erwähnt wird, so ist die Schreibweise der Namen nicht Case-Sensibel.

Und dann gibt es noch ein paar, die man nicht auf den ersten Blick sieht

  • Zertifikatsart = WebServer
    Anscheinend nutzt OCS immer nur "Webserverzertifikate". Ich habe schon versucht ein "Computerzertifikat" zu installieren, aber OCS hat dieses nicht zur Auswahl angeboten.
  • Verwendung
    Im Zertifikat ist hinterlegt, für welchen Einsatzzweck dieses Zertifikat verwendet werden darf, z.B. Serverauthentifizierung, Clientauthentifizierung, Sichere E-Mail, Smartcard-Login etc. Gerade "Webserver-Zertifikate" sind oft nur für die Serverauthentifizierung ausgestellt, d.h. der Client kann den Server prüfen.
  • Intermediate CA nicht in der Chain
    Gerade wenn man ein Zertifikat einer offiziellen CA hat, kann es sein, dass die ROOT wohl bekannt ist aber die Zwischenstellen nicht. Im SSL-Protokoll werden, sofern der Server zugriff auf die Intermediate hat, diese auch mit übertragen, so dass der Client die Kette prüfen kann. Wen ihr Server die Intermediate nicht hat, kann er sie nicht senden und nur Clients, die zufällig das Intermediate auch haben, können die Kette prüfen.
  • SHA1, SHA2 und andere
    Windows XP SP2 kann per Default noch kein "SHA-2". Auch andere "exotischere" Hash-Verfahren können diverse Clients oder Server verwirren.

Meist finden Sie aber im OCS Eventlog deutliche Hinweise, z.B.

Sie sollten also das Eventlog wachsam im Auge haben.

Achtung Windows 2008 R2: Hierzu ist ein Hotfix erforderlich. Siehe auch
975858 An application or service that calls the InitializeSecurityContext function together with the ISC_REQ_EXTENDED_ERROR flag may encounter a TLS/SSL negotiation failure on a computer that is running Windows Server 2008 R2 or Windows 7

Weitere Links