Anfordern und Konfigurieren eines Zertifikats für den HTTP-Reverseproxy

Letztes Änderungsdatum des Themas: 2012-07-15

Auf einem typischen Reverseproxyserver sind Zertifikate von sowohl einer öffentlichen Zertifizierungsstelle als auch von der internen Zertifizierungsstellen-Infrastruktur vorhanden, die für Ihre Unternehmensanforderungen verwendet wird, wenn Zertifikate erforderlich sind. Microsoft Lync Server 2010 kann eine interne Public Key-Infrastruktur (PKI) für alle internen Zwecke verwenden, wenn Sie eine bereitstellen. Sie können auch Zertifikate von einer öffentlichen Zertifizierungsstelle für alle internen und externen Zwecke verwenden. Wenn Sie die interne Zertifizierungsstelle und Zertifikate einer öffentlichen Zertifizierungsstelle verwenden möchten, benötigt der Reverseproxy das Stammzertifikat (und alle Zwischenzertifikate) der öffentlichen Zertifizierungsstelle sowie das Stammzertifikat (und alle Zwischenzertifikate) von der internen Zertifizierungsstelle. Sie müssen das Stammzertifikat und alle Zertifikate von Zwischenzertifizierungsstellen auf dem Reverseproxyserver installieren. Lesen Sie in der Dokumentation für Ihren Reverseproxyserver nach, um zu bestimmen, wie die Stamm- und Zwischenzertifikate auf den Reverseproxyserver geladen werden.

Sie müssen ein öffentliches Webserverzertifikat auf Ihrem Reverseproxyserver installieren. Ein Webserverzertifikat stellt sicher, dass das Zertifikat ordnungsgemäß mit den Clientanforderungen kommunizieren kann. Der Antragstellernamen des öffentlichen Zertifikats ist der externe Name der externen Webdienste von Front-End-Server oder Front-End-Pool. In den Beispielen, die für die Referenzarchitektur in Planen des Zugriffs externer Benutzer verwendet wurden, lautet der externe FQDN für Front-End-Server oder Front-End-Pools "webext.contoso.com". Die Definition des alternativen Antragstellernamens des Zertifikats muss die veröffentlichten vollqualifizierten Domänennamen (FQDNs) der externen Webdienste für jeden Pool enthalten, auf dem Benutzer verwaltet werden, für die der Remotezugriff aktiviert ist. Für alle FQDNs externer Webdienste aller Director oder Directorpool, die innerhalb der Edgeinfrastruktur verwendet werden, muss ein separater Listener und eine separates Zertifikat konfiguriert werden. Ein Beispiel für einen Director- oder Directorpool-Antragstellernamen oder alternativen Antragstellernamen für das Zertifikat lautet "webdirext.contosom". In den alternativen Antragstellernamen müssen außerdem die einfachen URLs für Besprechungen und Einwahl enthalten sein, und wenn Sie mobile Geräte bereitstellen und die Verwendung der automatischen Ermittlung planen, muss auch die externe AutoErmittlungsdienst-URL enthalten sein, wie in der folgenden Tabelle dargestellt. Die einfache URL und Lync-Ermittlungs-SANs ändern sich gegenüber der Front-End-Server nicht, wie in der Tabelle dargestellt.

	Wert	Beispiel
Antragstellername	Pool-FQDN	webext.contoso.com
Alternativer Antragstellername	Pool-FQDN	webext.contoso.com
Alternativer Antragstellername	Einfache URL für Besprechungen Hinweis: Alle einfachen URLs für Besprechungen müssen in den alternativen Antragstellernamen enthalten sein. Jede SIP-Domäne muss über mindestens eine aktive einfache URL für Besprechungen verfügen.	meet.contoso.com
Alternativer Antragstellername	Einfache URLs vom Typ "Dialin"	dialin.contoso.com
Alternativer Antragstellername	URL des externen AutoErmittlungsdiensts	lyncdiscover.contoso.com

Hinweis:

Wenn Ihre interne Bereitstellung mehr als einen Standard Edition-Server oder Front-End-Pool umfasst, müssen Sie Webveröffentlichungsregeln für jeden externen FQDN der Webfarm konfigurieren. Außerdem benötigen Sie entweder ein Zertifikat und einen Weblistener für jeden Eintrag, oder Sie müssen ein Zertifikat anfordern, dessen Liste alternativer Antragstellernamen die Namen enthält, die von allen Pools verwendet werden. Diese müssen einem Weblistener zugewiesen und in mehreren Webveröffentlichungsregeln gemeinsam verwendet werden.