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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
