Demande et configuration d’un certificat pour votre proxy HTTP inverse

 

Dernière rubrique modifiée : 2012-07-15

Le serveur proxy inverse typique utilise des certificats d’une autorité de certification publique et de l’infrastructure d’autorité de certification interne utilisée pour vos besoins d’entreprise lorsque des certificats sont nécessaires. Microsoft Lync Server 2010 peut utiliser une infrastructure à clé publique (PKI, Public Key Infrastructure) d’entreprise pour tous les besoins internes, si une telle infrastructure est déployée. Vous pouvez également utiliser les certificats d’autorité de certification publique pour tous les besoins, internes et externes. Si vous envisagez d’utiliser les certificats d’autorité de certification interne et d’autorité de certification publique, le proxy inverse a besoin du certificat racine (et des certificats intermédiaires) de l’autorité de certification publique et du certificat racine (et des certificats intermédiaires) de l’autorité de certifications interne. Vous devez installer les certificats racines et les certificats d’autorité de certification intermédiaire sur le serveur proxy inverse. Reportez-vous à la documentation de votre proxy inverse pour déterminer les modalités de chargement des certificats racines et intermédiaires dans le proxy inverse.

Vous devez installer un certificat public de type serveur web sur votre serveur proxy inverse. Un tel certificat garantit que le certificat peut communiquer correctement avec les demandes de client. Le nom du sujet de certificat public sera le nom externe des services web externes du serveur frontal ou du pool de serveurs frontaux. Dans les exemples utilisés pour l’Architecture de référence dans Planification de l’accès des utilisateurs externes, le nom de domaine complet externe du serveur frontal ou des pools de serveurs frontaux est webext.contoso.com. La définition de l’autre nom du sujet du certificat doit contenir les noms de domaine complets des services web externes publiés de chaque pool hébergeant les utilisateurs activés pour l’accès à distance. Un écouteur et un certificat séparés doivent être configurés pour les noms de domaine complets des services web externes des directeur ou pool de directeurs utilisés au sein de l’infrastructure Edge. Par exemple, un nom du sujet et un autre nom du sujet du directeur ou du pool de directeurs pour le certificat peut être webdirext.contosom. L’autre nom du sujet doit aussi contenir l’URL simple de réunion, l’URL simple de conférence rendez-vous et, si vous déployez des applications mobiles et souhaitez utiliser la découverte automatique, l’URL du service de découverte automatique externe, comme indiqué dans le tableau suivant. L’URL simple et les autres noms du sujet de Lync Discover restent les mêmes que pour le serveur frontal, comme indiqué dans le tableau.

	Valeur	Exemple
Nom du sujet	Nom de domaine complet du pool	webext.contoso.com
Autre nom du sujet	Nom de domaine complet du pool	webext.contoso.com
Autre nom du sujet	URL simple de réunion Remarque : Toutes les URL simples de réunion doivent se trouver dans l’autre nom de sujet. Chaque domaine SIP doit comporter au moins une URL simple de réunion active.	meet.contoso.com
Autre nom du sujet	URL simple Dial-in	dialin.contoso.com
Autre nom du sujet	URL du service de découverte automatique externe	lyncdiscover.contoso.com

Remarque :

Si votre déploiement interne se compose de plusieurs serveurs Standard Edition ou pools frontaux, vous devez configurer les règles de publication Web pour chaque nom de domaine complet (FQDN) externe de la batterie de serveurs Web. En outre, soit vous avez besoin d’un certificat et d’un port d’écoute Web pour chacun, soit vous devez obtenir un certificat dont l’autre nom de sujet contient les noms utilisés par tous les pools, l’affecter à un port d’écoute Web et le partager entre plusieurs règles de publication Web.