Un certificado "debe" tiene exactamente las características que los verificadores buscarán. Un "verificador" es cualquier sistema que examinará su firma y el certificado, y tratará de decidir si la firma es aceptable.
La mayoría de los verificadores que manejan certificados X.509 aplican las reglas exigidas por el estándar X.509 y la perfil de Internet X.509 . Hay muchas tales reglas; Los más importantes son:
- Un verificador deberá crear una ruta (o cadena ) que venga para una clave pública que sepa a priori (la confíe en el ancla ) hasta el certificado de entidad final , que es el certificado que contiene la clave pública asociada con la clave privada que usó para firmar el documento XML.
- Dentro de la ruta, cada certificado (excepto el último) se usa para verificar la firma en el siguiente certificado. Cada uno de estos certificados debe tener la extensión de Restricción básica con el bit "CA" establecido, marcando el certificado como una CA, es decir, adecuado para verificar una firma en el siguiente certificado en la ruta. Normalmente, la CA comercial se niega a emitir certificados con el conjunto de bits de CA, o lo hace a un precio elevado, por lo que es probable que su "certificado en su máquina de compilación" no sea no un certificado de CA.
- Cualquier certificado puede tener una extensión de uso de clave, que detalla los usos permitidos para la clave pública en el certificado. Para interoperar adecuadamente con los verificadores comunes, un certificado de EE utilizado para firmar un documento XML debe tener una extensión de Uso de clave con los indicadores
digitalSignature y nonRepudiation establecidos (o ninguna extensión de Uso de clave en absoluto). Si un certificado es "un certificado SSL" o un "certificado de firma de código" o cualquier otro nombre similar, es principalmente una cuestión de qué indicadores se establecen en su extensión de uso clave.
- Y, por supuesto, el certificado EE debe alojar una clave pública adecuada para firmar elementos, es decir, RSA, DSA, ECDSA ... pero no Diffie-Hellman.
El punto importante es que encadenar su "certificado incrustado" a su "certificado de máquina de compilación" tiene sentido solo si desea que sus verificaciones XML sean verificables por verificadores genéricos, que no sabrán de su aplicación específica, y usan un genérico conjunto de anclajes de confianza (incluido el que le vendió su "certificado de máquina de compilación"). Lo más probable es que no funcione, porque es improbable que su "certificado de compilación de máquina" tenga el bit de "CA" establecido. Para verificar el contenido de un certificado, use OpenSSL : la herramienta de línea de comandos (ya incluida en MacOS X, cualquier Linux bueno o * BSD , y disponible para la herramienta de Windows) puede usarse así:
openssl x509 -text -noout -in cert.pem
openssl x509 -text -noout -inform DER -in cert.crt
(Use el primero si el certificado está en formato PEM, el segundo si está en DER; o simplemente intente con ambos).
Si controla los verificadores (es decir, en su aplicación, el sistema que verificará la firma en el documento XML será un software que usted también proporciona), y luego se conectará al certificado de la máquina de compilación. Para el CA comercial es inútil; sería mejor crear su propia CA y hacer certificados. OpenSSL puede hacer eso, o puede buscar una solución más gráfica como EJBCA .
No hago ninguna afirmación deliberada sobre la solidez de su concepto de "incrustación segura de un certificado".