> On Apr 6, 2017, at 5:00 PM, Blumenthal, Uri - 0553 - MITLL <uri@xxxxxxxxxx> wrote: > > But with your help, and providing the top root in the “-CAfile …” argument, I got it!! > > > $ openssl cms -verify -CAfile ~/Certs/Our_Root_CA.pem -inform SMIME -in ~/Documents/test-smime-decr.txt > Content-Type: multipart/alternative; > boundary=Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3 > Content-Transfer-Encoding: 7bit > > > --Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3 > Content-Type: text/plain; > charset=us-ascii > . . . . . > --Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3-- > Verification successful Two problems here, the "Verification successful" message is just a diagnostic message to "stderr" and should not be considered a reliable indication of signature validity. You really should use the "-verify_retcode" option to ensure that verification failure leads to a non-zero exit code. Secondly, you would typically care *who* signed the message, and just that it was signed by some random certificate issued by a trusted root. Therefore, you should also use the: author=$(mktemp author.XXXXXX) ... -signer $author ... option to capture the signer's certificate, and then inspect it somehow (check the subject name or serial number, or ...). Further issues arise if the data is expected to remain verifiable past the lifetime of the signer's certificate. It that case, it should be verified on arrival and re-encrypted for long-term storage using an integrity protection mechanism that does not depend on the long-term validity of the signer's key. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
