La validación de certificados X.509 con Java y BouncyCastle

Question

a través de la bouncycastle wiki page yo era capaz de entender cómo crear un certificado raíz X.509 y una solicitud de certificación, pero no entiendo muy bien cómo proceder concepto- y programación inteligente después de eso .

Supongamos 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 suponemos que A ha enviado con éxito su certificado en formato DER o PEM a B?

Cualquier ayuda es muy apreciada.

Best Regards, Rob

Answer 1

Ok, la idea detrás de las CA es la siguiente:

• las CA son gente confía en todo el mundo. Con este fin, hay una selección de CA fiables disponible en su navegador/cliente de correo electrónico/incluso en mi dispositivo 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 de verificación del usuario final (dejo esto de forma ambigua), como cobrarles 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, lo comunican 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 cert-req y lo convierte en un certificado X.509.
• Otros usuarios se encuentran con nuestro usuario ficticio y desean saber si pueden confiar en ellos. Por lo tanto, echan un vistazo al certificado y descubren que está firmado digitalmente por alguien que tienen en su lista de confianza. Entonces, el hecho de que confíen en la CA raíz y solo 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 mr ficticio.

En un nivel programático, implemente esto leyendo el certificado X.509 y averiguando quién se supone que debe ser 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 ya he dicho, solo CA puede crear la firma digital pero cualquiera puede verificarla. Es exactamente el reverso del concepto de encriptación. Lo que debes hacer es "encriptar con la clave privada" los datos que deseas firmar y verificar que el "descifrado con la clave pública" sea igual a la información que tienes.

Answer 2

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

1. Un conjunto de "anclajes de confianza" — los certificados raíz de CA de los que depende. Deben protegerse contra manipulaciones, de modo 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.Almacenar 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 CA emitió un certificado, podría haber sido revocado prematuramente debido a que se divulgó la clave privada, o la entidad final cambió su identidad. (Por ejemplo, una persona cambia de trabajo y se revoca un certificado con el nombre de su empresa 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 usar el built-in PKIX support 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); 

Una cosa importante a tener en cuenta es 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ía el constructor de ruta qué informar como motivo?