Activer HTTPS sur votre serveur Web

Pour sécuriser la communication réseau entre ArcGIS Web Adaptor et l’organisation ArcGIS Enterprise, utilisez le protocole HTTPS.

Le protocole HTTPS est une technologie de sécurité standard qui permet d’établir une liaison chiffrée entre un serveur Web et un client Web. HTTPS facilite la sécurisation des communications sur le réseau en identifiant et en authentifiant le serveur, ainsi que la confidentialité et l’intégrité des données transmises. Etant donné que le protocole HTTPS empêche l’écoute ou la falsification des informations envoyées sur le réseau, il doit être utilisé avec un mécanisme de connexion ou d’authentification et sur tout réseau sur lequel transite des informations confidentielles ou propriétaires.

Remarque :

L’utilisation du port HTTPS 443 par défaut convient à la grande majorité des déploiements. Dans de rares cas, il arrive qu’une instance de ArcGIS Web Adaptor ne puisse pas utiliser le port 443 sur son serveur Web pour des raisons propres à l’organisation. Si votre organisation se trouve dans ce cas, consultez la rubrique Utiliser d’autres ports que ceux par défaut pour l’instance ArcGIS Web Adaptor du portail, qui décrit les étapes supplémentaires permettant de configurer une solution de remplacement.

L’activation du protocole HTTPS sur un serveur Web requiert un certificat de serveur contenant une clé publique et une clé privée. Chaque serveur Web dispose de sa propre méthode d’importation ou de référencement d’un certificat dans un processus d’écoute.

Assurez-vous également que votre serveur Web est configuré de façon à ignorer les certificats clients lors de l’accès aux services sécurisés sur HTTPS, sauf si l’authentification au niveau du Web via une authentification de certificat client reposant sur l’infrastructure à clé publique (PKI) est configurée.

Créer ou obtenir un certificat du serveur

Pour créer une connexion HTTPS entre ArcGIS Web Adaptor et l’organisation, le serveur Web a besoin d’un certificat de serveur. Un certificat est un fichier numérique contenant des informations sur l’identité du serveur Web. Ce certificat contient également la technique de chiffrement à utiliser lors de l’établissement d’un canal sécurisé entre le serveur Web et l’organisation. Il doit être créé par le propriétaire du site Web et signé numériquement. Il existe trois types de certificats : signé par une autorité de certification, de domaine et auto-signé. Ils sont expliqués ci-dessous.

Certificats signés par une autorité de certification

Les certificats signés par une autorité de certification indépendante garantissent aux clients que l’identité du site Web a été vérifiée. Il s’agit généralement d’un tiers de confiance qui peut attester de l’authenticité d’un site Web. Si un site Web est digne de confiance, l’autorité de certification ajoute sa propre signature numérique au certificat auto-signé. Les clients Web ont ainsi la garantie que l’identité du site Web a été vérifiée.

Utilisez les certificats signés par une autorité de certification pour les systèmes de production, en particulier si des utilisateurs extérieurs à votre organisation doivent accéder à votre organisation ArcGIS Enterprise.

Lorsque vous utilisez un certificat émis par une autorité de certification connue, une communication sécurisée entre le serveur et le client Web est établie automatiquement sans qu’aucune action spéciale ne soit requise de la part de l’administrateur de l’organisation ou des clients qui y accèdent. Vous ne remarquez aucun comportement inattendu ou message d’avertissement dans le navigateur Web car le site Web a été vérifié par l’autorité de certification.

Certificats de domaines

Si l’organisation se trouve derrière le pare-feu et que vous ne pouvez pas utiliser de certificat signé par une autorité de certification, utilisez un certificat de domaine. Un certificat de domaine est un certificat interne signé par l’autorité de certification de votre organisation. En utilisant un certificat de domaine, vous pouvez réduire les coûts associés à l’émission de certificats et faciliter leur déploiement, car ils sont générés et approuvés au sein de votre organisation à des fins internes.

Les utilisateurs de votre domaine ne rencontreront aucun comportement inattendu ou message d’avertissement, lesquels sont habituellement associés à un certificat auto-signé, car le site Web a été vérifié par le certificat de domaine. Toutefois, les certificats de domaines ne sont pas validés par une autorité de certification externe. Par conséquent, les utilisateurs qui visitent votre site en dehors de votre domaine ne pourront pas vérifier que votre certificat représente l’entité qu’il prétend représenter. Les utilisateurs externes verront dans le navigateur des avertissements indiquant que le site n’est pas approuvé. Ils pourront alors penser qu’ils communiquent avec une partie malveillante et ne pas visiter votre site.

Certificats auto-signés

Un certificat signé uniquement par le propriétaire du site Web est désigné sous le nom de certificat auto-signé. Ce type de certificat est généralement utilisé sur les sites Web accessibles aux seuls utilisateurs du réseau interne (LAN) de l’organisation. Si vous communiquez avec un site Web en dehors de votre propre réseau qui utilise un certificat auto-signé, vous n’avez aucun moyen de vérifier que le site qui émet le certificat représente la partie qu’il prétend représenter. Vous pourriez très bien communiquer avec une partie malveillante et faire courir un risque à vos données.

La création d’un certificat auto-signé n’est pas une option valide dans un environnement de production, car elle génère des résultats inattendus et une expérience peu satisfaisante pour les utilisateurs de l’organisation.

Lorsque vous configurez l’organisation, vous pouvez utiliser un certificat auto-signé pour procéder à certains tests initiaux qui vous aideront à vérifier que la configuration a abouti. Si vous utilisez un certificat auto-signé, vous vous trouverez dans les cas de figure suivants lors des tests :

• Vous recevrez des avertissements concernant le manque de fiabilité du site si vous accédez à l’organisation à partir d’un navigateur Web ou d’un client bureautique.

  Lorsqu’un navigateur Web décèle un certificat auto-signé, il affiche généralement un avertissement et vous demande de confirmer votre souhait d’accéder au site. De nombreux navigateurs affichent des icônes d’avertissement ou la couleur rouge dans la barre d’adresse tant que vous utilisez le certificat auto-signé. Attendez-vous à voir ces types d’avertissements si vous configurez l’organisation avec un certificat auto-signé.

• Vous ne pouvez pas ouvrir un service fédéré dans une instance Map Viewer, ajouter un élément de service sécurisé à l’organisation, vous connecter à ArcGIS Server Manager sur un serveur fédéré ou vous connecter à l’organisation à partir de ArcGIS for Office.

  Pour être en mesure de vous connecter depuis ArcGIS for Office, installez le certificat auto-signé dans le magasin de certificats Trusted Root Certification Authorities (Autorités de certification racines de confiance) sur la machine exécutant ArcGIS for Office.

• Il se peut que vous rencontriez un comportement inattendu en cas d’impression des services hébergés et d’accès à l’organisation à partir d’applications clientes.

Attention :

La liste ci-dessus des problèmes que vous risquez de rencontrer avec un certificat auto-signé n’est pas exhaustive. Il est conseillé d’utiliser un certificat de domaine ou un certificat signé par une autorité de certification pour tester et déployer entièrement une organisation ArcGIS Enterprise.

Configurer un processus d’écoute HTTPS

La capacité d’une application à écouter sur des ports privilégiés (1 à 1023) est généralement limitée aux processus exécutés par l’utilisateur racine. Vous pouvez éviter d’exécuter le serveur Web en tant qu’utilisateur racine de plusieurs manières. Voici quelques exemples :

• Ajoutez la fonctionnalité CAP_NET_BIND_SERVICE au fichier d’unité de service ou au jeu dans le binaire de l’application.
• Utilisez le paquetage authbind pour autoriser un processus ou jeu de processus à écouter sur un port en particulier.
• Exécutez le processus d’écoute du serveur Web sur un port non privilégié et utilisez les règles de pare-feu pour réacheminer les paquets envoyés aux ports HTTP/HTTPS standard (80/443) vers des ports non privilégiés (par exemple, 8080/8443).

Pour plus d’informations, consultez la documentation de votre serveur Web.

Lorsque vous créez un processus d’écoute HTTPS, l’utilisateur qui exécute le serveur Web requiert l’autorisation d’accéder au certificat de serveur utilisé pour les communications TLS sur le port spécifique. Si le processus d’écoute HTTPS est fonctionnel, mais que le protocole HTTPS n’est pas disponible, le journal du serveur Web indique que la liaison du processus d’écoute au port a échoué.

Tester votre site

Après avoir obtenu ou créé un certificat qui est lié au port 443, configurez votre instance Web Adaptor pour l’utiliser avec l’organisation. Vous devez accéder à la page de configuration de ArcGIS Web Adaptor via une URL HTTPS telle que https://webadaptorhost.domain.com/webadaptorname/webadaptor.

Une fois ArcGIS Web Adaptor configuré, testez le bon fonctionnement du protocole HTTPS en transmettant une requête HTTPS à l’organisation, par exemple https://webadaptorhost.domain.com/webadaptorname/home. Si vous testez le portail avec un certificat auto-signé, ignorez les messages d’avertissement du navigateur concernant les connexions non approuvées. Pour ce faire, vous pouvez ajouter une exception dans votre navigateur afin qu’il vous autorise à communiquer avec le site qui utilise un certificat auto-signé.