Tengo la respuesta .tsr de un proceso de firma en OpenSSL. openssl ts -replyobras.
openssl ts -reply -in b1.tsr -text
Using configuration from g:/progs/openssl/ssl/openssl.cnf
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified
TST info:
Version: 1
Policy OID: 1.3.6.1.4.1.6449.2.1.1
Hash Algorithm: sha256
Message data:
0000 - 10 20 96 d8 03 ec ed 6e-03 56 3d d6 d6 a7 14 50 . .....n.V=....P
0010 - b0 a7 53 a9 34 4e b9 57-f7 e2 83 13 5e 0d df e0 ..S.4N.W....^...
Serial number: 0xA7ADC6135D0A39500F7C3B0C41578D8C2CB62B87
Time stamp: Jun 22 10:59:44 2019 GMT
Accuracy: unspecified
Ordering: no
Nonce: 0xD4154ECA4E9A0D06
TSA: DirName:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Time Stamping Signer #1
Extensions:
openssl ts -verifyfalla.
openssl ts -verify -sha256 -digest "102096d803eced6e03563dd6d6a71450b0a753a9344eb957f7e283135e0ddfe0" -in b1.tsr -CAfile comodo.pem
Verification: FAILED
11928:error:2F06D064:time stamp routines:TS_VERIFY_CERT:certificate verify error:.\crypto\ts\ts_rsp_verify.c:264:Verify error:unable to get local issuer certificate
¿Qué es todo esto del certificado de emisor local? No puedo usar -noverify en el comando "ts".
Respuesta1
Para crear una cadena de certificados completa para que openssl verifique, no solo necesita el certificado raíz (que ha especificado usando el -CAfileconmutador), sino también el certificado que se ha utilizado para firmar TSResponse.
Desde la página de manual de ts:
-untrusted cert_file.pem
Set of additional untrusted certificates in PEM format which may be needed when building the certificate chain for the TSA's signing certificate. This
file must contain the TSA signing certificate and all intermediate CA certificates unless the response includes them. (Optional)
Respuesta2
Un error de verificación "no se puede obtener el certificado del emisor local" significa que OpenSSL no pudo encontrar en el almacén de confianza local ni la raíz (o ancla) de una cadena completa ni el siguiente enlace de una cadena incompleta que podría ser o no la raíz/ancla .
Como antecedente, dado que no indica cuánto comprende la verificación basada en certificados, ts -verifyconsta básicamente de cuatro partes:
Verifique que la firma en el cuerpo del token verifique el uso de la clave pública en el certificado del firmante (reclamado) y que se cumplan algunas otras restricciones impuestas por RFC3161 (debe haber solo un SignerInfo y debe usar firmadoAttrs, incluido ESSCertId). Si el certificado del firmante se incluye en la respuesta de marca de tiempo se controla mediante un indicador en la solicitud RFC3161; si no está incluido, el verificador/confesante deberá tenerlo ya o obtenerlo por otros medios.
cree una cadena (también llamada ruta) que vincule el certificado del firmante reclamado con al menos una CA confiable, representada por un certificado de CA llamado certificado raíz o ancla que se define localmente como confiable, generalmente por estar presente en un almacén de confianza. La respuesta RFC3161puedeincluir los certificados de cadena, pero no es obligatorio; en caso contrario, el verificador/confesante deberá tenerlos ya o obtenerlos por otros medios.
valide la cadena comprobando que la firma de cada certificado se verifique bajo la clave pública del siguiente certificado superior (es decir, la clave principal), que cada certificado sea válido (en vigor y no haya caducado) en el momento de la firma, y que una serie de otros campos en cada certificado estén apropiado para su uso en la cadena; ver los detalles enRFC5280 segundo 6. Validacióndeberíaincluya la verificación de que cada certificado en la cadena no sea revocado (a partir del momento de la firma), pero OpenSSL no hace esta parte de forma predeterminada; Hay varias opciones para realizar varias variantes de verificación de revocación, pero no utilizó ninguna de ellas.
finalmente, verifique que el certificado (cadena) sea apropiado para el propósito aquí, es decir, el sellado de tiempo. Para otros casos de uso de certificados como SSL/TLS y S/MIME, generalmente necesitamos verificar no solo que el certificado se emitió legítimamente bajo la autoridad de una CA confiable, sino que también se emitió.auna entidad específica (un sitio web, un servidor de correo o una persona que fue identificada de manera confiable). Sin embargo, por lo general no nos importa la marca de tiempo.cualLa TSA emitió el token, solo eso.algunoLa TSA válida lo hizo, por lo que esta última verificación solo verifica que ExtendedKeyUsage del certificado/cadena incluya (el OID estandarizado y, por lo tanto, permita) el sellado de tiempo.
En conjunto (y solo en conjunto), estos establecen que los datos que tenemos son, de hecho, un token de marca de tiempo emitido por una TSA válida, y no han sido falsificados ni alterados, ya sea intencionalmente o no, y por lo tanto se puede confiar en ellos.
Para la línea de comandos OpenSSL, la raíz/ancla debe estar en el almacén de confianza utilizado, que consta del archivo CA -CAfiley/ -CApatho ruta CA especificados y/o predeterminados, si existen, en cualquier caso en formato PEM; y (aunque la página de manual no es muy clara) cualquier otro certificado de cadena que no esté en el mensaje de respuesta debecualquieraestar en el almacén de confianza o en el archivo proporcionado -untrusted(que debe ser un solo archivo pero puede contener varios certificados en formato PEM). De forma predeterminada, solo se acepta un certificado raíz (e históricamente solo se acepta una raíz) como ancla de cadena/ruta, pero con la -partial_chainopción desde 1.0.2 se acepta un ancla no raíz en el almacén de confianza.
La ts -reply -textpantalla no muestra el nivel de CMS y, en particular, qué certificados se proporcionan en él. Puedes ver todo asn1parse -inform der [-i]pero debes decodificarlo a mano. Más convenientemente, puede extraer la parte CMS SignedData, también conocida como el token firmado, segúnmi respuesta aquíy luego examine los certificados de la siguiente manera:
openssl ts -reply -in respfile -token_out -out tokenfile
openssl pkcs7 -inform der -in tokenfile -print_certs
# if desired/necessary, feed any or each of the PEM cert block(s)
# to openssl x509 -text -noout to get full details
No tengo experiencia con esta TSA, pero según el principio de que el certificado y la cadena de una TSA pública conocida deben registrarse públicamente, el único certificado registrado con ese asunto es conocido por crt.sh (que también está administrado por Comodo-now -Sectigo) eshttps://crt.sh/?id=1437463789que tiene un padre conocidoSectigo RSA Time Stamping CA https://crt.sh/?id=1437089092cuyo emisor es USERTrust RSA Certification Authority; que CA tiene cuatro certificados (padres potenciales) enumerados enhttps://crt.sh/?caid=1167-- uno de ellos de código de Microsoft, que normalmente se usaría solo si la marca de tiempo es para una firma de código Microsoft Authenticode, y los otros tres son todos razonables para uso general, aunque el único llamado Comodo es bastante reciente (publicado hace solo 3 meses) . FWIW, la AIA en id=1437089092 apunta ahttp://crt.usertrust.com/USERTrustRSAAddTrustCA.crtque sirve el certificado desde la raíz de AddTrusthttps://crt.sh/?id=4860286que es el más antiguo (emitido en el año 2000 y que vence en un año).
Utilice los certificados en el mensaje para determinar qué certificados de cadena y ancla adicionales se necesitan para la raíz o el ancla que desea usar y compárelos con lo que se proporciona en su -CAfilearchivo u otro con el que pueda usar -untrusted.