Acabo de establecer una VPN de sitio a sitio IPSEC que requería algunos ExtendedKeyUsage e hice algunas investigaciones al respecto.
El ExtendedKeyUsage para el Intercambio de claves de Internet fue desaprobado por RFC4945
CA NO DEBE incluir la extensión ExtendedKeyUsage (EKU) en los certificados para su uso con IKE. Tenga en cuenta que había tres IPsec
identificadores de objetos relacionados en EKU que se asignaron en 1999. El
La semántica de estos valores nunca se definió claramente. El uso de
estos tres valores EKU en IKE / IPsec están obsoletos y explícitamente
En desuso por esta especificación. Las entidades emisoras de certificados NO DEBEN emitir certificados
para uso en IKE con ellos. (Sólo para referencia histórica, aquellos
los valores fueron id-kp-ipsecEndSystem, id-kp-ipsecTunnel e id-kp-
ipsecUser.)
Si este certificado se usará solo para IKE / IPSEC, la recomendación es configurar el uso de clave en digitalSignature, nonRepudiation o ambos.
IKE utiliza un certificado de entidad final en el proceso de autenticación.
El certificado de entidad final se puede utilizar para múltiples aplicaciones. Como
Por lo tanto, la AC puede imponer algunas restricciones sobre la manera en que un
La clave debe ser utilizada. KeyUsage (KU) y ExtendedKeyUsage (EKU)
las extensiones se aplican en esta situación.
Ya que estamos hablando de usar la clave pública para validar un
firma, si la extensión KeyUsage está presente, entonces al menos uno de
la firma digital o los bits de no rechazo en KeyUsage
la extensión DEBE ser establecida (ambas pueden ser establecidas también). También está bien si
otros bits de uso de clave están establecidos.
A continuación se incluye un resumen del flujo lógico para la validación de certificados entre pares:
o Si no hay una extensión KU, continúa.
o Si KU está presente y no menciona la firma digital o
no rechazo (ambos, además de otros KU, también están bien),
rechazar certificado.
o Si ninguno de los anteriores, continúa.