Authentification IKE (authentification basée sur certificat)
Hiérarchie multiniveau pour l’authentification des certificats
L’authentification basée sur les certificats est une méthode d’authentification prise en charge par les pare-feu SRX Series lors des négociations IKE. Dans les grands réseaux, plusieurs autorités de certification (CA) peuvent émettre des certificats d’entité finale (EE) à leurs appareils finaux respectifs. Il est courant d’avoir des AC distincts pour des sites, des départements ou des organisations individuels.
Lorsqu’une hiérarchie à un seul niveau est utilisée pour l’authentification basée sur les certificats, tous les certificats EE du réseau doivent être signés par le même AC. Tous les pare-feu doivent avoir le même certificat d’AC inscrit pour la validation du certificat homologue. La charge utile de certificat envoyée lors de la négociation IKE ne contient que des certificats EE.
La charge utile de certificat envoyée lors de la négociation IKE peut également contenir une chaîne de certificats EE et AC. Une chaîne de certificats est la liste des certificats requis pour valider le certificat EE d’un pair. La chaîne de certificats comprend le certificat EE et tous les certificats AC qui ne sont pas présents dans l’homologue local.
L’administrateur réseau doit s’assurer que tous les pairs participant à une négociation IKE ont au moins un AC de confiance commun dans leurs chaînes de certificats respectives. L’AC de confiance commune n’a pas besoin d’être l’AC racine. Le nombre de certificats dans la chaîne, y compris les certificats pour les EE et l’AC la plus élevée de la chaîne, ne peut pas dépasser 10.
La validation d’un homologue IKE configuré peut être effectuée avec un serveur AC ou un groupe de serveurs AC spécifiés. Avec les chaînes de certificats, l’AC racine doit correspondre au groupe d’AC ou au serveur d’AC approuvé configuré dans la stratégie IKE.
Dans l’exemple de hiérarchie d’AC illustré à la figure 1, Root-AC est l’AC de confiance commune à tous les appareils du réseau. L’autorité de certification Root-AC délivre des certificats d’AC aux autorités de certification d’ingénierie et de vente, identifiées respectivement comme Eng-AC et Sales-AC. Eng-AC délivre des certificats d’AC aux AC de développement et d’assurance qualité, qui sont identifiés comme Dev-AC et Qa-AC, respectivement. L’hôte A reçoit son certificat EE de Dev-AC, tandis que l’hôte B reçoit son certificat EE de Sales-AC.
certificats
Chaque terminal doit être chargé avec les certificats d’AC dans sa hiérarchie. L’hôte A doit avoir des certificats Root-AC, Eng-AC et Dev-AC ; Les certificats Sales-AC et Qa-AC ne sont pas nécessaires. L’hôte B doit être titulaire de certificats d’AC racine et d’AC de vente. Les certificats peuvent être chargés manuellement dans un appareil ou enrôlés à l’aide du processus simple d’inscription des certificats (SCEP).
Chaque terminal doit être configuré avec un profil d’AC pour chaque AC de la chaîne de certificats. La sortie suivante montre les profils d’AC configurés sur l’hôte A :
admin@host-A# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url “www.example.net/scep/Eng/”;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url “www.example.net/scep/Dev/”;
}
}
}
La sortie suivante montre les profils d’AC configurés sur l’hôte B :
admin@host-B# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Sales-CA {
ca-identity Sales-CA;
enrollment {
url “www.example.net/scep/Sales/”;
}
}
}
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.