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

Quitter la vue de l'impression

 
Mis à jour : Septembre 2014
 
 

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

Dans cette procédure, vous créez et signez un certificat de clé publique. La clé privée et le certificat sont stockés dans le keystore de jeton logiciel PKCS #11 pour IKEv2. Vous envoyez le certificat de clé publique aux homologues IKE, qui, à leur tour, vous envoient leur certificat public.

Vous effectuez cette procédure sur tous les systèmes utilisant IKE les certificats auto-signés .

Avant de commencer

Pour utiliser les certificats, vous devez avoir effectué la Création et utilisation d'un keystore pour les certificats de clés publiques IKEv2.

Vous devez vous connecter en tant qu'administrateur disposant du profil de droits Network IPsec Management (gestion IPsec du réseau). Vous devez utiliser un shell de profil. 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. Créez un certificat autosigné dans le keystore.

    Pour obtenir une description des arguments de la commande ikev2cert gencert, vérifiez la sous-commande pktool gencert keystore=pkcs11 de la page de manuel pktool(1).

    Pour le format de l'argument subject, reportez-vous à Utilisation de certificats de clés publiques dans IKE.

    Remarque -  Donnez une étiquette au certificat. L'étiquette identifie le certificat, ainsi que ses keystore des clés correspondantes dans les fichiers locaux.
    1. Par exemple, la commande du système partym apparaîtrait comme suit : 
      # pfbash
	# ikev2cert gencert \
	label="ITpartym" \
	subject="O=exampleco, OU=IT, C=US, CN=partym" \
	serial=0x87654321
    keytype=rsa
    keylen=2048
	Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx

      Les messages d'erreur suivants indiquent un code PIN contenant une faute de frappe ou un keystore non initialisé :

      Error creating certificate and keypair:
	keystore error: CKR_PIN_INCORRECT
	libkmf error: KMF_ERR_AUTH_FAILED

	Error creating certificate and keypair:
	keystore error: CKR_PIN_EXPIRED: PIN expired and must be changed
	libkmf error: KMF_ERR_BAD_PARAMETER: invalid parameter
      Conseil  -  Un affichage de la syntaxe de la commande pktool indique qu'une partie de votre certificat est mal saisie. , reportez-vous à l'utilisation d'une commande non-schéma ne sont pas autorisés pour le, les guillemets et algorithme de signes égal manquant, ainsi que d'autres des erreurs typographiques. Une stratégie est pour localiser l'argument non valide, puis pour extraire les enlever un argument de commande, l'un après l'autre.
    2. La commande sur le système enigma se présenterait de la manière suivante : 
      # ikev2cert gencert \
	label=ITenigma \
	subject="O=exampleco, OU=IT, C=US, CN=enigma" \
	serial=0x86428642
    keytype=rsa
    keylen=2048
	Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx
  2. (Facultatif) Listez les clés et le certificat. 
    enigma # /usr/sbin/ikev2cert list objtype=both
	Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx
	No.     Key Type        Key Len.        Key Label
	----------------------------------------------------
	Asymmetric private keys:
	1)      RSA                             ITenigma
	Asymmetric public keys:
	1)      RSA                             ITenigma
	Certificates:
	1) X.509 certificate
		Label: ITenigma
		Subject: C=US, O=exampleco, OU=IT, CN=enigma
		Issuer: C=US, O=exampleco, OU=IT, CN=enigma
		Not Before: April 10 21:49:00 2014 GMT
		Not After: April 10 21:49:00 2015 GMT
		Serial: 0x86426420
		Signature Algorithm: sha1WithRSAEncryption
		X509v3 Subject Key Identifier:
			34:7a:3b:36:c7:7d:4f:60:ed:ec:4a:96:33:67:f2:ac:87:ce:35:cc
		SHA1 Certificate Fingerprint:
			68:07:48:65:a2:4a:bf:18:f5:5b:95:a5:01:42:c0:26:e3:3b:a5:30
    Conseil  -  L'algorithme de hachage par défaut est SHA1. Pour créer certificat avec un algorithme de signature plus fort, utilisez l'option keytype et un autre algorithme de hachage, par exemple keytype=rsa hash=sha384. Pour connaître les options, reportez-vous à la page de manuel pktool(1)
  3. Livrer le certificat à l'autre système.
    1. Sur chaque système, exportez uniquement le certificat dans un fichier.

      L'option outformat=pem permet de vous assurer que le certificat public est placé dans le fichier dans un format convenant à l'importation directe. L'étiquette keystore identifie le certificat dans le.

      # cd /tmp
	# ikev2cert export objtype=cert outformat=pem outfile=filename label=label
	Enter PIN for Sun Software PKCS#11 softtoken:xxxxxxxx
    2. Envoyez ce certificat à l'autre système par e-mail, sftp ou ssh.

      Par exemple administrez les deux systèmes, utilisez la commande sftp pour ramener le certificat de l'autre système.

      enigma # sftp jdoe@partym:/tmp/ITpartym.pem /tmp/ITpartym.pem.cert
	partym # sftp jdoe@enigma:/tmp/ITenigma.pem /tmp/ITenigma.pem.cert

      Vous êtes invité à saisir votre mot de passe. Dans cet exemple, jdoe doit fournir un mot de passe.

  4. Vérifiez que les certificats sont identiques.

    Avant de charger un certificat dans le keystore, assurez-vous que c'est le bon.

    1. Créer une synthèse du fichier exporté sur chaque système.

      Par exemple, l'administrateur de partym envoie par e-mail à l'autre administrateur l'empreinte du fichier contenant le certificat de partym. L'administrateur de enigma envoie pour sa part l'empreinte du fichier de certificat de enigma.

      partym # digest -a sha1 /tmp/ITpartym.pem
	c6dbef4136c0141ae62110246f288e5546a59d86

	enigma # digest -a sha1 ITenigma.pem
	6b288a6a6129d53a45057065bd02b35d7d299b3a
    2. Sur l'autre système, exécutez la commande digest sur le fichier contenant le certificat du premier système. 
      enigma # digest -a sha1 /tmp/ITpartym.pem.cert
	c6dbef4136c0141ae62110246f288e5546a59d86

	partym # digest -a sha1 /tmp/ITenigma.pem.cert
	6b288a6a6129d53a45057065bd02b35d7d299b3a

      Les condensés doivent correspondre. Si elles ne correspondent pas, ne pas importer le contenu du fichier dans le keystore. Pour une autre manière de vérifier la validité d'un certificat, voir l'Example 9–3.

  5. Après vérification, importez le certificat de l'autre système dans le keystore.

    Lorsque vous importez un certificat dans votre keystore, vous devez lui assigner une étiquette unique pour l'identifier sur votre système. La clé publique l'étiquette avec ses liens certificat de clé publique.

    enigma# ikev2cert import label=ITpartym1 infile=/tmp/ITpartym.pem.cert
    partym# ikev2cert import label=ITenigma1 infile=/tmp/ITenigma.pem.cert
  6. (Facultatif) Listez les objets dans le keystore.

    Comparez la liste à celle de l'Step 2. Par exemple, le certificat de partym est ajouté dans le keystore de enigma.

    enigma # /usr/sbin/ikev2cert list objtype=both
	Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx
	No.     Key Type        Key Len.        Key Label
	----------------------------------------------------
	Asymmetric private keys:
	1)      RSA                             ITenigma
	Asymmetric public keys:
	1)      RSA                             ITenigma
	Certificates:
	1) X.509 certificate
		Label: ITenigma
		Subject: C=US, O=exampleco, OU=IT, CN=enigma
		Issuer: C=US, O=exampleco, OU=IT, CN=enigma
		Not Before: April 10 21:49:00 2014 GMT
		Not After: April 10 21:49:00 2015 GMT
		Serial: 0x86426420
		Signature Algorithm: sha1WithRSAEncryption
		X509v3 Subject Key Identifier:
			34:7a:3b:36:c7:7d:4f:60:ed:ec:4a:96:33:67:f2:ac:87:ce:35:cc
		SHA1 Certificate Fingerprint:
			68:07:48:65:a2:4a:bf:18:f5:5b:95:a5:01:42:c0:26:e3:3b:a5:30

	2) X.509 certificate
		Label: ITpartym1
		Subject: C=US, O=exampleco, OU=IT, CN=partym
		Issuer: C=US, O=exampleco, OU=IT, CN=partym
		Not Before: April 10 21:40:00 2014 GMT
		Not After: April 10 21:40:00 2015 GMT
		Serial: 0x87654321
		Signature Algorithm: sha1WithRSAEncryption
		X509v3 Subject Key Identifier:
			ae:d9:c8:a4:19:68:fe:2d:6c:c2:9a:b6:06:55:b5:b5:d9:d9:45:c6
		SHA1 Certificate Fingerprint:
			83:26:44:29:b4:1f:af:4a:69:0d:87:c2:dc:f4:a5:1b:4f:0d:36:3b
  7. Sur chaque système, utilisez les certificats dans une règle IKEv2.

    Utilisez la commande pfedit pour modifier le fichier /etc/inet/ike/ikev2.config.

    1. Par exemple, sur le système partym, la règle du fichier ikev2.config ressemble à ceci : 
      ##  ... Global transform that applies to any rule without a declared transform
	ikesa_xform { dh_group 21 auth_alg sha512 encr_alg aes }
	##  ... Any self-signed
	## end-entity certificates must be present in the keystore or
	## they will not be trusted.
	{
	 label "partym-enigma"
	 auth_method cert
	 local_id DN = "O=exampleco, OU=IT, C=US, CN=partym"
	 remote_id DN = "O=exampleco, OU=IT, C=US, CN=enigma"
	}
	...
    2. Sur le système enigma, utilisez le ND du certificat enigma comme valeur de local_id dans le fichier ikev2.config.

      Pour la valeur du paramètre distant, utilisez le ND du certificat de partym. Assurez-vous que la valeur du mot-clé label est unique sur le système local.

      …
	ikesa_xform { dh_group 21 auth_alg sha512 encr_alg aes }
	…
	{
	 label "enigma-partym"
	 auth_method cert
	 local_id DN = "O=exampleco, OU=IT, C=US, CN=enigma"
	 remote_id DN = "O=exampleco, OU=IT, C=US, CN=partym"
	}
	...
  8. (Facultatif) Sur chaque système, vérifiez la validité des fichiers ikev2.config. 
    # /usr/lib/inet/inikev2.d -c

    Des erreurs typographiques ou des inexactitudes corrigez les éventuelles avant de continuer.

  9. Sur chaque système, vérifiez l'état de l'instance de service IKEv2. 
    # svcs ikev2
	STATE          STIME    FMRI
	disabled       Sep_07   svc:/network/ipsec/ike:ikev2
  10. Sur chaque système, activez l'instance de service IKEv2. 
    partym # svcadm enable ipsec/ike:ikev2

	enigma # svcadm enable ipsec/ike:ikev2
Exemple 9-2  Création d'un certificat autosigné à l'aide d'une durée de vie limitée

Dans cet exemple, l'administrateur indique que le certificat est valide pendant deux ans.

# ikev2cert gencert \
	 > label=DBAuditV \
	 > serial=0x12893467235412 \
	 > subject="O=exampleco, OU=DB, C=US, CN=AuditVault" \
	 > altname=EMAIL=auditV@example.com \ 
	 > keytype=ec curve=secp521r1 hash=sha512 \
     > lifetime=2-year
Exemple 9-3  Vérification d'un certificat de clé publique à l'aide de son empreinte

Dans cet exemple, l'administrateur utilise l'empreinte du certificat pour vérifier le certificat. L'inconvénient de cette méthode est qu'il appartient à l'administrateur d'importer le certificat dans le keystore du pair avant de visualiser l'empreinte.

L'administrateur importe le certificat, le liste à l'aide de la commande ikev2cert list objtype=cert, puis copie son empreinte numérique depuis la sortie et l'envoie à l'administrateur de l'autre système.

SHA1 Certificate Fingerprint:
             83:26:44:29:b4:1f:af:4a:69:0d:87:c2:dc:f4:a5:1b:4f:0d:36:3b

Si la vérification échoue, l'administrateur qui a importé le certificat doit supprimer ce certificat et sa clé publique du keystore.

# ikev2cert delete label=label-name
       Enter PIN for Sun Software PKCS#11 softtoken: xxxxxxxx
       1 public key(s) found, do you want to delete them (y/N) ? y
       1 certificate(s) found, do you want to delete them (y/N) ? y

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.

Copyright © 1999, 2014, Oracle et/ou ses affiliés. Tous droits réservés. Mentions légales
Précédent
Suivant