Configuration du protocole IKE avec des certificats de clés publiques

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é.

Configuration du protocole IKE avec des certificats de clés publiques autosignés

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.

Connectez-vous en tant qu'administrateur.
Pour plus d'informations, reportez-vous à la section Procédure d’obtention des droits d’administration du manuel Administration d’Oracle Solaris : 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 15-1.
Créez un certificat autosigné dans la base de données ike.privatekeys.
```
# ikecert certlocal -ks -m keysize -t keytype \
-D dname -A altname \
[-S validity-start-time] [-F validity-end-time] [-T token-ID]
```
-ks

Crée un certificat autosigné.

-m keysize

Taille de la clé. La keysize peut être 512, 1 024, 2 048, 3 072 ou 4 096.

-t keytype

Spécifie le type d'algorithme à utiliser. Le keytype (type de clé) peut être rsa-sha1, rsa-md5 ou dsa-sha1.

-D dname

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.

-A altname

Nom alternatif du certificat. altname se présente de la manière suivante : tag=value. Les balises valides sont IP, DNS, email et DN.

-S, validity-start-time

Indique la date de début de validité absolue ou relative du certificat.

-F, validity-end-time

Indique la date de fin de validité absolue ou relative du certificat.

-T token-ID

Permet à un jeton matériel PKCS #11 de générer les clés. Les certificats sont alors stockés sur le matériel.
1. Exécutée par exemple sur le système partym, la commande se présente comme suit :
```
# 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.
2. Exécutée sur le système enigma, elle se présente de la manière suivante :
```
# 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-----
```
Enregistrez le certificat et envoyez-le au système distant.
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 b.
1. Par exemple, vous transmettez la portion publique du certificat partym à l'administrateur de enigma.
```
To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIIC1TCCAb2gAwIBAgIEfdZgKjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T
a...+
zBGi4QkNdI3f
-----END X509 CERTIFICATE------
```
2. L'administrateur de enigma vous transmet la portion publique du certificat enigma.
```
To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: ----BEGIN X509 CERTIFICATE-----
MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T
...
y85m6LHJYtC6
-----END X509 CERTIFICATE-----
```
Sur chaque système, ajoutez le certificat que vous avez reçu à la base de données de clés publiques.
1. Enregistrez l'e-mail de l'administrateur dans un fichier lisible par root.
2. Redirigez le fichier vers la commande ikecert.
```
# ikecert certdb -a < /tmp/certificate.eml 
```
  La commande importe le texte entre les balises BEGIN et END.

Vérifiez auprès de l'autre administrateur que ce certificat est bien de lui.

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.

Répertoriez les certificats stockés sur partym.

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, 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.

Vérifiez que le système enigma possède le certificat public de partym.

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 hachage du certificat privé de partym issu de l'étape précédente.

Approuvez les deux certificats sur chacun des systèmes.

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.

Sur le système partym par exemple, le fichier ike/config se présente de la manière suivante :

# 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}
}

Sur le système enigma, ajoutez les valeurs de enigma des paramètres locaux dans le fichier ike/config.
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
…
```

Sur les systèmes homologues, activez IKE.

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.

Configuration du protocole IKE avec des certificats signés par une CA

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.

Connectez-vous en tant qu'administrateur.
Pour plus d'informations, reportez-vous à la section Procédure d’obtention des droits d’administration du manuel Administration d’Oracle Solaris : 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 15-1.

La commande ikecert certlocal -kc permet de créer une demande de certificat.

Pour consulter la description des arguments de cette commande, reportez-vous à l'Étape b 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

La commande suivante permet par exemple de créer une demande de certificats sur le système partym :

# 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-----

La commande suivante permet de créer une demande de certificat sur le système enigma :

# 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-----

Soumettez la demande de certificat à un fournisseur de PKI.
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 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.
Ajoutez tous les certificats sur votre système.
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.
1. Connectez-vous en tant qu'administrateur.
  Pour plus d'informations, reportez-vous à la section Procédure d’obtention des droits d’administration du manuel Administration d’Oracle Solaris : 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 15-1.
2. Ajoutez le certificat de clé publique que vous avez reçu du fournisseur de PKI.
```
# ikecert certdb -a < /tmp/PKIcert.eml
```
3. Ajoutez le certificat CA émanant du fournisseur de PKI.
```
# ikecert certdb -a < /tmp/PKIca.eml
```
4. Si le fournisseur de PKI vous a envoyé une liste des certificats révoqués, ajoutez-la à la base de données certrldb :
```
# ikecert certrldb -a
Press the Return key
Paste the CRL:
-----BEGIN CRL----- … -----END CRL----
Press the Return key
<Control>-D
```

Le mot-clé cert_root permet d'identifier le fournisseur de PKI dans le fichier /etc/inet/ike/config.

Utilisez le nom que le fournisseur de PKI vous a indiqué.

Sur le système partym, par exemple, le fichier ike/config peut se présenter de la manière suivante :

# 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.

Créez un fichier similaire sur le système enigma.
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
…
```

Spécifiez le mode de traitement des CRL par le protocole IKE.
Choisissez l'option appropriée :
- Pas de CRL disponible
  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.
- CRL disponible
  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 18-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.

Génération et stockage de certificats de clés publiques dans le matériel

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.

Connectez-vous en tant qu'administrateur.
Pour plus d'informations, reportez-vous à la section Procédure d’obtention des droits d’administration du manuel Administration d’Oracle Solaris : 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 15-1.
Générez un certificat autosigné ou une demande de certificat et spécifiez l'ID de jeton.
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.
- Pour un certificat autosigné, utilisez la syntaxe suivante :
```
# 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.
- Pour une demande de certificat, utilisez la syntaxe suivante :
```
# 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).
Lorsque vous êtes invité à saisir le PIN, entrez le nom de l'utilisateur de la carte Sun Crypto Accelerator 6000 suivi de deux-points et du mot de passe de l'utilisateur.
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-----
```
Envoyez votre certificat aux personnes concernées.
Procédez de l'une des manières suivantes :
- Envoyez le certificat autosigné au système distant.
  Vous pouvez le coller dans un e-mail.
- Envoyez la demande de certificat à un fournisseur de PKI.
  Pour ce faire, suivez les instructions du fournisseur de PKI. Pour plus d'informations, reportez-vous à l'Étape 3 de la section Configuration du protocole IKE avec des certificats signés par une CA.

Editez le fichier /etc/inet/ike/config sur votre système pour reconnaître les certificats.

Procédez de l'une des manières suivantes :

Certificat autosigné

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}
}

Demande de certificat

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}
}

Placez les certificats de l'autre partie sur le matériel.
Répondez à la demande de PIN comme vous l'avez fait au cours de l'Étape 3.

Remarque - Vous devez ajouter les certificats de clés publiques au matériel connecté qui a généré votre clé privée.
- Certificat autosigné.
  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.
- Certificats émanant d'un fournisseur de PKI.
  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.

Traitement des listes des certificats révoqués

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 6 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. Voir l'Exemple 18-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.

Affichez le certificat que vous avez reçu de la CA.

# ikecert certdb -lv certspec

-l: Liste les certificats dans la base de données de certificats IKE.
-v: Liste les certificats en mode détaillé. Utilisez cette option avec précaution.
certspec: 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.

Choisissez l'une des méthodes suivantes pour accéder à la CRL depuis un point de distribution central.
- Utilisez l'URI.
  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
…
```
- Utilisez un proxy Web.
  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 un serveur LDAP.
  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 18-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

Ignorer les liens de navigation
Quitter l'aperu
	Administration d'Oracle Solaris : Services IP Oracle Solaris 11 Information Library (Français)