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

Quitter la vue de l'impression

Mis à jour : Septembre 2014
 
 

Configuration du protocole IKEv1 avec des certificats signés par une AC

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. Utilisez la commande ikecert certlocal -kc pour créer une demande de signature de certificat (CSR, Certificate signing request).

    Pour consulter la description des arguments de la commande, reportez-vous à l'Step 1 de la section Configuration d'IKEv1 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 un fichier contenant une CSR sur le système partym :
      # ikecert certlocal -kc -m 2048 -t rsa-sha384 \
      > -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 CSR sur le système enigma :
      # ikecert certlocal -kc -m 2048 -t rsa-sha384 \
      > -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-----
  2. CA CSR à un soumettre le.

    L'AC peut vous indiquer comment soumettre la CSR. 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 CSR dans le formulaire. Après avoir vérifié votre demande, le fournisseur émet vous certificats signés. Pour plus d'informations, reportez-vous à Utilisation de certificats de clés publiques dans IKE.

  3. Ajoutez chaque certificat à 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. Connexion en tant qu'administrateur.

      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.

    2. Clé publique et la ajouter le certificat que vous avez reçu de la CA.
      # ikecert certdb -a < /tmp/PKIcert.eml
    3. Ajoutez le certificat public d'CA.

      Vous devrez peut-être également. pour ajouter des certificats intermédiaires

      # ikecert certdb -a < /tmp/PKIca.eml
    4. Si l'AC 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
      Press Control-D
  4. Utilisez le mot-clé cert_root dans le fichier /etc/inet/ike/config pour identifier l'AC qui a émis le certificat.

    Utilisez le nom distinctif (DN) du certificat du CA.

    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 CA
      # This is the X.509 distinguished name for the CA's cert 
      
      cert_root "C=US, O=ExampleCA\, Inc., OU=CA-Example, CN=Example CA"
      
      ## 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-enigma - Example CA"
       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.
    2. Créez un fichier similaire sur le système enigma.

        Spécifiquement, 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=ExampleCA\, Inc., OU=CA-Example, CN=Example CA"
      …
      {
       label "JA-enigma to US-partym - Example CA"
       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
      …
  5. Fixez les stratégies IKEv1 pour la gestion des certificats révoqués.

    Choisissez l'option appropriée :

    • Aucune OCSP disponibles

      Si le certificat de clé publique fournit un URI pour atteindre le serveur OCSP mais que votre système ne peut pas se connecter à Internet, ajoutez le mot-clé ignore_ocsp au fichier ike/config.

      # Trusted root cert
      …
      cert_root "C=US, O=ExampleCA\, Inc., OU=CA-Example,…
      ignore_ocsp

      Le mot-clé ignore_ocsp dit à IKEv1 de partir du principe que le certificat est valide.

    • Pas de CRL disponible

      Si le certificat de clé publique ne fournit pas de source fiable pour les LCR ou si votre système ne peut pas se connecter à Internet pour les récupérer, ajoutez le mot-clé ignore_crls au fichier ike/config.

      # Trusted root cert
      …
      cert_root "C=US, O=ExampleCA\, Inc., OU=CA-Example,…
      ignore_crls
    • Disponible pour les CRL ou OCSP URI

      Si l'AC communique un point de distribution central pour les certificats révoqués, vous pouvez modifier le fichier ike/config de façon à utiliser les URI.

      Pour des exemples, reportez-vous à Gestion des certificats révoqués dans IKEv1.

Exemple 10-2  Utilisation de rsa_encrypt lors de la configuration d'IKEv1

    Lorsque vous utilisez auth_method rsa_encrypt dans le fichier ike/config, vous devez ajouter le certificat du pair à la base de données publickeys.

  1. Envoyez ce certificat à l'administrateur du système distant.

    Vous pouvez le coller dans un e-mail.

    Par exemple, l'administrateur de partym envoie le message suivant :

    To: admin@enigma.ja.example.com
    From: admin@party.us.example.com
    Message: -----BEGIN X509 CERTIFICATE-----
    MII…
    ----END X509 CERTIFICATE-----

    L'administrateur de enigma envoie le message suivant :

    To: admin@party.us.example.com
    From: admin@enigma.ja.example.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 < /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é du pair, IKEv1 ne peut pas récupérer son certificat. La méthode rsa_encrypt requiert donc que les pairs IKEv1 connaissent leurs clés publiques respectives.

    C'est pourquoi vous devez ajouter le certificat du pair à 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

  • La chaîne de certificats CA du

  • Le certificat de clé publique de l'homologue

Dépannage – la charge utile IKEv1, qui comprend au moins trois certificats, peut devenir trop volumineuse pour être chiffrée par 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).

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.