Hola usuario de nuestro sitio web, hemos encontrado la solución a lo que necesitas, deslízate y la obtendrás aquí.
Solución:
Primerodebes saber que una parte de la respuesta a tu pregunta es una openssl informe de errores que acabo de presentar.
Ambas cosas openssl cms -sign y openssl cms -verify solo manejar contenido S/MIME. Ellos, por coincidencia, también pueden procesar cualquier dato de texto (aunque no hay promesa de que esta funcionalidad se mantenga en versiones futuras), pero no están diseñados para firmar o verificar ningún dato binario cifrado, incluidos, entre otros, DER cifrados. -mensajes codificados, como es en su caso (aunque el cms(1) página de manual asume que todavía es posible).
Lo que no es menos importante, esos dos no detectarían si la entrada está en cualquier otro formato, fallando silenciosamente con un mensaje de error (algo oscuro):
$ cat msg.txt
This is a secret message from Alice for Bob written at Thu Mar 13 12:39:12 CET 2014
$
$ openssl cms -encrypt -outform DER -aes-256-cbc -in msg.txt cert.pem
| openssl cms -sign -md sha256 -signer cert.pem -inkey key.pem -nodetach -outform DER
| openssl cms -verify -inform DER -CAfile ca.pem -out msg_ver.txt
Verification successful
$
$ openssl cms -cmsout -in msg_ver.txt -print
Error reading S/MIME message
4404864620:error:0D0D40D1:asn1 encoding routines:SMIME_read_ASN1:no content type:asn_mime.c:440:
$
$ openssl cms -cmsout -in msg_ver.txt -inform DER -print
Error reading S/MIME message
4527457900:error:0D06B08E:asn1 encoding routines:ASN1_D2I_READ_BIO:not enough data:a_d2i_fp.c:247:
$
NB: esto es a partir de 1.0.2r y 1.1.1b
opensslversiones: las más recientes en el momento de escribir este artículo.Probablemente se mantendría igual en versiones futuras, aunque será mejor que vuelvas a comprobarlo si estás leyendo esto alrededor de 2020.
Intentaré actualizar la respuesta una vez que cambie el comportamiento, aunque no tengo ninguna responsabilidad por no hacerlo.
Segundoel resultado que ve es un mensaje descifrado correcto en su totalidad.
Sin embargo, por razones que desconozco, quienquiera que le haya proporcionado el archivo encriptado no hizo lo normal. encrypt[1] -> sign[2] ruta, pero en su lugar lo hizo sign[1] -> encrypt[2] -> sign[3] en lugar de. La firma en los pasos 1 y 3 se realizó con diferentes certificados, con números de serie a2:30:b4:be:2b:89:05:27 y a2:30:b4:be:2b:89:05:23respectivamente.
Ha manejado correctamente los pasos 3 y 2 hacia atrás. Para verificar la última firma del paso 1, necesita encontrar un certificado con el número de serie a2:30:b4:be:2b:89:05:27y el certificado que ha proporcionado tiene un número de serie a2:30:b4:be:2b:89:05:23cuatro certificados emitidos lejos de lo que debería haber tenido.
Así es como puede averiguar el número de serie de un certificado:
$ openssl x509 -in ehealth_root_ca.cer -noout -text | grep -A1 'Serial Number:'
Serial Number:
a2:30:b4:be:2b:89:05:23
$
Tal vez el certificado necesario se encuentre en algún lugar de las fuentes o ejemplos de la biblioteca a la que se refiere.
(Aquí hay un breve openssl cms libro de cocina en caso de que lo necesites, aunque no parece usted hacer.)
Acuérdate de que puedes optar por la opción de interpretar si diste con la respuesta.