Probably really damaged in transit. The empty attachment should not be empty
too.
But the CA chain is complete and correct: there is a CA certificate present
with required
AKI 44:6A:95:67:55:79:11:4F and
SKI 41:91:69:1C:BF:AD:D8:98
Specifying the root CA in -CAfile must (and normally really does) suffice.
Thanks, Best Regards --Michi
-Ursprüngliche Nachricht-
Von: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
Im Auftrag von Dave Thompson *EXTERN*
Gesendet: Freitag, 28. Juni 2013 05:43
An: openssl-users@openssl.org
Betreff: RE: smime verification failure
From: owner-openssl-us...@openssl.org On Behalf Of Gsandtner Michael
Sent: Wednesday, 26 June, 2013 08:27
# openssl smime -verify -in mail.smime -CAfile A-Trust-nQual-03.pem
Verification failure
3086427788:error:21071065:PKCS7 routines:PKCS7_signatureVerify:
digest failure:pk7_doit.c:1097:
3086427788:error:21075069:PKCS7 routines:PKCS7_verify:
signature failure:pk7_smime.c:410:
# openssl version
OpenSSL 1.0.1e 11 Feb 2013
Any hint locating the problem welcome.
I don't see the point in SMIME-signing a timestamp response,
which is already CMS-signed by its originator. Be that as it may,
it appears to have been done wrong or damaged in transit.
messageDigest in signedAttrs has value (hex)
DB890D1C3E13C6FBBD85A64370B7C0165B726864
but for SHA1 of the actual (clear-part) data I get
911bf75107d9e75c7b480c4a12340e0164a46c74
-- that's your PKCS7_R_DIGEST_FAILURE at pk7_doit.c:1097.
You might see if the sender can send an undetached signature,
i.e. SignedData with content embedded; that will be opaque
to mail-handlers that know about, and might alter, MIME.
Or I note that your .smime as posted has LF=NL line endings
throughout, not CRLF as required on the wire for 2822 headers
and MIME-part headers, and I believe for S/MIME base64 bodies
(which this is) -- openssl processing certainly assumes so.
I hope the NLs are a MUA-local feature; if it was actually sent
and hashed that way, openssl will compute the canonical hash
and thus (practically) never match.
Also, the cert chain is incomplete. The signer-id matches
the first cert in the SignedData: Serial x04d15b from Issuer
C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,
OU=a-sign-corporate-light-03, CN=a-sign-corporate-light-03
for Subject: C=AT, O=Bundesamt f\xC3\xBCr Eich- und Vermessungswesen,
CN=Signaturdienst BEV/serialNumber=246549429784
which has AKI keyid:41:91:69:1C:BF:AD:D8:98 .
(And this cert's key verifies the signedAttrs, although
as noted above signedAttrs does not verify the data.)
The only other cert in the SignedData, which matches
the cert you attached as your -CAfile, is a root for
C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,
OU=A-Trust-nQual-03, CN=A-Trust-nQual-03
with SKI 44:6A:95:67:55:79:11:4F .
The signer's AIA does offer the needed chain cert,
at least apparently so, but openssl won't follow AIA.
You'll need to get it yourself and include it in your
local truststore (CAfile and/'or CApath). Or of course
get the sender to supply the complete chain.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
