Las extensiones son solo algún tipo de metadatos de políticas adjuntas al certificado. Técnicamente, sin importar las extensiones, un certificado sigue siendo lo mismo: un archivo que vincula una clave a una identidad. Su información podría utilizarse para cualquier propósito: autenticar un servidor, un cliente, firmar otros certificados, firmar correos electrónicos, firmar software / código de controlador, etc.
Ahí es donde las extensiones entran en juego: le dicen a la aplicación qué usos son aplicables a este certificado, de modo que cuando la aplicación encuentra el certificado en un contexto no autorizado, podría (o debe, dependiendo de si el uso está establecido como crítico o no ) considera el certificado como inválido y lo rechaza.
Sin embargo, esta comprobación debe realizarse en el nivel de la aplicación. Una aplicación mal implementada puede no verificar estos usos correctamente y aceptar cualquier certificado en cualquier momento.
Además, se deben tener en cuenta algunas cosas complementarias:
- Estas extensiones son solo una restricción. Se permite el uso de un certificado sin extensión en cualquier rol (sin limitación de uso), mientras que un certificado que contiene alguna extensión está restringido al uso definido por estas extensiones,
-
Las extensiones de tesis se dividen en dos partes principales (más una simplemente histórica):
- El uso de clave (como "No repudio" en su ejemplo) define el uso de criptografía de nivel inferior permitido para este certificado,
- El uso de clave extendida proporciona un nivel de uso más alto autorizado para este certificado ("Autenticación de servidor web TLS" y "Autenticación de cliente web TLS" en sus ejemplos).
- Algunas aplicaciones también manejan lo que se llama Netscape Cert Type , se puede ver como el precursor de los usos de claves extendidas y recolectan usos como "Servidor SSL", "Cliente SSL", etc.
Todos estos usos clave pueden asociarse y utilizarse de manera complementaria.
-
Algunas extensiones podrían estar marcadas como "críticas": esta marca determina cómo una aplicación que no reconoce / no ha implementado una extensión específica debe manejar el certificado. En tal situación, si el indicador "crítico" está habilitado, la aplicación debe rechazar el certificado, cuando este indicador no esté establecido, la aplicación puede seguir aceptando el certificado.
Los nombres de usos de clave extendidos (así como el tipo de certificado de Netscape) son bastante fáciles de entender. Sin embargo, los usos clave dependen en gran medida de cómo el protocolo (en el caso de una comunicación de red) utilizará los certificados. Los usos clave más comunes para una aplicación cliente / servidor SSL / TLS son los siguientes:
-
Servidor : firma digital, no repudio, cifrado de claves,
-
Cliente : firma digital, cifrado de claves, cifrado de datos.
Entonces, para responder a sus preguntas editadas:
¿El certificado con el uso "Sin Repudio" permite autenticar a todos los clientes con / sin el uso de "Autenticación del cliente web TLS"?
¿Pero la "Autenticación de servidor web TLS" sin "No rechazo" permite la autenticación de clientes solo con el uso de "Autenticación de cliente web TLS"?
El uso de "No Repudio" del certificado del servidor será controlado principalmente por el software del cliente, no por el servidor, y no tendrá ningún impacto en la forma en que el servidor validará los certificados del cliente.
El uso de "Autenticación de cliente web TLS" evitará que los certificados del cliente se utilicen en un contexto de servidor. Su ausencia no bloqueará ninguna autenticación. Sin embargo, si un cliente intenta autenticarse usando un certificado sin este uso pero con la "Autenticación del servidor web TLS" en su lugar, lo más probable es que la autenticación sea rechazada por el servidor.