descargar - Validación del certificado X.509 con Java y Bouncycastle

descargar bouncy castle

Question

a través de la página de wiki de bouncycastle pude entender cómo crear un certificado raíz X.509 y una solicitud de certificación, pero después de eso no entiendo bien cómo proceder con el concepto y la programación.

Asumamos que la parte A realiza una solicitud de certificado y obtiene su certificado de cliente de la CA. ¿Cómo puede una parte B validar el certificado de A? ¿Qué tipo de certificado necesita A? ¿Un certificado raíz? ¿Un certificado de cliente ''normal''?

¿Y cómo funciona la validación en el nivel de programación, si asumimos que A ha enviado con éxito su certificado en formato DER o PEM a B?

Cualquier ayuda es muy apreciada.

Saludos cordiales, Rob

Answer 1

Desde la perspectiva de un programador, necesita algunas cosas para validar un certificado X.509.

1. Un conjunto de "anclas de confianza": los certificados raíz de las CA en las que confía. Estos deben estar protegidos contra manipulación, para que un atacante no reemplace un certificado de CA con su propia falsificación. Las claves públicas en estos certificados se utilizan para verificar las firmas digitales en otros certificados.
2. Una colección de certificados intermedios. La aplicación puede mantener una colección de estos, pero la mayoría de los protocolos, como SSL y S / MIME, que usan certificados tienen una forma estándar de proporcionar certificados adicionales. El almacenamiento de estos no requiere ningún cuidado especial; su integridad está protegida por la firma de una CA raíz.
3. Información de revocación. Incluso si un certificado fue emitido por una CA, podría haber sido revocado prematuramente porque la clave privada fue revelada, o la entidad final cambió su identidad. (Por ejemplo, una persona cambia de trabajo y se revoca un certificado con el nombre de su compañía anterior.) Las CRL o un servicio web como OCSP se pueden usar para obtener una actualización sobre el estado de un certificado.

Con estas entradas disponibles, puede utilizar el soporte PKIX incorporado para construir y validar una ruta de certificado.

/* Givens. */
InputStream trustStoreInput = ...
char[] password = ...
List<X509Certificate> chain = ...
Collection<X509CRL> crls = ...

/* Construct a valid path. */
KeyStore anchors = KeyStore.getInstance(KeyStore.getDefaultType());
anchors.load(trustStoreInput, password);
X509CertSelector target = new X509CertSelector();
target.setCertificate(chain.get(0));
PKIXBuilderParameters params = new PKIXBuilderParameters(anchors, target);
CertStoreParameters intermediates = new CollectionCertStoreParameters(chain)
params.addCertStore(CertStore.getInstance("Collection", intermediates));
CertStoreParameters revoked = new CollectionCertStoreParameters(crls);
params.addCertStore(CertStore.getInstance("Collection", revoked));
CertPathBuilder builder = CertPathBuilder.getInstance("PKIX");
/* 
 * If build() returns successfully, the certificate is valid. More details 
 * about the valid path can be obtained through the PKIXBuilderResult.
 * If no valid path can be found, a CertPathBuilderException is thrown.
 */
PKIXBuilderResult r = (PKIXBuilderResult) builder.build(params);

Es importante tener en cuenta que si no se puede encontrar una ruta, no se obtiene mucha información sobre el motivo. Esto puede ser frustrante, pero es así por diseño. En general, hay muchos caminos potenciales. Si todos fallan por diferentes razones, ¿cómo decidirá el generador de rutas qué reportar como la razón?

Answer 2

Ok, la idea detrás de CAs es la siguiente:

• Los AC son personas en las que todos confían. Para este fin, una selección de CA de confianza está disponible en su navegador / cliente de correo electrónico / incluso en mi móvil. En su caso, su clave raíz pública (certificado) debe estar en su aplicación.
• Los usuarios envían solicitudes a la CA para obtener un certificado en formato PEM con la clave pública. Las CA hacen alguna forma (dejo esta forma ambigua deliberada) de verificación del usuario final, como cobrarle dinero o, en el caso de certificados de verificación mejorada (verde), verificaciones de antecedentes.
• Si la CA no cree que la solicitud del usuario sea válida, se lo comunicarán de alguna manera.
• Si lo hacen, firman la clave pública y producen un certificado que contiene esta información. Aquí es donde procesa el certificado y lo convierte en un certificado X.509.
• Otros usuarios se encuentran con nuestro usuario ficticio y desean saber si pueden confiar en ellos. Entonces, miran el certificado y descubren que está firmado digitalmente por alguien que tiene en su lista de confianza. Por lo tanto, el hecho de que confíen en la CA raíz y solo en la CA raíz podría firmar (a través de su clave privada) la clave pública de este usuario y la CA confía en el usuario, deducimos que el nuevo usuario puede confiar en el señor ficticio.

A nivel programático, implementa esto leyendo el certificado X.509 y descubriendo quién se supone que debe ser la CA. Dada la huella digital de CA, la encuentra en su base de datos y verifica la firma. Si coincide, tienes tu cadena de confianza.

Esto funciona porque, como he dicho, solo la CA puede crear la firma digital, pero cualquiera puede verificarla. Es exactamente lo contrario del concepto de cifrado. Lo que hace es "cifrar con la clave privada" los datos que desea firmar y verificar que "descifrar con la clave pública" es igual a los datos que tiene.