test

Guide d'administration système : services IP

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 sur le matériel connecté. Pour plus d'informations sur cette procédure, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation du matériel connecté (liste des tâches).

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

Les certificats autosignés nécessitent un temps système inférieur à celui des certificats publics émanant d'une AC, mais s'intègrent plus difficilement dans un environnement à grande échelle.

  1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

    Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

    Remarque –

    En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

  2. Ajoutez un certificat autosigné à la base de données ike.privatekeys. 


    # ikecert certlocal -ks|-kc -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é.

    -kc

    Crée une demande de certificat. Pour plus d'informations sur cette procédure, reportez-vous à la section Configuration du protocole IKE avec des certificats signés par une AC.

    -m taille de clé

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

    -t type de clé

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

    -D nom distinctif

    Nom distinctif X.509 de l'objet du certificat. Le nom distinctif se présente de la manière suivante : C=pays, O=organisation, OU=unité d'organisation, CN=nom commun. Les balises valides sont C, O, OU et CN.

    -A nom alternatif

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

    -S, début de validité

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

    -F, fin de validité

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

    -T ID de jeton

    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 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/0.
Enabling external key providers - done.
Acquiring private keys for signing - done.
Certificate: 
 Proceeding with the signing operation.
 Certificate generated successfully (…/publickeys/0)
Finished successfully.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. Exécutée sur le système enigma, elle se présente de la manière suivante :


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16
Creating software private keys.
  …
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  3. Enregistrez le certificat et envoyez-le au système distant.

    Vous pouvez le coller dans un e-mail.

    1. Transmettez le certificat de partym à l'administrateur de enigma :


      To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. L'administrateur de enigma vous envoie le certificat enigma suivant :


      To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  4. Sur chaque système, ajoutez le certificat que vous avez reçu.

    1. Copiez la clé publique que l'administrateur vous a envoyée par e-mail.

    2. Saisissez la commande ikecert certdb -a et appuyez sur la touche Retour.

      Aucune invite ne s'affiche lorsque vous appuyez sur la touche Retour.


      # ikecert certdb -a Press the Return key

    3. Collez la clé publique, puis appuyez sur la touche Retour. Pour clore l'entrée, appuyez sur Ctrl-D.


      -----BEGIN X509 CERTIFICATE-----
MIIC…
…
----END X509 CERTIFICATE----- Press the Return key
<Control>-D

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

    Vous pouvez par exemple lui téléphoner et comparer la valeur de hachage de la clé publique. La valeur de hachage de clé publique du certificat partagé doit être identique pour les deux systèmes.

    1. Répertoriez les certificats stockés sur votre système.

      Par exemple, sur le système partym, le certificat public se trouve à l'emplacement 1 et le certificat privé à l'emplacement 0.


      partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-md5 Private Key
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2

Certificate Slot Name: 1   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 0) Points to certificate's private key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

    2. Comparez cette valeur avec le hachage de la clé publique sur le système enigma.

      Vous pouvez communiquer la valeur de hachage par téléphone.


      enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-md5 Private Key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0

Certificate Slot Name: 5   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 4)
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

  6. Approuvez les deux certificats sur chacun des systèmes.

    Éditez 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.

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


      # Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

# Verified remote address and remote ID
# Verified public key hash per telephone call from administrator
cert_trust "192.168.13.213" Local system's certificate Subject Alt Name
cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name

## Parameters that may also show up in rules.

p1_xform 
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 5

{
 label "US-partym to JA-enigmax"
 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 sha1 encr_alg aes}
}

    2. 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. Elle doit différer de la valeur label du système distant.


      …
{
 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
…
Exemple 23–4 Vérification de la validité du certificat d'un autre administrateur

Dans cet exemple, les administrateurs vérifient la concordance des certificats à l'aide de l'attribut Subject Name.

Le premier administrateur enregistre la sortie de la génération et du listage du certificat dans un fichier. La sortie de la commande ikecert s'imprimant en erreur standard, l'administrateur redirige l'erreur standard vers le fichier.


sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

L'administrateur vérifie le contenu du fichier.


sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Ensuite, l'administrateur envoie le fichier par courrier électronique au deuxième administrateur.

Celui-ci place le fichier dans un répertoire sécurisé, puis importe le certificat à partir du fichier.


sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

La commande ikecert importe uniquement le texte entre les lignes -----BEGIN et -----END. L'administrateur vérifie que le certificat local possède une clé de hachage publique identique à celle du fichier co2sys.


sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Le deuxième administrateur s'assure par téléphone que le premier administrateur a bien envoyé ce message électronique et vérifie l'attribut Subject Name du certificat.

Exemple 23–5 Spécification de dates de début et de fin de validité de certificat.

Dans cet exemple, l'administrateur du système partym définit la période de validité du certificat. Le certificat est antidaté de 2,5 jours et sa période de validité est de 4 ans et 6 mois à compter de la date de création.


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

L'administrateur du système enigma définit la période de validité du certificat. Le certificat est antidaté de 2 jours et sa période de validité s'étend jusqu'au 31 décembre 2010, minuit.


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

ProcedureConfiguration du protocole IKE avec des certificats signés par une AC

Les certificats publics émanant d'autorités de certification (AC) 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.

  1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

    Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

    Remarque –

    En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

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

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


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -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-----

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


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -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-----

  3. 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 AC – La signature du fournisseur. L'AC vérifie que votre certificat de clé publique est légitime.

    • Une liste de révocation de certificats (LRC) – 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 LRC est intégré au certificat de clé publique.

      Si un URI de LRC est intégré au certificat de clé publique, IKE peut récupérer automatiquement la LRC. 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 LRC 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 de révocation de certificats.

  4. 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. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

    2. Ajoutez le certificat de clé publique que vous avez reçu du fournisseur de PKI.


      # ikecert certdb -a
Press the Return key
Paste the certificate:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    3. Ajoutez le certificat AC émanant du fournisseur de PKI.


      # ikecert certdb -a
Press the Return key
Paste the CA:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    4. Si le fournisseur de PKI vous a envoyé une liste de révocation de certificats, 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

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

    1. 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 sha1 encr_alg des }
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 sha1 encr_alg aes}
}
      Remarque –

      Tous les arguments du paramètre auth_method doivent se trouver sur la même ligne.

    2. 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
…

  6. Spécifiez le mode de traitement des LRC par le protocole IKE.

    Choisissez l'option appropriée :

    • Pas de LRC disponible

      Si le fournisseur de PKI ne fournit pas de LRC, 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 LRC.

    • LRC disponible

      Si le fournisseur de PKI vous communique un point de distribution central pour les LRC, 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 de révocation de certificats.

Exemple 23–6 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.

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

  2. Sur chacun des systèmes, ajoutez à la base de données publickeys locale le certificat envoyé par e-mail. 


    # ikecert certdb -a
Press the Return key
-----BEGIN X509 CERTIFICATE-----
MII…
-----END X509 CERTIFICATE-----
Press the Return key
<Control>-D

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. Étant 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 :

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

ProcedureGénération et stockage de certificats de clés publiques sur 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

  1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

    Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

    Remarque –

    En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

  2. 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 4000 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 1024 -t rsa-md5 \
> -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 4000 connectée.

    • Pour une demande de certificat, utilisez la syntaxe suivante :


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -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).

  3. Lorsque l'invite demandant le PIN s'affiche, entrez le nom de l'utilisateur de la carte Sun Crypto Accelerator 4000 suivi de deux points et du mot de passe de l'utilisateur.

    Si la carte Sun Crypto Accelerator 4000 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-----

  4. Envoyez votre certificat aux personnes concernées.

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

  5. Éditez 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


# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 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 sha1 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"

# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 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 sha1 encr_alg aes}
}

  6. Placez les certificats de l'autre partie sur le matériel.

    Répondez à la demande de PIN comme lors 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 l'AC.


      # 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 de révocation de certificats (LRC) communiquée par un fournisseur de PKI, reportez-vous à la section Traitement des listes de révocation de certificats.

ProcedureTraitement des listes de révocation de certificats

Les listes de révocation de certificats (LRC) sont émises par une AC et contiennent les certificats périmés ou compromis. Vous pouvez traiter les LRC de quatre façons :

La section ci-dessous décrit la procédure permettant de paramétrer l'utilisation des LRC à partir d'un point de distribution central dans le protocole IKE.

  1. Affichez le certificat que vous avez reçu de l'AC.


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

    spécification de certificat

    Modèle permettant de rechercher les certificats correspondants dans la base de données de certificats IKE.

    Par exemple, le certificat ci-dessous a été émis par Sun Microsystems (les détails ont été modifiés).


    # ikecert certdb -lv example-protect.sun.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
 SerialNumber: 14000D93
   Validity:
      Not Valid Before: 2002 Jul 19th, 21:11:11 GMT
      Not Valid After:  2005 Jul 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.sun.com
      Key Usage: DigitalSignature KeyEncipherment
      [CRITICAL]
   CRL Distribution Points:
      Full Name:
         URI = #Ihttp://www.sun.com/pki/pkismica.crl#i
         DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
      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 LRC de cette organisation est disponible sur le Web. L'entrée DN indique que la LRC est disponible sur un serveur LDAP. Après que le protocole IKE a accédé à la LRC, celle-ci est mise en cache en vue de futures utilisations.

    Pour accéder à la LRC, vous devez tout d'abord accéder à un point de distribution.

  2. Choisissez l'une des méthodes suivantes pour accéder à la LRC 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 un 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.sun.com:389,ldap2.sun.com"
…

    Le protocole IKE récupère la LRC et la met en cache jusqu'à ce que le certificat expire.

Exemple 23–7 Ajout d'une LRC à la base de données certrldb locale

Si la LRC 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 LRC dans un fichier, suivez les instructions du fournisseur de PKI, puis ajoutez la LRC à la base de données à l'aide de la commande ikecert certrldb -a.


# ikecert certrldb -a < Sun.Cert.CRL