Configuration de l’authentification réciproque

L’authentification mutuelle établit la confiance grâce à l’échange de certificats SSL (Secure Sockets Layer).

Avant de se connecter à un serveur, le client demande un certificat SSL. Le serveur répond en demandant au client d’envoyer son propre certificat. Les deux répondent en validant les certificats et en envoyant des accusés de réception avant d’initier une connexion HTTPS.

Les administrateurs effectuent les tâches préliminaires de configuration d’un magasin de clés et de génération de certificats avant que les demandes de certification ne soient satisfaites.

Avertissement :

Cette fonctionnalité active uniquement l’authentification réciproque sur les connexions https sortantes.

Création du magasin de clés

L’instance prend actuellement en charge le chargement d’un fichier de magasin de clés Java devant contenir la clé privée, la paire de certificats publics et ses certificats signés.

Les étapes suivantes utilisent des commandes qui vous permettent de générer un nouveau fichier de magasin de clés Java Keytool, de créer une demande de signature de certificat (CSR) et d’importer des certificats. Tous les certificats racines ou intermédiaires doivent être importés avant d’importer le certificat principal pour votre domaine. Tapez ces commandes dans une interface de ligne de commande.

1. Générez un magasin de clés Java et une paire de clés.

   keytool -genkey -alias mydomain -keyalg RSA -keystore my.keystore

2. Générez une CSR pour un magasin de clés Java existant.

   keytool -certreq -alias mydomain -keystore my.keystore -file mydomain.csr

3. Importez un certificat d’autorité de certification racine ou intermédiaire dans un magasin de clés Java existant.

   keytool -import -trustcacerts -alias root -file Thawte.crt -keystore my.keystore

4. Importez un certificat primaire signé dans un magasin de clés Java existant.

   keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore my.keystore

Configurer le magasin de clés

Maintenant que le magasin de clés a été créé, il peut être téléchargé dans la table Certificats. Sur le Définition du système > Certificats , cliquez sur Nouveau et définissez les champs suivants :

• Entrez un nom de certificat.
• Stockez le magasin de clés en tant qu’actif.
• Définissez le type = Magasin de clés Java.
• Fournissez un mot de passe de magasin de clés. Il s’agit du mot de passe utilisé pour créer le magasin de clés.

Cliquez sur Envoyer pour créer l’entrée Java Key Store.

Figure 1. Magasin de clés

Spécification d’un certificat de serveur de confiance

Lors d’une connexion SSL sortante, c’est-à-dire un appel de service Web HTTPS, il est possible de spécifier un certificat fourni par le fournisseur de services qui assure la validité du fournisseur de services lors de la connexion SSL. Par exemple, un navigateur qui tente de se connecter à un service sécurisé et qui s’identifie par un certificat.

En téléchargeant le certificat du serveur approuvé, ServiceNow garantit que le service auquel il se connecte est valide et sécurisé.

Créez une nouvelle entrée de certificat avec le type « Trust Store Cert » et joignez un certificat au format DER, ou copiez-collez son format PEM dans le champ Certificat PEM .

Traitement des demandes d’authentification réciproque

Figure 2. Échange de certificats

• Lorsqu’un client demande le certificat du serveur pour l’authentification, une demande de signature de certificat (CSR) est générée.
• Pour répondre à une CSR, le serveur génère deux clés cryptographiques uniques : une clé publique, qui est utilisée pour chiffrer les messages au serveur et une clé privée, qui est utilisée pour déchiffrer les messages. Les deux clés sont conservées dans le magasin de clés.
• Les clés sont utilisées pour déchiffrer les messages sécurisés du client afin qu’ils puissent être lus par le serveur. Toute connexion sortante au format HTTPS vérifie la certification en vérifiant le magasin de clés, en offrant sa certification publique, et utilise les certificats du magasin de clés de confiance pour vérifier la confiance mutuelle.
• Pour compléter le lien sécurisé entre le client et le serveur, le serveur fait correspondre le certificat à la clé privée correspondante. Étant donné que seul le serveur a accès à la clé privée, il peut déchiffrer les données du client.

Voici un exemple de commande qui enregistre MYHTTPS avec l’usine de sockets com.glide.certificates.DBKeyStoreSocketFactory sur le port 443. L’usine de magasins de clés de base de données est utilisée pendant le processus d’échange SSL pour offrir un certificat client pour l’authentification réciproque.

glide.httpclient.protocol.myhttps.class = "com.glide.certificates.DBKeyStoreSocketFactory"
glide.httpclient.protocol.myhttps.port = "443"

Avoir la configuration ci-dessus affecte toute URL de myhttps://host.domain.com/target sortante pour utiliser l’instanciateur de socket personnalisé et échanger des certificats pendant SSL.

Remarque :

Le remplacement de l’instanciateur de sockets du protocole HTTPS par défaut affecte toutes les connexions HTTPS sortantes. Ce n’est généralement pas souhaitable.

Le serveur répond en envoyant un certificat. S’agit-il d’un certificat accepté par le client ? Si c’est le cas, un message est envoyé au serveur acceptant le certificat et un canal sécurisé est lancé. Si le certificat n’est pas accepté, cela peut signifier que l’autorité racine est nécessaire pour la certification.