Protección de la red en Oracle® Solaris 11.2

Salir de la Vista de impresión

Actualización: Septiembre de 2014
 
 

Cómo configurar IKEv1 con certificados de claves públicas autofirmados

En este procedimiento, se crea una clave pública/privada y un certificado, llamado par de certificados. La clave privada se almacena en un disco en la base de datos local de certificados y se puede hacer referencia a ella mediante el comando ikecert certlocal. La clave pública y el certificado se almacenan en la base de datos pública de certificados. Puede hacerse referencia a ella mediante el comando ikecert certdb. Puede intercambiar el certificado público con un sistema par. Los dos certificados se utilizan para autenticar las transmisiones de IKEv1.

Los certificados autofirmados requieren menos carga que los certificados públicos de una autoridad de certificación, pero no se escalan fácilmente. A diferencia de los certificados emitidos por una CA, los dos administradores que intercambiaron los certificados deben verificar los certificados autofirmados.

Antes de empezar

Debe convertirse en un administrador que tiene asignado el perfil de derechos de gestión de IPsec de red. Para obtener más información, consulte Uso de sus derechos administrativos asignados de Protección de los usuarios y los procesos en Oracle Solaris 11.2 .

Si realiza administraciones remotas, consulte el Example 7–1 y Cómo administrar ZFS con shell seguro de forma remota de Gestión de acceso mediante shell seguro en Oracle Solaris 11.2 para obtener instrucciones para un inicio de sesión remoto seguro.

  1. En cada sistema IKEv1, cree un certificado autofirmado en la base de datos de ike.privatekeys.

    Para obtener argumentos sobre el comando ikecert certlocal, consulte la página del comando man ikecert(1M).

    1. Por ejemplo, el comando del sistema partym sería como el siguiente:
      # 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-----

      Donde

      –ks

      Crea un certificado autofirmado.

      –m keysize

      Especifica el tamaño de la clave.

      –t keytype

      Especifica el tipo de algoritmo que utilizar.

      –D dname

      Especifica el nombre distintivo (DN) X.509 para el asunto del certificado. Para obtener un ejemplo, consulte Uso de certificados de claves públicas en IKE.

      –A altname

      Especifica el nombre alternativo o el apodo para el certificado. altname tiene el formato tag=value. Las etiquetas válidas son IP, DNS, email y DN.


      Notas -  Los valores de las opciones –D y –A son nombres que identifican solamente el certificado, no cualquier sistema, como 192.168.13.213. De hecho, dado que estos valores son apodos de certificados, debe verificar fuera de banda que el certificado correcto esté instalado en los sistemas pares.
    2. El comando del sistema enigma sería como el siguiente:
      # 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. Guarde el certificado y envíelo al sistema remoto.

    La salida es una versión codificada de la parte pública del certificado. Puede pegar de manera segura este certificado en un mensaje de correo electrónico. La parte receptora debe verificar fuera de banda que se haya instalado el certificado correcto, como se muestra en el Step 4.

    1. Por ejemplo, debe enviar la parte pública del certificado partym al administrador 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. El administrador de enigma debe enviarle la parte pública del certificado enigma.
      To: admin@party.us.example.com
      From: admin@enigma.ja.example.com
      Message: ----BEGIN X509 CERTIFICATE-----
      MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T
      ...
      y85m6LHJYtC6
      -----END X509 CERTIFICATE-----
  3. En cada sistema, agregue el certificado que recibió a la base de datos de claves públicas.
    1. Guarde el correo electrónico del administrador en un archivo que pueda ser leído por root.
    2. Redirija el archivo al comando ikecert.
      # ikecert certdb -a < /tmp/certificate.eml 

      El comando importa el texto entre las etiquetas BEGIN y END.

  4. Verifique con el otro administrador del sistema que el certificado pertenezca a ese administrador.

    Por ejemplo, puede llamar por teléfono al otro administrador para verificar que el hash del certificado público que usted tiene coincida con el hash del certificado privado que únicamente el administrador tiene.

    1. Muestre el certificado almacenado en partym.

      En el ejemplo siguiente, Note 1 (Nota 1) indica el nombre distintivo (DN) del certificado en la ranura 0. El certificado privado en la ranura 0 tiene el mismo hash (ver Note 3 [Nota 3]), de modo que estos certificados son el mismo par de certificados. Para que los certificados públicos funcionen, debe haber una pareja coincidente. El subcomando certdb enumera la parte pública, mientras que el subcomando certlocal enumera la parte privada.

      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

      Esta comprobación verificó que el sistema partym tenga un par de certificados válido.

    2. Verifique que el sistema enigma tenga el certificado público de partym.

      El hash de clave pública se puede comunicar por teléfono.

      Compare los hashes de Note 3 (Nota 3) en partym, en el paso anterior, con Note 4 (Nota 4) en 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

      El hash de clave pública y el nombre del asunto del último certificado almacenado en la base de datos de certificados públicos de enigma coincide con el hash del certificado privado para partym en el paso anterior.

  5. En cada sistema, confíe en ambos certificados.

    Edite el archivo /etc/inet/ike/config para reconocer los certificados.

    El administrador del sistema remoto proporciona los valores para los parámetros cert_trust, remote_addr y remote_id.

    1. Por ejemplo, en el sistema partym, el archivo ike/config sería similar a:
      # 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. En el sistema enigma, agregue los valores de enigma para los parámetros locales en el archivo ike/config.

      Para los parámetros remotos, utilice los valores de partym. Asegúrese de que el valor de la palabra clave label sea exclusivo en el sistema 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. En los sistemas pares, active IKEv1.
    partym # svcadm enable ipsec/ike:default
    enigma # svcadm enable ipsec/ike

Pasos siguientes

Si no terminó de establecer la política IPsec, regrese al procedimiento IPsec para activar o refrescar la política IPsec. Para ver ejemplos de la política de IPsec para protección de VPN, consulte Protección de una VPN con IPsec. Para ver otros ejemplos de la política de IPsec, consulte Cómo proteger el tráfico de red seguro entre dos servidores con IPsec.