¿Qué datos debo validar al validar los certificados X.509 utilizando Java?

6

Bueno, empecé con PKI hace un año con el sistema RFID en la escuela. Ahora me piden que implemente esto en mi trabajo. Entiendo la mayor parte de la idea. La duda es sobre la validación del certificado.

Sé que tiene una fecha válida "No antes" y "No después". ¿Es esto suficiente para decir que el certificado es válido? Esto se debe a que los certificados se cambian cada año y quiero estar seguro de que los datos firmados se firmaron con una clave válida. ¿Cómo puedo implementar esto en Java?

La otra pregunta es sobre la revocación, no entiendo para qué sirve, ¿alguien me puede explicar?

    
pregunta BRabbit27 08.12.2011 - 21:04
fuente

3 respuestas

4

Sin la revocación del certificado, su única forma de validar un certificado sería asegurarse de que las fechas sean correctas y que la CA que lo firmó sea de confianza. ¿Qué sucede si emitió un certificado de cliente a un usuario para el acceso VPN y ese certificado se extravió o fue robado? ¿Qué pasa si un servidor se vio comprometido y el certificado ya no es confiable? La revocación del certificado le permite "revocar" certificados individuales que ya no deberían ser aceptados. Al validar un certificado, el cliente verificará la CRL (Lista de revocación de certificados) para obtener una lista de los certificados que se han revocado para garantizar que el certificado sigue siendo válido.

    
respondido por el Paul Ackerman 08.12.2011 - 22:08
fuente
8

La validación del certificado es, eh, un poco más que mirar las fechas.

Eche un vistazo a RFC 5280 . Sería un completo engaño creer que podría implementar la validación de certificados con cualquier tipo de seguridad e interoperabilidad decente, si no lee varias veces y comprende completamente ese documento. Una gran cantidad de problemas se han acumulado en los estándares relacionados con X.509, lo que hace que la implementación de la validación de certificados sea un esfuerzo desalentador. La guía de estilo X.509 es una lectura obligatoria (aunque ahora está un poco anticuada , todavía da la impresión correcta sobre el estado de las cosas en el mundo X.509).

Realmente, si tu jefe te dijo que implementaras la validación X.509, entonces se burló de ti o está seriamente desconectado de la realidad.

Su mejor apuesta es usar alguna biblioteca existente que ya haga el trabajo. Afortunadamente, Java viene con un código para eso; búsquelo en el paquete java.security.cert . Lea detenidamente la Guía del Programador de Java PKI y la adyacente note .

Revocation es el equivalente PKI de "Whoops, sorry, ignorar mi mensaje anterior". Se utiliza para declarar que un certificado determinado no se utilizará, aunque toda la parafernalia de firmas y restricciones de nombre y árboles de políticas y usos clave diga que todo está bien con eso. La verificación del estado de revocación implica la descarga de listas potencialmente enormes de revocación (CRL) y / o hablar con servidores en línea que afirman el estado de algunos certificados (OCSP); en cualquier caso, es costoso, voluminoso, y funcionará solo en la medida en que la Autoridad de Certificación correspondiente publique la información de revocación de una manera adecuada y que cumpla con los estándares, es decir, no tan a menudo.

    
respondido por el Tom Leek 08.12.2011 - 22:16
fuente
6

Además de lo que dijo @Tom Leek's acerca de la API de ruta de certificación, parece que está hablando de "certificados TLS", que supongo que implica que puede estar usando su certificado X.509 dentro del alcance de TLS.

Para hacer esto como parte de la pila TLS de Java (JSSE), puede usar la infraestructura existente X509TrustManager . Debo admitir que no estoy seguro de si se verifica en RFC 5280 o RFC 3280 , su especificación más antigua (probablemente dependa de la versión de Java que esté usando). Asumo Sun / Oracle JRE 6, pero la implementación variará dependiendo de proveedores de seguridad instalados. Este es un contenedor encima de la API de ruta de certificación ya mencionada.

Aquí hay un ejemplo que inicializa TrustManagerFactory con null : usará valores predeterminados para los anclajes de confianza . Lo siguiente le dará a los administradores de confianza:

TrustManagerFactory factory = TrustManagerFactory.getInstance("PKIX");
factory.init((KeyStore)null);
TrustManager[] trustManagers = factory.getTrustManagers();

Los métodos check* del administrador de confianza lanzan un CertificateException cuando algo ha fallado. También verifica la validez de la fecha.

Los administradores de confianza se pueden utilizar para inicializar un SSLContext , que luego puede usarse para inicializar un SSLSocket (a través de la fábrica) o SSLEngine . De forma predeterminada, SSLSocketFactory usa el SSLContext predeterminado, que se inicializa con un número de valores predeterminados .

También puede crear su propio TrustManager si necesita verificar más extensiones para su aplicación y / o relajar ciertas reglas. (Por ejemplo, he escrito una pequeña biblioteca para envolver a los administradores de confianza existentes y acepta otras formas de certificados, como certificados proxy ( RFC 3820 - no 3280).)

Para verificar extensiones específicas, recomiendo usar BouncyCastle , ya que proporciona estructuras de datos para tratar con ASN.1 y así sucesivamente.

    
respondido por el Bruno 08.12.2011 - 23:53
fuente

Lea otras preguntas en las etiquetas