---
sourceDocument: Options de la plateforme d’IA ServiceNow de Yokohama
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/yokohama/servicenow-platform

 Release :

    - yokohama

ft:locale :

    - fr-FR

ft:publication_title :

    - Options de la plateforme d’IA ServiceNow de Yokohama

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Politiques de vérification des certificats de Serveur MID

# Politiques de vérification des certificats de Serveur MID {#ariaid-title1}

* Rversion finale: Yokohama
* 
* Mis à jour 30 janv. 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 minutes de lecture

Le serveur MID utilise trois types de contrôles de sécurité pour sécuriser le trafic externe. Les contrôles de sécurité utilisent la validation des certificats TLS/SSL, la validation du nom d'hôte et la validation OCSP pour améliorer la sécurité. Contrôlez ces contrôles de sécurité avec la table Politiques de vérification des certificats de Serveur MID.

|-|
|   |
[ ]

{#mid-security-checks__table_m2t_cv4_nhb}

## Validation du certificat TLS/SSL {#mid-security-checks__section_w5g_d2n_mnb}

La sécurité du chiffrement TLS/SSL utilise le 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 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 du Québec \[KB0867397\]](https://support.servicenow.com/kb_view.do?sysparm_article=KB0867397).

Lors de la validation d'un certificat TLS/SSL, le serveur MID 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 serveur MID. Le serveur MID vérifie l'authenticité du certificat et envoie un message au serveur Web. Le serveur Web répond par une acceptation signée numériquement pour l'initiation d'une session chiffrée TLS/SSL. Le serveur MID peut ensuite commencer à chiffrer la communication avec le serveur Web.

## Validation du nom d'hôte {#mid-security-checks__section_kdd_12n_mnb}

La vérification du nom d'hôte est une partie de HTTPS qui implique une vérification de l'identité du serveur pour s'assurer que le client parle au bon serveur. Cette vérification empêche l'envoi d'informations à un serveur après avoir été redirigé 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 demande. 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.  
Remarque :  
La validation du nom d'hôte dérive le nom d'hôte du certificat validé présenté par le serveur. Par conséquent, la validation du certificat TLS est une condition préalable à la validation du nom d'hôte.

## Protocole OCSP (Online Certificate Status Protocol) {#mid-security-checks__section_zht_c2n_mnb}

OCSP implique de contacter le serveur de l'autorité de certification distant et de vérifier le certificat avant que le serveur MID ne communique davantage avec le serveur cible. Les certificats compromis peuvent constituer une vulnérabilité de sécurité, surtout si ces certificats ont la capacité de signer d'autres certificats. Si les certificats ont été cassés ou falsifiés, une autorité de certification peut informer un client des certificats invalides et ne doivent pas être utilisés.

Un répondeur OCSP (un 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é en tant que répondeur OCSP. Cela crée une chaîne de certificats qui doivent être vérifiés. Le certificat du répondant doit être délivré par l'émetteur du certificat en question. Le certificat de l'intervenant doit inclure une certaine extension qui le marque comme un pouvoir de signature OCSP.  
Remarque :  
Les vérifications OCSP sont des appels HTTP secondaires effectués vers un répondeur OCSP. L'appel principal peut interrompre la connexion en fonction de la réponse du répondeur OCSP.

## Politique de sécurité du serveur MID {#mid-security-checks__section_q4l_qws_snb}

Les politiques de sécurité du serveur MID contrôlent l'ensemble du trafic HTTPS provenant du serveur MID. Cela inclut les connexions HTTPS du serveur MID à un point de terminaison Internet, les URL ServiceNow, les points de terminaison intranet, ainsi que les points de terminaison 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 exclusivement pour les URL ServiceNow. Sur la config.xml du serveur MID, il existe des propriétés d'amorce qui ne sont utilisées que pour établir une première connexion à l'instance et qui sont mises à jour avec la stratégie de system_default.

Politique Internet
:   Ces politiques couvrent toutes les connexions HTTPS initiées à partir d'un serveur MID vers n'importe quel point de terminaison sur Internet.

Politique intranet
:   Ces stratégies couvrent les sous-réseaux IP réservés, tels que les réseaux auto-hébergés.

Politique de remplacement
:   Vous pouvez remplacer des points de terminaison ou des URL spécifiques avec cette définition de politique. Les politiques remplacées occupent l'ordre de priorité le plus élevé pendant l'exploitation.

Les deux tables sont modifiables pour inclure ou exclure des plages IP et contrôlent le type de vérifications de validation de certificat à effectuer. Activez tous les contrôles de validation de certificat pour maximiser la sécurité. La version québécoise active toutes les politiques et vérifications par défaut pour les nouvelles installations.  
Pour la mise à niveau des clients, les contrôles de validation de certificat sont désactivés par défaut dans la stratégie intranet. Pour améliorer la sécurité, configurez et activez la politique pour les points de terminaison au sein du réseau interne.  
Remarque :  
Les points de terminaison internes ou les URL doivent posséder un certificat valide signé par l'autorité de certification pour une connexion réussie.

Pour les points de terminaison qui hébergent un certificat auto-signé, importez le certificat dans le magasin de clés de confiance du serveur MID ou désactivez les contrôles de politique qui valident cet hôte. Pour plus d'informations sur l'ajout de certificats, reportez-vous à la section [Ajouter des certificats SSL pour le serveur MID](https://servicenow-prod.fluidtopics.net/KnDhe_BkYE2nyTJsjGY~5g#add-ssl-certificates "Configurez le serveur MID pour vous connecter à une source via SSL.").

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

## Utiliser la politique de sécurité de l'instance {#mid-security-checks__section_vgp_nps_dwb}

Le paramètre de configuration du serveur MID mid.ssl.use.instance.security.policy contrôle si le serveur MID 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 false 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 permet d'éviter certains problèmes lors de la configuration du serveur MID. Par exemple, si l'hôte ne parvient pas à joindre le répondeur OCSP, l'installation d'un nouveau serveur MID n'est pas perturbée par la politique d'une instance qui exige une connexion OCSP.

Le paramètre de configuration mid.ssl.use.instance.security.policy peut être défini pour chaque serveur MID. Lorsque la valeur est définie sur vrai, le serveur MID 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 mid_cert_check_policy d'instance. Les politiques finales mettent à jour la carte de stratégie dans la mémoire du serveur MID ainsi que le config.xml.  
Les paramètres par défaut du config.xml sont les suivants :

* `<nom du paramètre="mid.ssl.bootstrap.default.check_cert_hostname >> value="true"/>`
* `<nom du paramètre="mid.ssl.bootstrap.default.check_cert_chain >> value="true"/>`
* `<nom du paramètre="mid.ssl.bootstrap.default.check_cert_revocation >> value="false"/>`
* `<nom du paramètre="mid.ssl.use.instance.security.policy >> value="false"/>`
{#mid-security-checks__ul_wv5_1zx_2wb}

Les instances auto-hébergées ou sur site doivent ajouter le paramètre suivant pour le config.xml : `<nom du paramètre="mid.ssl.bootstrap.default.target_endpoint >> value="FQDN_OF_THE_INSTANCE"/>`
**Concepts associés**   

* [Informations d'identification d'authentification du serveur MID et demandes SOAP](https://servicenow-prod.fluidtopics.net/dIXun15wZVfGj0sWkOStpw#mid-authentication-soap-requests "Définissez les informations d’identification d’authentification de base pour mettre à jour les données d’invocation du service web. Pour plus de sécurité, vous pouvez appliquer l’authentification de base à chaque demande SOAP entrante vers le serveur MID.")
* [Magasin de clés unifié du serveur MID](https://servicenow-prod.fluidtopics.net/eHKsHQMDW6TDcavcwVtGvA#mid-unified-keystore "Le magasin de clés unifié du serveur MID permet à tous les produits sur le serveur MID d’utiliser des certificats et des paires de clés communs. Cette fonctionnalité permet aux applications d’utiliser le même canal de communication sécurisée vers le serveur MID que celui utilisé par le serveur MID pour se connecter à l’instance.")
* [Serveur MID Journal d'audit de commande](https://servicenow-prod.fluidtopics.net/aGBuY8P3tJIpG01C0OnEHg "Le journal d’audit des commandes enregistre les commandes exécutées par pour Serveur MID l’application Découverte . Examinez les commandes pour vérifier s’il y a des anomalies ou des erreurs.")
* [Mode FIPS appliqué du serveur MID](https://servicenow-prod.fluidtopics.net/xly0FzzUTaeJEPzVgN6D7g#mid-fips-enforced "Le serveur MID prend en charge l’environnement NSC (National Security Cloud) IL-5, qui exige que toutes les cryptoographies utilisées soient validées par FIPS. Le serveur MID peut être exécuté en mode FIPS appliqué, où seuls les algorithmes de chiffrement validés par FIPS sont utilisés.")
* [Gouvernance de serveur MID](https://servicenow-prod.fluidtopics.net/ke9Asb~0l6JC_bOAPlkcKw "Améliorez Serveur MID la sécurité en définissant un délai d’expiration automatique pour invalider et arrêter inactif Serveurs MID. Vous pouvez activer cette fonctionnalité et définir le délai d’expiration d’inactivité globalement et pour chaque Serveur MID.")  
**Tâches associées**   

* [Chiffrer ou déchiffrer les valeurs des fichiers de configuration de serveur MID](https://servicenow-prod.fluidtopics.net/Q1u2WTPTqkAJV8UTwSLqvw "La valeur de n’importe quel paramètre du serveur MID dans le fichier config.xml peut être chiffrée. Les attributs de toutes les valeurs chiffrées sont gérés à partir du fichier de configuration, y compris l’attribut de sécurité du mot de passe de connexion.")
* [Activer l'authentification réciproque du serveur MID](https://servicenow-prod.fluidtopics.net/03OdSt4nj4brVrQM6a5zEQ "Configurez le serveur MID de sorte qu’il utilise un certificat client pour s’authentifier auprès de l’instance. Cela évite d’avoir à créer des informations d’identification d’authentification de base dans le magasin de clés pour la configuration du serveur MID.")
* [Serveur MID : intégration de Azure Key Vault](https://servicenow-prod.fluidtopics.net/1erp7~RUWTszwcPJMyoE7A#mid_azure_key_vault_integration "L’intégration du serveur MID au coffre-fort de clés Azure permet à Orchestration, Découverte et Mappage des services de s’exécuter sans stocker d’informations d’identification sur l’instance.")
* [Retapez la clé d'un serveur MID](https://servicenow-prod.fluidtopics.net/U2m_FmrgVh5jAO1nrY8Ypg "Retapez la clé d’un serveur MID pour générer une nouvelle clé privée. Les clés privées sont utilisées pour déchiffrer les informations d’identification permettant aux serveurs MID de transmettre des informations en toute sécurité. Les paires de clés sont initialement générées lorsqu’un serveur MID est validé, et la saisie des serveurs MID doit être renouvelée périodiquement pour répondre aux exigences de sécurité.")
* [Ajouter des certificats SSL pour le serveur MID](https://servicenow-prod.fluidtopics.net/KnDhe_BkYE2nyTJsjGY~5g#add-ssl-certificates "Configurez le serveur MID pour vous connecter à une source via SSL.")
* [Joindre un fichier de script à un fichier synchronisé Serveur MID](https://servicenow-prod.fluidtopics.net/CsmvsPWrNFSP7LUAM3uTvg#mid-server-script-attach "Vous pouvez joindre un fichier de script à synchroniser avec un serveur MID connecté. Windows La sécurité renforcée d’Internet Explorer bloque les fichiers téléchargés qu’elle juge potentiellement dangereux. Cependant, la synchronisation des fichiers permet d’éviter ce problème de sécurité.")  
**Référence associée**   

* [Sécurité du fichier de configuration de serveur MID](https://servicenow-prod.fluidtopics.net/5JlufBa7tOlcfvwvToefSQ "Les données sensibles de configuration de serveur MID peuvent être protégées à l’aide de plusieurs schémas différents, notamment le chiffrement des données internes et externes et le stockage des données externes.")
* [Algorithmes de chiffrement SSH de serveur MID](https://servicenow-prod.fluidtopics.net/2DWkoEtbbHIaQrOnLsLZ1A "Le serveur MID utilise des clients SSH pour effectuer de nombreuses actions de découverte. Au cours de l’établissement de liaison SSH, le client et le serveur déterminent d’abord les algorithmes pris en charge par les deux parties, puis le client choisit l’algorithme de priorité la plus élevée. Pour l’algorithme de clé d’hôte, le client choisit l’algorithme de priorité la plus élevée pris en charge par les deux parties qui correspond au type de clé.")

