Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
Administración de Oracle Solaris: servicios IP Oracle Solaris 11 Information Library (Español) |
Parte I Administración de TCP/IP
1. Planificación de la implementación de red
2. Consideraciones para el uso de direcciones IPv6
3. Configuración de una red IPv4
4. Habilitación de IPv6 en una red
5. Administración de una red TCP/IP
6. Configuración de túneles IP
7. Resolución de problemas de red
10. Acerca de DHCP (descripción general)
11. Administración del servicio DHCP de ISC
12. Configuración y administración del cliente DHCP
13. Comandos y archivos DHCP (referencia)
14. Arquitectura de seguridad IP (descripción general)
15. Configuración de IPsec (tareas)
16. Arquitectura de seguridad IP (referencia)
17. Intercambio de claves de Internet (descripción general)
18. Configuración de IKE (tareas)
Visualización de información IKE
Cómo visualizar grupos y algoritmos disponibles para intercambios IKE de fase 1
Configuración de IKE (mapa de tareas)
Configuración de IKE con claves previamente compartidas (mapa de tareas)
Configuración de IKE con claves previamente compartidas
Cómo configurar IKE con claves previamente compartidas
Cómo actualizar IKE para un sistema equivalente nuevo
Configuración de IKE con certificados de clave pública (mapa de tareas)
Configuración de IKE con certificados de clave pública
Cómo configurar IKE con certificados de clave pública autofirmados
Cómo configurar IKE con certificados firmados por una autoridad de certificación
Cómo generar y almacenar certificados de clave pública en el hardware
Configuración de IKE para sistemas portátiles (mapa de tareas)
Configuración de IKE para sistemas portátiles
Cómo configurar IKE para sistemas remotos
Configuración de IKE para buscar el hardware conectado
Cómo configurar IKE para buscar la placa Sun Crypto Accelerator 6000
19. Intercambio de claves de Internet (referencia)
20. Filtro IP en Oracle Solaris (descripción general)
22. Descripción general del equilibrador de carga integrado
23. Configuración del equilibrador de carga integrado (tareas)
24. Protocolo de redundancia de enrutador virtual (descripción general)
25. Configuración VRRP (tareas)
26. Implementación del control de congestión
Parte V Calidad de servicio IP (IPQoS)
27. Introducción a IPQoS (descripción general)
28. Planificación para una red con IPQoS (tareas)
29. Creación del archivo de configuración IPQoS (tareas)
30. Inicio y mantenimiento de IPQoS (tareas)
31. Uso de control de flujo y recopilación de estadísticas (tareas)
Los certificados de clave pública acaban con la necesidad de que los sistemas que se comunican compartan material de claves secreto fuera de banda. A diferencia de las claves previamente compartidas, un certificado de clave pública se puede utilizar en un equipo portátil o en un sistema cuya numeración podría cambiar.
Los certificados de clave pública también se pueden generar y almacenar en el hardware conectado. Para conocer el procedimiento, consulte Configuración de IKE para buscar el hardware conectado.
En este procedimiento, se crea un par de certificados. La clave privada se almacena en un disco en la base de datos local de certificados y puede consultarse con el subcomando certlocal. La parte pública del certificado se almacena en la base de datos pública de certificados. Puede consultarse con el subcomando certdb. Con un sistema equivalente, puede intercambiarse la parte pública. La combinación de dos certificados se utiliza para autenticar las transmisiones IKE.
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 autoridad de certificación, los certificados autofirmados deben verificarse fuera de la banda.
Para obtener más información, consulte Cómo obtener derechos administrativos de Administración de Oracle Solaris: servicios de seguridad. Si inicia sesión de manera remota, utilice el comando ssh para un inicio de sesión remoto seguro. Esto se ilustra en el Ejemplo 15-1.
# ikecert certlocal -ks -m keysize -t keytype \ -D dname -A altname \ [-S validity-start-time] [-F validity-end-time] [-T token-ID]
Crea un certificado autofirmado.
Es el tamaño de la clave. Tamaño_clave puede ser 512, 1024, 2048, 3072 o 4096.
Especifica el tipo de algoritmo que utilizar. Tipo_algoritmo puede ser rsa-sha1, rsa-md5 o dsa-sha1.
Es el nombre X.509 distinguido para el tema del certificado. Por lo general, nombre_d tiene la forma: C=país, O=organización, OU=unidad organizativa, CN=nombre común. Las etiquetas válidas son C, O, OU y CN.
Nombre alternativo del certificado; nombre_alt tiene el formato tag=value. Las etiquetas válidas son IP, DNS, email y DN.
Proporciona un tiempo de inicio de validez absoluto o relativo para el certificado.
Proporciona un tiempo de fin de validez absoluto o relativo para el certificado.
Permite al token de hardware PKCS #11 generar las claves. Los certificados se guardan en el hardware.
# ikecert certlocal -ks -m 2048 -t rsa-sha1 \ -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-----
Nota - Los valores de las opciones de -D y -A son arbitrarios. Los valores se utilizan para identificar el certificado únicamente. No se utilizan para identificar un sistema, como 192.168.13.213. De hecho, dado que estos valores son idiosincrásicos, debe verificar fuera de banda que el certificado correcto esté instalado en los sistemas equivalentes.
# ikecert certlocal -ks -m 2048 -t rsa-sha1 \ -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-----
La salida es una versión codificada de la parte pública del certificado. Puede pegar de manera segura este certificado en un correo electrónico. La parte receptora debe verificar fuera de banda que se haya instalado el certificado correcto, como se muestra en el Paso b.
To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEfdZgKjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T a...+ zBGi4QkNdI3f -----END X509 CERTIFICATE------
To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: ----BEGIN X509 CERTIFICATE----- MIIC1TCCAb2gAwIBAgIEBl5JnjANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9T ... y85m6LHJYtC6 -----END X509 CERTIFICATE-----
# ikecert certdb -a < /tmp/certificate.eml
El comando importa el texto entre las etiquetas BEGIN y END.
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.
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, 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-sha1 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.
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 de enigma coincide con el hash del certificado privado para partym en el paso anterior.
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.
# 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-enigmax" 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} }
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-enigmax 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 …
partym # svcadm enable ipsec/ike enigma # svcadm enable ipsec/ike
Pasos siguientes
Si no terminó de establecer la política IPsec, regrese al procedimiento IPsec para habilitar o refrescar la política IPsec.
Los certificados públicos de una autoridad de certificación requieren negociar con una organización externa. Los certificados se pueden escalar con gran facilidad para proteger un mayor número de sistemas que se comunican.
Para obtener más información, consulte Cómo obtener derechos administrativos de Administración de Oracle Solaris: servicios de seguridad. Si inicia sesión de manera remota, utilice el comando ssh para un inicio de sesión remoto seguro. Esto se ilustra en el Ejemplo 15-1.
Para ver una descripción de los argumentos del comando, consulte el Paso b in Cómo configurar IKE con certificados de clave pública autofirmados.
# ikecert certlocal -kc -m keysize -t keytype \ -D dname -A altname
# ikecert certlocal -kc -m 2048 -t rsa-sha1 \ > -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-----
# ikecert certlocal -kc -m 2048 -t rsa-sha1 \ > -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-----
La organización de PKI puede indicar cómo enviar la solicitud de certificado. La mayoría de las organizaciones cuenta con un sitio web con un formulario de envío. El formulario requiere una prueba de que el envío es legítimo. Normalmente, la solicitud de certificado se pega en el formulario. Cuando la organización ha comprobado la solicitud, emite los dos objetos de certificado siguientes y una lista de los certificados revocados:
El certificado de clave pública: este certificado se basa en la solicitud que usted ha enviado a la organización. La solicitud que envía forma parte del certificado de clave pública. El certificado le identifica de forma exclusiva.
Una autoridad de certificación: la firma de la organización. La autoridad de certificación verifica que el certificado de clave pública sea legítimo.
Una lista de revocación de certificados (CRL): la lista de certificados más reciente que ha revocado la organización. La CRL no se envía por separado como objeto de certificado si el acceso a la CRL está integrado en el certificado de clave pública.
Cuando un URI para la CRL está integrado en el certificado de clave pública, IKE puede recuperar automáticamente la CRL. De modo similar, cuando una entrada DN (nombre de directorio en servidor LDAP) se integra en el certificado de clave pública, IKE puede recuperar la CRL y almacenarla en caché desde un servidor LDAP que se especifique.
Consulte Cómo administrar una lista de revocación de certificados para ver un ejemplo de URI integrado y una entrada DN integrada en un certificado de clave pública.
La opción -a de ikecert certdb -a agrega el objeto pegado a la base de datos de certificados pertinente del sistema. Para más información, consulte IKE con certificados de claves públicas.
Para obtener más información, consulte Cómo obtener derechos administrativos de Administración de Oracle Solaris: servicios de seguridad. Si inicia sesión de manera remota, utilice el comando ssh para un inicio de sesión remoto seguro. Esto se ilustra en el Ejemplo 15-1.
# ikecert certdb -a < /tmp/PKIcert.eml
# ikecert certdb -a < /tmp/PKIca.eml
# ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D
Utilice el nombre que proporciona la organización de PKI.
# 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 sha384 encr_alg aes} 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 sha256 encr_alg aes} }
Nota - Todos los argumentos del parámetro auth_method deben encontrarse en la misma línea.
En concreto, el archivo enigma ike/config llevará a cabo las siguientes acciones:
Incluirá el mismo valor de cert_root.
Utilizará los valores de enigma para los parámetros locales.
Utilice los valores de partym para los parámetros remotos.
Cree un valor único para la palabra clave label. Este valor debe ser diferente del valor label del sistema remoto.
… 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 …
Elija la opción adecuada:
Si la organización de PKI no proporciona ninguna CRL, agregue la palabra clave ignore_crls al archivo ike/config.
# Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,… ignore_crls …
La palabra clave ignore_crls indica a IKE que no debe buscar ninguna CRL.
Si la organización de PKI proporciona un punto de distribución central para las CRL, puede modificar el archivo ike/config para que haga referencia a esa ubicación.
Consulte Cómo administrar una lista de revocación de certificados para ver algunos ejemplos.
Ejemplo 18-2 Uso de rsa_encrypt durante la configuración de IKE
Cuando utiliza auth_method rsa_encrypt en el archivo ike/config, debe agregar el certificado equivalente a la base de datos publickeys.
Envíe el certificado al administrador del sistema remoto.
El certificado se puede pegar en un mensaje de correo electrónico.
Por ejemplo, el administrador de partym enviaría el siguiente mensaje de correo electrónico:
To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MII… ----END X509 CERTIFICATE-----
El administrador de enigma enviaría el siguiente mensaje de correo electrónico:
To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MII … -----END X509 CERTIFICATE-----
En cada sistema, agregue el certificado enviado por correo electrónico a la base de datos publickeys local.
# ikecert certdb -a < /tmp/saved.cert.eml
El método de autenticación para el cifrado de RSA oculta las identidades de IKE de los intrusos. Dado que el método rsa_encrypt oculta la identidad del equivalente, IKE no puede recuperar su certificado. Como consecuencia de ello, el método rsa_encrypt requiere que los equivalentes de IKE conozcan las claves públicas el uno del otro.
Por tanto, si utiliza un auth_method de rsa_encrypt en el archivo /etc/inet/ike/config, debe agregar el certificado del equivalente a la base de datos publickeys. La base de datos publickeys incluye tres certificados para cada par de sistemas que se comunican:
Su certificado de clave pública
El certificado de la administración de certificación
El certificado de clave pública del equivalente
Resolución de problemas: la carga útil de IKE, que incluye los tres certificados, puede ser demasiado grande para que la cifre rsa_encrypt. Errores como un fallo de autenticación o una carga útil mal formada pueden indicar que el método rsa_encrypt no puede cifrar la carga útil total. Reduzca el tamaño de la carga útil utilizando un método que requiera únicamente dos certificados, por ejemplo rsa_sig.
Pasos siguientes
Si no terminó de establecer la política IPsec, regrese al procedimiento IPsec para habilitar o refrescar la política IPsec.
La generación y el almacenamiento de certificados de clave pública en hardware es similar a la generación y el almacenamiento de certificados de clave pública en el sistema. En el hardware, los comandos ikecert certlocal e ikecert certdb deben identificar el hardware. La opción -T con el ID de símbolo identifica el hardware para los comandos.
Antes de empezar
El hardware debe estar configurado.
El hardware utiliza la biblioteca /usr/lib/libpkcs11.so, a menos que la palabra clave pkcs11_path del archivo /etc/inet/ike/config haga referencia a una biblioteca distinta. La biblioteca debe implementarse de acuerdo con el estándar siguiente: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), es decir, una biblioteca PKCS #11.
Consulte Cómo configurar IKE para buscar la placa Sun Crypto Accelerator 6000 para obtener instrucciones sobre la instalación.
Para obtener más información, consulte Cómo obtener derechos administrativos de Administración de Oracle Solaris: servicios de seguridad. Si inicia sesión de manera remota, utilice el comando ssh para un inicio de sesión remoto seguro. Esto se ilustra en el Ejemplo 15-1.
Elija una de las siguientes opciones:
Nota - La placa Sun Crypto Accelerator 6000 admite claves de hasta 2048 bits para RSA. Para DSA, esta placa admite claves de hasta 1024 bits.
# ikecert certlocal -ks -m 2048 -t rsa-sha1 \ > -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
El argumento para la opción -T es el ID de token de la placa Sun Crypto Accelerator 6000 conectada.
# ikecert certlocal -kc -m 2048 -t rsa-sha1 \ > -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
Para ver una descripción de los argumentos para el comando ikecert, consulte la página del comando man ikecert(1M).
Si la placa Sun Crypto Accelerator 6000 tiene un usuario ikemgr cuya contraseña es rgm4tigt, debe escribir lo siguiente:
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
Nota - La respuesta de PIN se guarda en el disco como texto sin cifrar.
Una vez indicada la contraseña, se imprime el certificado:
Enter PIN for PKCS#11 token: ikemgr:rgm4tigt -----BEGIN X509 CERTIFICATE----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … oKUDBbZ9O/pLWYGr -----END X509 CERTIFICATE-----
Elija una de las siguientes opciones:
El certificado se puede pegar en un mensaje de correo electrónico.
Siga las instrucciones de la organización de PKI para enviar la solicitud de certificado. Para obtener información más detallada, consulte el Paso 3 de Cómo configurar IKE con certificados firmados por una autoridad de certificación.
Elija una de las siguientes opciones.
Utilice los valores que proporciona el administrador del sistema remoto para los parámetros cert_trust, remote_id y remote_addr. Por ejemplo, en el sistema enigma, el archivo ike/config sería similar a:
# 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 … { 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 sha256 encr_alg aes} }
Escriba el nombre que proporciona la organización de PKI como valor para la palabra clave cert_root. Por ejemplo, el archivo ike/config del sistema enigma podría ser similar a:
# 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" … { 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 sha256 encr_alg aes} }
Responda a la solicitud de PIN del mismo modo que en el Paso 3.
Nota - Debe agregar los certificados de clave pública al mismo hardware conectado que generó la clave privada.
Agregue el certificado autofirmado al sistema remoto. En este ejemplo, el certificado se guarda en el archivo, 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 el certificado autofirmado utilizó rsa_encrypt como valor para el parámetro auth_method, agregue el certificado del equivalente al hardware.
Agregue el certificado que ha generado la organización a partir de la solicitud de certificado, y agregue la autoridad de certificación.
# 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
Para agregar una lista de revocación de certificados (CRL) de la organización de PKI, consulte Cómo administrar una lista de revocación de certificados.
Pasos siguientes
Si no terminó de establecer la política IPsec, regrese al procedimiento IPsec para habilitar o refrescar la política IPsec.
Una lista de revocación de certificados (CRL) contiene certificados caducados o que suponen un peligro de una autoridad de certificación. Existen cuatro modos de administrar las CRL.
Debe indicar a IKE que omita las CRL si la organización de la autoridad de certificación no emite ninguna CRL. Esta opción se muestra en el Paso 6 in Cómo configurar IKE con certificados firmados por una autoridad de certificación.
Puede indicar a IKE que acceda a las CRL desde un indicador de recursos uniforme (URI) cuya dirección esté integrada en el certificado de clave pública de la autoridad de certificación.
Puede indicar a IKE que acceda a las CRL desde un servidor LDAP cuya entrada de nombre de directorio (DN) esté integrada en el certificado de clave pública de la autoridad de certificación.
Puede proporcionar la CRL como argumento para el comando ikecert certrldb. Esto se ilustra en el Ejemplo 18-3.
El siguiente procedimiento describe cómo indicar a IKE que utilice las CRL de un punto de distribución central.
# ikecert certdb -lv certspec
Enumera los certificados de la base de datos IKE.
Enumera los certificados en modo detallado. Utilice esta opción con precaución.
Es un patrón que coincide con un certificado de la base de datos de certificados IKE.
Por ejemplo, Oracle emitió el certificado siguiente. Los detalles se han modificado.
# ikecert certdb -lv example-protect.oracle.com Certificate Slot Name: 0 Type: dsa-sha1 (Private key in certlocal slot 0) Subject Name: <O=Oracle, CN=example-protect.oracle.com> Issuer Name: <CN=Oracle CA (Cl B), O=Oracle> SerialNumber: 14000D93 Validity: Not Valid Before: 2011 Sep 19th, 21:11:11 GMT Not Valid After: 2015 Sep 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.oracle.com Key Usage: DigitalSignature KeyEncipherment [CRITICAL] CRL Distribution Points: Full Name: URI = #Ihttp://www.oracle.com/pki/pkismica.crl#i DN = <CN=Oracle CA (Cl B), O=Oracle> CRL Issuer: Authority Key ID: Key ID: 4F … 6B SubjectKeyID: A5 … FD Certificate Policies Authority Information Access
Observe la entrada CRL Distribution Points. La entrada URI indica que la CRL de esta organización está disponible en Internet. La entrada DN indica que la CRL está disponible en un servidor LDAP. Cuando IKE accede a la CRL, ésta se almacena en caché para futuros usos.
Para acceder a la CRL, debe alcanzar un punto de distribución.
Agregue la palabra clave use_http al archivo /etc/inet/ike/config del host. Por ejemplo, el archivo ike/config tendría el siguiente aspecto:
# Use CRL from organization's URI use_http …
Agregue la palabra clave proxy al archivo ike/config. La palabra clave proxy adopta una dirección URL como argumento, como en el caso siguiente:
# Use own web proxy proxy "http://proxy1:8080"
Configure el servidor LDAP como argumento para la palabra clave ldap-list del archivo /etc/inet/ike/config del host. Su organización proporciona el nombre del servidor LDAP. La entrada del archivo ike/config tendría el siguiente aspecto:
# Use CRL from organization's LDAP ldap-list "ldap1.oracle.com:389,ldap2.oracle.com" …
IKE recupera la CRL y almacena en caché la CRL hasta que caduque el certificado.
Ejemplo 18-3 Cómo pegar una CRL en la base de datos certrldb local
Si la CRL de la organización de PKI no está disponible en un punto de distribución central, puede agregar la CRL manualmente a la base de datos certrldb local. Siga las instrucciones de la organización de PKI para extraer la CRL en un archivo y, a continuación, agregue la CRL a la base de datos con el comando ikecert certrldb -a.
# ikecert certrldb -a < Oracle.Cert.CRL