Validation du certificat TLS/SSL

La sécurité de chiffrement TLS/SSL utilise un chiffrement asymétrique, également appelé chiffrement à clé publique. Ce chiffrement utilise deux clés cryptographiques : la clé publique et la clé privée. La clé publique est utilisée pour le chiffrement des données et est visible publiquement. La clé privée est utilisée pour le déchiffrement des données et sa sécurité est essentielle pour en vérifier l’authenticité. Pour plus d’informations sur la préparation de votre réseau, consultez Serveur MID Politique de vérification des certificats TLS/SSL Informations sur la mise à niveau Quebec [KB0867397].

Lors de la validation des certificats TLS/SSL, le MID Server tente de se connecter à un serveur Web sécurisé par un certificat TLS ou SSL. Le serveur Web envoie une copie de son certificat TLS/SSL au MID Server. Le MID Server vérifie l’authenticité du certificat et envoie un message au serveur Web. Le serveur Web répond avec une acceptation signée numériquement pour le lancement d’une session cryptée TLS/SSL. Après quoi, le MID Server peut commencer une communication chiffrée avec le serveur Web.

Validation du nom d’hôte

La vérification du nom d’hôte est une partie du protocole HTTPS qui implique une vérification de l’identité du serveur pour s’assurer que le client parle au serveur correct. Cette vérification empêche l’envoi d’informations à un serveur après avoir été redirigées par une attaque de l’homme du milieu.

La vérification consiste à vérifier que le dnsName du certificat envoyé par le serveur correspond à l’URL utilisée pour effectuer la requête. Selon la RFC 6125, la vérification du nom d’hôte doit être effectuée par rapport au champ dNSName du certificat subjectAlternativeName. Dans certaines implémentations héritées, la vérification est effectuée par rapport au champ commonName du certificat. Si les noms ne correspondent pas, la connexion est interrompue.

Protocole OCSP (Online Certificate Status Protocol)

OCSP implique de contacter le serveur de l’autorité de certification distant et de vérifier le certificat avant que le MID Server ne communique davantage avec le serveur cible. Les certificats compromis peuvent constituer une faille de sécurité, en particulier si ces certificats sont capables de signer d’autres certificats. Si les certificats ont été cassés ou falsifiés, une autorité de certification peut indiquer à un client quels certificats ne sont pas valides et ne doivent pas être utilisés.

Un répondeur OCSP (serveur généralement géré par l’émetteur du certificat) renvoie une réponse signée indiquant que le certificat est « bon », « révoqué » ou « inconnu ». S’il ne peut pas traiter la demande, il peut renvoyer un code d’erreur.

L’émetteur du certificat peut déléguer une autre autorité à titre d’intervenant du PCCO. Cela crée une chaîne de certificats qui doivent être vérifiés. Le certificat de l’intervenant doit être délivré par l’émetteur du certificat en question. Le certificat de l’intervenant doit inclure une certaine extension qui indique qu’il s’agit d’un pouvoir de signature du PCCO.

Politique de sécurité du MID Server

Les politiques de sécurité du MID Server contrôlent l’ensemble du trafic HTTPS provenant du MID Server. Cela inclut les connexions HTTPS du MID Server à un point de terminaison Internet, des URL ServiceNow, des points de terminaison intranet ainsi que des points de terminaison dans le cloud.

Ces connexions peuvent être classées en 4 politiques de sécurité :

Politique de point de terminaison ServiceNow

Cette politique est la valeur système par défaut exclusive pour les URL ServiceNow. Sur la config.xml du MID Server, il existe des propriétés d’amorce qui ne sont utilisées que pour établir la première connexion à l’instance et qui seront mises à jour avec la politique system_default.

Politique d’Internet

Ces politiques couvrent toutes les connexions HTTPS initiées à partir du MID Server vers n’importe quel point de terminaison sur Internet.

Politique intranet

Ces politiques couvrent les sous-réseaux IP réservés, tels que les réseaux auto-hébergés.

Politique remplacée

Vous pouvez remplacer des points de terminaison ou des URL spécifiques par cette définition de politique. Les politiques remplacées prennent l’ordre de priorité le plus élevé pendant l’exploitation.

Les deux tables sont modifiables pour inclure ou exclure des plages d’adresses IP, ainsi que pour contrôler le type de vérifications de validation de certificat à effectuer. Activez toutes les vérifications de validation de certificat pour optimiser la sécurité. Toutes les politiques et vérifications de la version Quebec sont activées par défaut pour les nouvelles installations.

Pour les points de terminaison qui hébergent un certificat autosigné, importez le certificat dans le magasin de confiance du MID Server ou désactivez les vérifications de politique qui valident cet hôte. Pour plus d’informations sur l’ajout de certificats, reportez-vous à Ajouter des certificats SSL pour le serveur MID.

Après la mise à niveau vers Quebec, accédez à la table des politiques de vérification des certificats et apportez des modifications à la configuration de la politique si nécessaire. Une fois que le MID Server démarre et se connecte à l’instance, toute connexion HTTPS suivante provenant du MID Server commence à appliquer ces vérifications de certificat lors de l’exécution. Les connexions non sécurisées sont interrompues avec des messages d’erreur appropriés.

Utiliser la politique de sécurité d’instance

Le paramètre de configuration du MID Server mid.ssl.use.instance.security.policy détermine si le MID Server utilise ses paramètres d’amorce plutôt que la politique de sécurité de l’instance. Par défaut, mid.ssl.use.instance.security.policy est définie sur faux dans la config.xml afin que les politiques d’amorce ne soient pas remplacées par celles de l’instance.

Ce paramètre par défaut peut éviter certains problèmes lors de la configuration du MID Server. Par exemple, si l’hôte n’est pas en mesure de joindre le répondeur OCSP, une nouvelle installation de MID Server n’est pas perturbée par la politique d’une instance exigeant une connexion OCSP.

Le paramètre de configuration mid.ssl.use.instance.security.policy peut être défini pour chaque MID Server. Lorsque la valeur est définie sur true, le MID Server synchronise toutes les politiques avec l’instance et les paramètres de configuration d’amorce sont remplacés par la politique *.servicenow.com sur la table de mid_cert_check_policy d’instance. Les stratégies finales mettent à jour la carte de politiques dans la mémoire du MID Server ainsi que le config.xml.

Les instances auto-hébergées ou sur site doivent ajouter le paramètre suivant pour le config.xml : <parameter name="mid.ssl.bootstrap.default.target_endpoint » value="FQDN_OF_THE_INSTANCE"/>