Ignorer les liens de navigation | |
Quitter l'aperu | |
Sécurisation du réseau dans Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
1. Utilisation de la protection des liens dans des environnements virtualisés
3. Serveurs Web et protocole SSL (Secure Sockets Layer)
4. IP Filter dans Oracle Solaris (présentation)
6. Architecture IPsec (présentation)
7. Configuration d'IPsec (tâches)
8. Architecture IPsec (référence)
9. Protocole IKE (présentation)
10. Configuration du protocole IKE (tâches)
Affichage des informations IKE
Affichage des groupes et algorithmes disponibles pour les échanges IKE de la phase 1
Configuration du protocole IKE (liste des tâches)
Configuration du protocole IKE avec des clés prépartagées (liste des tâches)
Configuration du protocole IKE avec des clés prépartagées
Configuration du protocole IKE avec des clés prépartagées
Configuration d'IKE pour un nouveau système homologue
Configuration du protocole IKE avec des certificats de clés publiques (liste des tâches)
Configuration du protocole IKE avec des certificats de clés publiques
Configuration du protocole IKE avec des certificats de clés publiques autosignés
Configuration du protocole IKE avec des certificats signés par une CA
Génération et stockage de certificats de clés publiques dans le matériel
Configuration du protocole IKE pour les systèmes portables (liste des tâches)
Configuration du protocole IKE pour les systèmes portables
Configuration du protocole IKE pour les systèmes hors site
Configuration du protocole IKE en vue de l'utilisation du matériel connecté
Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 6000
Grâce aux certificats de clés publiques, les systèmes communicants n'ont plus besoin de partager de numéros de clé secrets hors bande. Contrairement aux clés prépartagées, les certificats de clés publiques peuvent être utilisés sur une machine portable ou sur un système susceptible d'être renuméroté.
Les certificats de clés publiques peuvent également être stockés dans le matériel connecté. Pour la procédure, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation du matériel connecté.
Dans cette procédure, vous créez une paire de certificats. La clé privée est stockée sur le disque, dans la base de données de certificats locale, et peut être référencée par la sous-commande certlocal. La portion publique de la paire de certificats est stockée dans la base de données des certificats publics. Elle peut être référencée par la sous-commande certdb. Vous échangez la portion publique avec un système homologue. La combinaison des deux certificats sert à authentifier les transmissions IKE.
Les certificats autosignés nécessitent un temps système inférieur à celui des certificats publics émanant d'une CA, mais s'intègrent plus difficilement dans un environnement à grande échelle. A la différence des certificats émis par une CA, les certificats autosignés doivent être vérifiés hors bande.
Avant de commencer
Vous devez vous connecter en tant qu'administrateur disposant du profil de droits Network IPsec Management (gestion IPsec du réseau), en plus de l'autorisation solaris.admin.edit/etc/inet/ike/config. Le rôle root dispose de tous ces droits. Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
Si vous vous connectez à distance, exécutez la commande ssh pour que votre connexion soit sécurisée. Reportez-vous à l'Exemple 7-1.
# ikecert certlocal -ks -m keysize -t keytype \ -D dname -A altname \ [-S validity-start-time] [-F validity-end-time] [-T token-ID]
Crée un certificat autosigné.
Taille de la clé. La keysize peut être 512, 1 024, 2 048, 3 072 ou 4 096.
Spécifie le type d'algorithme à utiliser. Le keytype (type de clé) peut être rsa-sha1, rsa-md5 ou dsa-sha1.
Nom distinctif X.509 de l'objet du certificat. dname se présente de la manière suivante : C=country (pays), O=organization (organisation), OU=organizational unit, (unité d'organisation) CN=common name (nom commun). Les balises valides sont C, O, OU et CN.
Nom alternatif du certificat. altname se présente de la manière suivante : tag=value. Les balises valides sont IP, DNS, email et DN.
Indique la date de début de validité absolue ou relative du certificat.
Indique la date de fin de validité absolue ou relative du certificat.
Permet à un jeton matériel PKCS #11 de générer les clés. Les certificats sont alors stockés sur le matériel.
# ikecert certlocal -ks -m 2048 -t rsa-sha1 \ -D "O=exampleco, OU=IT, C=US, CN=partym" \ -A IP=192.168.13.213 Creating private key. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEfdZgKjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T a...+ zBGi4QkNdI3f -----END X509 CERTIFICATE-----
Remarque - Les valeurs des options -D et -A sont arbitraires. Ces valeurs servent uniquement à identifier le certificat. Elles ne permettent pas d'identifier un système, comme 192.168.13.213. Il s'agit en réalité de valeurs idiosyncrasiques, vous devez donc vérifier hors bande que le certificat correct est installé sur les systèmes homologues.
# ikecert certlocal -ks -m 2048 -t rsa-sha1 \ -D "O=exampleco, OU=IT, C=US, CN=enigma" \ -A IP=192.168.116.16 Creating private key. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T ... y85m6LHJYtC6 -----END X509 CERTIFICATE-----
La sortie est une version codée de la portion publique du certificat. Vous pouvez coller en toute sécurité ce certificat dans un e-mail. La partie réceptrice doit vérifier hors bande que le certificat correct est installé, comme indiqué dans l'Étape 4.
To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEfdZgKjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T a...+ zBGi4QkNdI3f -----END X509 CERTIFICATE------
To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: ----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T ... y85m6LHJYtC6 -----END X509 CERTIFICATE-----
# ikecert certdb -a < /tmp/certificate.eml
La commande importe le texte entre les balises BEGIN et END.
Par exemple, vous pouvez téléphoner à l'autre administrateur afin de vérifier que le hachage de son certificat public, que vous possédez, correspond au hachage de son certificat privé, que seul lui possède.
Dans l'exemple suivant, la remarque 1 indique le nom distinctif du certificat dans l'emplacement 0. Le certificat privé de l'emplacement 0 possède le même hachage (reportez-vous à la remarque 3), ces certificats appartiennent donc à la même paire de certificats. Pour que les certificats publics fonctionnent, vous devez posséder une paire correspondante. La sous-commande certdb répertorie la portion publique, tandis que la sous-commande certlocal répertorie la portion privée.
partym # ikecert certdb -l Certificate Slot Name: 0 Key Type: rsa (Private key in certlocal slot 0) Subject Name: <O=exampleco, OU=IT, C=US, CN=partym>Note 1 Key Size: 2048 Public key hash: 80829EC52FC5BA910F4764076C20FDCF Certificate Slot Name: 1 Key Type: rsa (Private key in certlocal slot 1) Subject Name: <O=exampleco, OU=IT, C=US, CN=Ada> Key Size: 2048 Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388 partym # ikecert certlocal -l Local ID Slot Name: 0 Key Type: rsa Key Size: 2048 Public key hash: 80829EC52FC5BA910F4764076C20FDCFNote 3 Local ID Slot Name: 1 Key Type: rsa-sha1 Key Size: 2048 Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388 Local ID Slot Name: 2 Key Type: rsa Key Size: 2048 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818
Cette vérification a permis de confirmer que le système partym possédait une paire de certificats valide.
Vous pouvez communiquer la valeur de hachage par téléphone.
Comparez les hachages de la remarque 3 sur partym indiquée dans l'étape précédente avec la remarque 4 sur enigma.
enigma # ikecert certdb -l Certificate Slot Name: 0 Key Type: rsa (Private key in certlocal slot 0) Subject Name: <O=exampleco, OU=IT, C=US, CN=Ada> Key Size: 2048 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818 Certificate Slot Name: 1 Key Type: rsa (Private key in certlocal slot 1) Subject Name: <O=exampleco, OU=IT, C=US, CN=enigma> Key Size: 2048 Public key hash: FEA65C5387BBF3B2C8F16C019FEBC388 Certificate Slot Name: 2 Key Type: rsa (Private key in certlocal slot 2) Subject Name: <O=exampleco, OU=IT, C=US, CN=partym> Key Size: 2048 Public key hash: 80829EC52FC5BA910F4764076C20FDCFNote 4
Le hachage de clé publique et le nom du sujet du dernier certificat stocké dans la base de données de certificats publics de enigma correspond au certificat privé de partym issu de l'étape précédente.
Editez le fichier /etc/inet/ike/config pour reconnaître les certificats.
L'administrateur du système distant fournit la valeur des paramètres cert_trust, remote_addr et remote_id.
# Explicitly trust the self-signed certs # that we verified out of band. The local certificate # is implicitly trusted because we have access to the private key. cert_trust "O=exampleco, OU=IT, C=US, CN=enigma" # We could also use the Alternate name of the certificate, # if it was created with one. In this example, the Alternate Name # is in the format of an IP address: # cert_trust "192.168.116.16" ## Parameters that may also show up in rules. p1_xform { auth_method preshared oakley_group 5 auth_alg sha256 encr_alg 3des } p2_pfs 5 { label "US-partym to JA-enigmax" local_id_type dn local_id "O=exampleco, OU=IT, C=US, CN=partym" remote_id "O=exampleco, OU=IT, C=US, CN=enigma" local_addr 192.168.13.213 # We could explicitly enter the peer's IP address here, but we don't need # to do this with certificates, so use a wildcard address. The wildcard # allows the remote device to be mobile or behind a NAT box remote_addr 0.0.0.0/0 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes} }
Pour les paramètres distants, utilisez les valeurs de partym. Assurez-vous que la valeur du mot-clé label est unique sur le système local.
… { label "JA-enigmax to US-partym" local_id_type dn local_id "O=exampleco, OU=IT, C=US, CN=enigma" remote_id "O=exampleco, OU=IT, C=US, CN=partym" local_addr 192.168.116.16 remote_addr 0.0.0.0/0 …
partym # svcadm enable ipsec/ike enigma # svcadm enable ipsec/ike
Étapes suivantes
Si vous n'avez pas terminé d'établir la stratégie IPsec, effectuez de nouveau la procédure IPsec pour activer ou actualiser la stratégie IPsec.
Les certificats publics émanant d'autorités de certification (CA) requièrent une négociation avec une organisation externe. Ces certificats s'intègrent très facilement dans les environnements à grande échelle afin protéger un grand nombre de systèmes communicants.
Avant de commencer
Vous devez vous connecter en tant qu'administrateur disposant du profil de droits Network IPsec Management (gestion IPsec du réseau), en plus de l'autorisation solaris.admin.edit/etc/inet/ike/config. Le rôle root dispose de tous ces droits. Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
Si vous vous connectez à distance, exécutez la commande ssh pour que votre connexion soit sécurisée. Reportez-vous à l'Exemple 7-1.
Pour consulter la description des arguments de la commande, reportez-vous à l'Étape 1 de la section Configuration du protocole IKE avec des certificats de clés publiques autosignés.
# ikecert certlocal -kc -m keysize -t keytype \ -D dname -A altname
# ikecert certlocal -kc -m 2048 -t rsa-sha1 \ > -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \ > -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym" Creating software private keys. Writing private key to file /etc/inet/secret/ike.privatekeys/2. Enabling external key providers - done. Certificate Request: Proceeding with the signing operation. Certificate request generated successfully (…/publickeys/0) Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w … lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X -----END CERTIFICATE REQUEST-----
# ikecert certlocal -kc -m 2048 -t rsa-sha1 \ > -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \ > -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax" Creating software private keys. … Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … 8qlqdjaStLGfhDOO -----END CERTIFICATE REQUEST-----
Le fournisseur de PKI vous indiquera la procédure de soumission des demandes de certificat. Dans la plupart des cas, celle-ci s'effectue en remplissant un formulaire directement sur le site Web du fournisseur. Dans ce formulaire, vous devrez notamment indiquer la preuve de la légitimité de votre demande. Il suffit généralement de coller votre demande de certificat dans le formulaire. Après avoir vérifié votre demande, le fournisseur émet les deux objets de certificats suivants et une liste des certificats révoqués :
Votre certificat de clé publique : ce certificat est basé sur la demande que vous avez envoyée au fournisseur. Cette demande est intégrée au certificat, qui vous identifie de manière unique.
Un certificat CA : la signature du fournisseur. La CA vérifie que votre certificat de clé publique est légitime.
Une liste des certificats révoqués (CRL) : la liste la plus récente des certificats révoqués par le fournisseur. Cette liste n'est pas expédiée sous la forme d'un objet de certificat séparé si l'accès à la CRL est intégré au certificat de clé publique.
Si un URI de CRL est intégré au certificat de clé publique, IKE peut récupérer automatiquement la CRL. De la même façon, si une entrée de DN (nom de répertoire sur un serveur LDAP) est intégrée au certificat de clé publique, IKE peut récupérer la CRL sur un serveur LDAP que vous avez spécifié et la mettre en cache.
Pour consulter un exemple d'URI et d'entrée de DN intégrés à un certificat de clé publique, reportez-vous à la section Traitement des listes des certificats révoqués.
L'option -a de la commande ikecert certdb -a ajoute l'objet collé à la base de données de certificats correspondante de votre système. Pour plus d'informations, reportez-vous à la section IKE avec certificats de clés publiques.
Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité. Si vous vous connectez à distance, exécutez la commande ssh pour que votre connexion soit sécurisée. Reportez-vous à l'Exemple 7-1.
# ikecert certdb -a < /tmp/PKIcert.eml
# ikecert certdb -a < /tmp/PKIca.eml
# ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D
Utilisez le nom que le fournisseur de PKI vous a indiqué.
# Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ## Parameters that may also show up in rules. p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha384 encr_alg aes} p2_pfs 2 { label "US-partym to JA-enigmax - Example PKI" local_id_type dn local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes} }
Remarque - Tous les arguments du paramètre auth_method doivent se trouver sur la même ligne.
Le fichier enigma ike/config doit :
Inclure la même valeur cert_root.
Utiliser les valeurs de enigma pour les paramètres locaux.
Utiliser les valeurs de partym pour les paramètres distants.
Créer une valeur unique pour le mot-clé label. Elle doit différer de la valeur label du système distant.
… cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 …
Choisissez l'option appropriée :
Si le fournisseur de PKI ne fournit pas de CRL, ajoutez le mot-clé ignore_crls au fichier ike/config.
# Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,… ignore_crls …
Le mot-clé ignore_crls indique au protocole IKE de ne pas chercher de CRL.
Si le fournisseur de PKI vous communique un point de distribution central pour les CRL, vous pouvez modifier le fichier ike/config de manière à ce qu'il pointe sur cet emplacement.
Pour consulter des exemples de ce type de configuration, reportez-vous à la section Traitement des listes des certificats révoqués.
Exemple 10-2 Utilisation de rsa_encrypt lors de la configuration du protocole IKE
Lorsque vous utilisez auth_method rsa_encrypt dans le fichier ike/config, vous devez ajouter le certificat homologue à la base de données publickeys.
Envoyez ce certificat à l'administrateur du système distant.
Vous pouvez le coller dans un e-mail.
L'administrateur de partym envoie le message suivant :
To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MII… ----END X509 CERTIFICATE-----
L'administrateur de enigma envoie l'e-mail suivant :
To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MII … -----END X509 CERTIFICATE-----
Sur chacun des systèmes, ajoutez à la base de données publickeys locale le certificat envoyé par e-mail.
# ikecert certdb -a < /tmp/saved.cert.eml
En cachant les identités à l'aide du protocole IKE, la méthode d'authentification utilisée en chiffrement RSA prévient les risques d'écoute électronique. Etant donné que la méthode rsa_encrypt cache l'identité de l'homologue, le protocole IKE ne peut récupérer son certificat. La méthode rsa_encrypt requiert donc que les homologues IKE connaissent leurs clés publiques respectives.
C'est pourquoi vous devez ajouter le certificat de l'homologue à la base de données publickeys lorsque vous utilisez la méthode auth_method de rsa_encrypt dans le fichier /etc/inet/ike/config. La base de données publickeys détient alors trois certificats pour chaque couple de systèmes communicants :
Votre certificat de clé publique
Le certificat CA
Le certificat de clé publique de l'homologue
Dépannage la charge du protocole IKE, qui inclut les trois certificats, peut s'avérer trop importante pour le chiffrement via rsa_encrypt. L'apparition d'erreurs indiquant que l'autorisation a échoué ou que la charge n'est pas conforme peut signifier que la méthode rsa_encrypt est incapable de chiffrer la totalité de la charge. Pour réduire la charge, utilisez une autre méthode (par exemple, rsa_sig, qui ne requiert que deux certificats).
Étapes suivantes
Si vous n'avez pas terminé d'établir la stratégie IPsec, effectuez de nouveau la procédure IPsec pour activer ou actualiser la stratégie IPsec.
Le processus de génération et de stockage de certificats de clés publiques sur du matériel est similaire au processus de génération et de stockage de certificats de clés publiques sur un système. Dans le premier cas, il convient d'identifier le matériel à l'aide des commandes ikecert certlocal et ikecert certdb, accompagnées de l'option -T et de l'ID de jeton.
Avant de commencer
Le matériel doit être configuré.
Excepté si le mot-clé pkcs11_path du fichier /etc/inet/ike/config pointe sur une autre bibliothèque, le matériel utilise /usr/lib/libpkcs11.so. Cette bibliothèque doit être implémentée conformément aux standards suivants : RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), c'est-à-dire une bibliothèque PKCS #11.
Pour consulter les instructions de paramétrage, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 6000.
Vous devez vous connecter en tant qu'administrateur disposant du profil de droits Network IPsec Management (gestion IPsec du réseau), en plus de l'autorisation solaris.admin.edit/etc/inet/ike/config. Le rôle root dispose de tous ces droits. Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
Si vous vous connectez à distance, exécutez la commande ssh pour que votre connexion soit sécurisée. Voir l'Exemple 7-1.
Procédez de l'une des manières suivantes :
Remarque - Pour RSA, la carte Sun Crypto Accelerator 6000 prend en charge des clés d'une longueur maximum de 2 048 bits. Pour DSA, la longueur maximum des clés est de 1 024 bits.
# ikecert certlocal -ks -m 2048 -t rsa-sha1 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password
L'argument de l'option -T est l'ID de jeton de la carte Sun Crypto Accelerator 6000 connectée.
# ikecert certlocal -kc -m 2048 -t rsa-sha1 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password
Pour obtenir une description des arguments de la commande ikecert, reportez-vous à la page de manuel ikecert(1M).
Si la carte Sun Crypto Accelerator 6000 possède un utilisateur ikemgr dont le mot de passe est rgm4tigt, entrez :
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
Remarque - La réponse est stockée en texte en clair sur le disque.
Après entrée du mot de passe, le certificat s'imprime :
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt -----BEGIN X509 CERTIFICATE----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … oKUDBbZ9O/pLWYGr -----END X509 CERTIFICATE-----
Procédez de l'une des manières suivantes :
Vous pouvez le coller dans un e-mail.
Pour ce faire, suivez les instructions du fournisseur de PKI. Pour plus d'informations, reportez-vous à l'Étape 2 de la section Configuration du protocole IKE avec des certificats signés par une CA.
Procédez de l'une des manières suivantes :
Utilisez les valeurs fournies par l'administrateur du système distant pour les paramètres cert_trust, remote_id et remote_addr. Sur le système enigma par exemple, le fichier ike/config se présente comme suit :
# Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert cert_trust "192.168.116.16" Local system's certificate Subject Alt Name cert_trust "192.168.13.213" Remote system's certificate Subject Alt name … { label "JA-enigmax to US-partym" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes} }
Entrez le nom que le fournisseur de PKI vous a communiqué comme valeur du mot-clé cert_root. Sur le système enigma par exemple, le fichier ike/config peut se présenter comme suit :
# Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes} }
Répondez à la demande de PIN comme vous l'avez fait au cours de l'Étape 2.
Remarque - Vous devez ajouter les certificats de clés publiques au matériel connecté qui a généré votre clé privée.
Ajoutez le certificat autosigné du système distant. Dans cet exemple, il est stocké dans le fichier DCA.ACCEL.STOR.CERT.
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password
Si le certificat autosigné a utilisé rsa_encrypt comme valeur du paramètre auth_method, ajoutez le certificat de l'homologue au magasin du matériel.
Ajoutez le certificat généré par le fournisseur suite à votre demande et ajoutez la CA.
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password
# ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT Enter PIN for PKCS#11 token: Type user:password
Pour ajouter une liste des certificats révoqués (CRL) communiquée par un fournisseur de PKI, reportez-vous à la section Traitement des listes des certificats révoqués.
Étapes suivantes
Si vous n'avez pas terminé d'établir la stratégie IPsec, effectuez de nouveau la procédure IPsec pour activer ou actualiser la stratégie IPsec.
Les listes des certificats révoqués (CRL) sont émises par une autorité de certification et contiennent les certificats périmés ou compromis. Vous pouvez traiter les CRL de quatre façons :
Vous devez faire en sorte que le protocole IKE ignore les listes des certificats révoqués si votre CA n'en émet pas. Pour plus d'informations, reportez-vous à l'Étape 5 de la section Configuration du protocole IKE avec des certificats signés par une CA.
Vous pouvez faire en sorte que le protocole IKE accède aux CRL à partir d'un URI (uniform resource indicator, identificateur universel de ressources) dont l'adresse est intégrée au certificat de clé publique de la CA.
Vous pouvez faire en sorte que le protocole IKE accède aux CRL à partir d'un serveur LDAP dont l'entrée de nom de répertoire (DN, directory name) est intégrée au certificat de clé publique de la CA.
Vous pouvez traiter les CRL comme des arguments de la commande ikecert certrldb. Pour un exemple, reportez-vous à l'Exemple 10-3.
La section ci-dessous décrit la procédure permettant de paramétrer l'utilisation des CRL à partir d'un point de distribution central dans le protocole IKE.
Avant de commencer
Vous devez vous connecter en tant qu'administrateur disposant du profil de droits Network IPsec Management (gestion IPsec du réseau). Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
# ikecert certdb -lv certspec
Liste les certificats dans la base de données de certificats IKE.
Liste les certificats en mode détaillé. Utilisez cette option avec précaution.
Modèle permettant de rechercher les certificats correspondants dans la base de données de certificats IKE.
Par exemple, le certificat suivant a été émis par Oracle. (les détails ont été modifiés).
# ikecert certdb -lv example-protect.oracle.com Certificate Slot Name: 0 Type: dsa-sha1 (Private key in certlocal slot 0) Subject Name: <O=Oracle, CN=example-protect.oracle.com> Issuer Name: <CN=Oracle CA (Cl B), O=Oracle> SerialNumber: 14000D93 Validity: Not Valid Before: 2011 Sep 19th, 21:11:11 GMT Not Valid After: 2015 Sep 18th, 21:11:11 GMT Public Key Info: Public Modulus (n) (2048 bits): C575A…A5 Public Exponent (e) ( 24 bits): 010001 Extensions: Subject Alternative Names: DNS = example-protect.oracle.com Key Usage: DigitalSignature KeyEncipherment [CRITICAL] CRL Distribution Points: Full Name: URI = #Ihttp://www.oracle.com/pki/pkismica.crl#i DN = <CN=Oracle CA (Cl B), O=Oracle> CRL Issuer: Authority Key ID: Key ID: 4F … 6B SubjectKeyID: A5 … FD Certificate Policies Authority Information Access
Notez l'entrée CRL Distribution Points. L'entrée URI indique que la CRL de cette organisation est disponible sur le Web. L'entrée DN indique que la CRL est disponible sur un serveur LDAP. Après que le protocole IKE a accédé à la CRL, celle-ci est mise en cache en vue de futures utilisations.
Pour accéder à la CRL, vous devez tout d'abord accéder à un point de distribution.
Ajoutez le mot-clé use_http au fichier /etc/inet/ike/config de l'hôte. Le fichier ike/config se présente comme suit :
# Use CRL from organization's URI use_http …
Ajoutez le mot-clé proxy au fichier ike/config. Le mot-clé proxy adopte une URL comme argument, comme indiqué ci-dessous :
# Use own web proxy proxy "http://proxy1:8080"
Utilisez le nom du serveur LDAP comme argument du mot-clé ldap-list dans le fichier /etc/inet/ike/config de l'hôte. Le nom du serveur LDAP est fourni par votre organisation. L'entrée dans le fichier ike/config se présente comme suit :
# Use CRL from organization's LDAP ldap-list "ldap1.oracle.com:389,ldap2.oracle.com" …
Le protocole IKE récupère la CRL et la met en cache jusqu'à ce que le certificat expire.
Exemple 10-3 Ajout d'une CRL à la base de données certrldb locale
Si la CRL du fournisseur de PKI n'est pas disponible à partir d'un point de distribution central, vous pouvez ajouter cette liste manuellement à la base de données certrldb locale. Pour extraire la CRL dans un fichier, suivez les instructions du fournisseur de PKI, puis ajoutez la CRL à la base de données à l'aide de la commande ikecert certrldb -a.
# ikecert certrldb -a < Oracle.Cert.CRL