Configuration de l’authentification réciproque

L’authentification réciproque établit la confiance par l’échange de certificats SSL (Secure Sockets Layer).

Lors de l’établissement de liaison SSL, le serveur présente son certificat au client. Par la suite, en fonction de la configuration du serveur, il peut demander un certificat au client. Le serveur et le client effectuent des procédures de validation des certificats pour garantir l’authenticité et l’intégrité des certificats présentés.

Une fois la validation réussie, les accusés de réception sont échangés avant l’établissement de la connexion HTTPS.

Les administrateurs effectuent le travail préliminaire de configuration du magasin de clés client et de génération des 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 Java Key Store, qui contient une clé privée et une paire de certificats publics. Le certificat public inclut une chaîne complète, y compris le certificat racine.

Pour configurer votre magasin de clés client :

• Vous avez besoin d’un certificat signé par une autorité de certification (CA) de confiance.
• Votre fournisseur de point de terminaison d’API peut vous aider à générer le magasin de clés.

Si vous devez générer le magasin de clés, le processus implique plusieurs étapes à l’aide de commandes de l’interface de ligne de commande pour générer un nouveau fichier du magasin de clés, créer une demande de signature de certificat (CSR) et importer des certificats signés. Avant d’importer le certificat principal de votre domaine, vous devez d’abord importer les certificats racines ou intermédiaires. Voici une instruction étape par étape :

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. Envoyez la CSR à votre autorité de signature de l’autorité de certification pour qu’elle signe et renvoie les fichiers de certificat, qui comprennent les certificats intermédiaires et racine ainsi que le certificat signé.
4. Importez un certificat d'autorité de certification (CA) racine ou intermédiaire dans un magasin de clés Java existant.

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

   Remarque :

   Vous pouvez regrouper tous les certificats dans un seul fichier et les importer. C’est une option préférable. Si vous faites de cette façon, vous pouvez sauter 5

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

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

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

Configuration du 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éfinir 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 du magasin de clés Java.

Figure 1. Magasin de clés

Spécification d’un certificat de serveur de confiance

Lors d’une connexion SSL sortante, qui est un appel de service Web HTTPS, il est possible de spécifier un certificat fourni par le fournisseur de service qui assure la validité du fournisseur de service pendant 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 il s’assure que le service auquel il se connecte est valide et sécurisé.

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

Profil du protocole

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 vers le 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 associe 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 mutuelle.

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

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

Remarque :

Le remplacement de l’usine de sockets de protocole HTTPS par défaut affecte chaque connexion HTTPS sortante. Ce n’est généralement pas souhaitable.

Le serveur répond par l’envoi d’un certificat. S’agit-il d’un certificat accepté par le client ? Si c’est le cas, un message est envoyé au serveur qui accepte 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.