Sécurisation du réseau dans Oracle® Solaris 11.2

Quitter la vue de l'impression

Mis à jour : Septembre 2014
 
 

Configuration d'IKEv1 avec des certificats de clés publiques autosignés

Dans cette procédure, vous créez une clé publique ou privée et un certificat, c'est ce l'on appelle 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 commande ikecert certlocal. La clé publique et le certificat est stocké dans la base de données des certificats publics. Elle peut être référencée par la commande ikecert certdb. Vous échangez le certificat public avec un système homologue. Les deux les certificats permettent d'authentifier les transmissions IKEv1.

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. La différence des certificats émis par une CA, les certificats autosignés doivent être vérifiés aux administrateurs qui échangés par les deux les certificats.

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 A l’aide de vos droits administratifs attribués du manuel Sécurisation des utilisateurs et des processus dans Oracle Solaris 11.2 .

Si vous administrez à distance, reportez-vous à l'Example 7–1 et à Administration à distance de ZFS avec le shell sécurisé du manuel Gestion de l’accès au shell sécurisé dans Oracle Solaris 11.2 pour des instructions sur la connexion à distance sécurisée.

  1. Sur chaque système IKEv1, créez un certificat autosigné dans la base de données ike.privatekeys.

    Pour les arguments de la commande ikecert certlocal, reportez-vous à la page de manuel ikecert(1M).

    1. Par exemple, la commande du système partym apparaîtrait comme suit :
      # ikecert certlocal -ks -m 2048 -t rsa-sha512 \
      -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-----

      avec

      –ks

      Crée un certificat autosigné.

      –m keysize

      Indique la taille de la clé.

      –t keytype

      Spécifie le type d'algorithme à utiliser.

      –D dname

      Spécifie le nom distinctif (ND) X.509 pour le sujet du certificat. Pour un exemple, reportez-vous à Utilisation de certificats de clés publiques dans IKE.

      –A altname

      Nom ou un pseudonyme en spécifie l'du certificat. altname se présente de la manière suivante : tag=value. Les balises valides sont IP, DNS, email et DN.


      Remarque -  Les valeurs des options –D et –A sont des noms qui identifient uniquement le certificat, et non un système, tel que 192.168.13.213. Il s'agit en réalité de surnoms de certificats, vous devez donc vérifier hors bande que le certificat correct est installé sur les systèmes homologues.
    2. La commande sur le système enigma se présenterait de la manière suivante :
      # ikecert certlocal -ks -m 2048 -t rsa-sha512 \
      -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-----
  2. 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é à l'Step 4.

    1. Par exemple, vous transmettez la portion publique du certificat partym à l'administrateur de enigma.
      To: admin@enigma.ja.example.com
      From: admin@party.us.example.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@party.us.example.com
      From: admin@enigma.ja.example.com
      Message: ----BEGIN X509 CERTIFICATE-----
      MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T
      ...
      y85m6LHJYtC6
      -----END X509 CERTIFICATE-----
  3. Sur chaque système, ajoutez le certificat reçu à la base de données des 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.

  4. Assurez-vous 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.

    1. Listez le certificat enregistré sur partym.

      Dans l'exemple suivant, la remarque 1 indique le nom distinctif (ND) 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-sha512
              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.

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

  5. Sur chaque système, faites confiance aux deux certificats.

    Editez le fichier /etc/inet/ike/config pour reconnaître les certificats.

    L'administrateur du système distant fournit les valeurs 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 comme suit :
      # 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-enigma"
       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}
      }
    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 sur le système local.

      …
      {
       label "JA-enigma 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
      
       p1_xform
        {auth_method rsa_sig oakley_group 2 auth_alg sha256 encr_alg aes}
      }
  6. Sur les systèmes homologues, activez IKEv1.
    partym # svcadm enable ipsec/ike:default
    enigma # svcadm enable ipsec/ike

Etapes 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. Pour obtenir des exemples de la stratégie IPsec de protection de VPN, reportez-vous à Protection d'un VPN à l'aide d'IPsec. Pour plus d'exemples de la stratégie IPsec, reportez-vous à la section Sécurisation du trafic entre deux serveurs réseau à l'aide d'IPsec.