This is a discussion on [openssl.org #1167] allow to use -nocerts in "smime -decrypt" or look for private key anyway if no matching cert found - Openssl ; BTW, this functionality was added: > to use the new functionality execute > 'openssl smime -decrypt -inkey key.pem ...' that is just give it a > -inkey argument and not -recip. Desktop> openssl smime -decrypt -inkey smimeSignerKey. pem -in gwEncTmpCert.eml ...
BTW, this functionality was added:
> to use the new functionality execute
> 'openssl smime -decrypt -inkey key.pem ...' that is just give it a
> -inkey argument and not -recip.
Desktop> openssl smime -decrypt -inkey smimeSignerKey.
pem -in gwEncTmpCert.eml
to check, use
ls -lart /lib/libcrypt.*
readelf -all /lib/libcrypt.a* /lib/libcrypt.dll.a*
nm -A /lib/libcrypt.a
"Cygwin: OpenSSL 0.9.8a 11 Oct 2005 (Library: OpenSSL 0.9.8 05 Jul 2005)"
You get that when the shared library (DLL) isn't the same as the openssl
utility version. This is the cause of the problems.
You need to find where the DLL is that the openssl utility is using and
replace it with the 0.9.8a version. It might be called something like
You can tell the difference by doing:
nm whatever.dll | grep X509_VERIFY_PARAM_set_flags
nm whatever.dll | grep X509_VERIFY_PARAM_get_flags
If you don't get any output for X509_VERIFY_PARAM_get_flags its the
0.9.8 library. If you get output for both its 0.9.8a or later. If you
don't get output for either its probably 0.9.7X.>>
There is a freeware utility on www.sysinternals.com called ListDLLs
which you can use to see all the DLLs a program loads. If you just start
the interactive version of openssl (just type "openssl") the utility
should show you the DLL it uses.>>
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org