Checking a single signature from several in S/MIME
Hello list, I'm signing a file using SMIME with 2 signers. When trying to check the signature with only one of the two signers, it fails with a "signer certificate not found". Using both signers, it succeeds. Is there a way to be able to check the signature with a single signer, not all of them? // Signing openssl smime -binary -sign -nodetach -in file -out file.signed -inkey key1.pem -signer cert1.pem -inkey key2.pem -signer cert2.pem // this command fails with signer certificate not found" openssl smime -binary -verify -nointern -noverify -certfile cert1.pem -in file.sign -out file.checked // this command succeeds and write both certificates in file.signer openssl smime -binary -verify -noverify -certfile cert1.pem -in file.sign -out file.checked -signer file.signer // This command succeeds openssl smime -binary -verify -nointern -noverify -certfile file.signer -in file.sign -out file.checked thanks in advance for any suggestion, Laurent
make test fails for 0.9.8i on Solaris 9 SPARC
Hello, I've built OpenSSL 0.9.8i on a Solaris 9 SPARC system, using a fully patched Sun Studio 11. It builds fine, however, «make test» fails (see below). Version 0.9.8h built on the same system with the same parameters doesn't fail. Version 0.9.8i built with Studio 12 on S10 x86 doesn't fail, either. Compiler or OpenSSL bug? Laurent I built using this: ./config --prefix=/usr/local/openssl-0.9.8i shared -R/usr/local/openssl-0.9.8i/lib make make test c2tnb431r1: ... ok wap-wsg-idm-ecid-wtls3: ... ok wap-wsg-idm-ecid-wtls5: .. failed ECDSA test failed 23191:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1294: 23191:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=ECDSA_SIG 23191:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:150: 23191:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:1281: 23191:error:0D06C03A:asn1 encoding routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:830: 23191:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=s, Type=ECDSA_SIG *** Error code 1 make: Fatal error: Command failed for target `test_ecdsa' Current working directory /export/home/lblume/openssl-0.9.8i/test *** Error code 1 make: Fatal error: Command failed for target `tests' With OpenSSL 0.9.8h: c2tnb431r1: ... ok wap-wsg-idm-ecid-wtls3: ... ok wap-wsg-idm-ecid-wtls5: ... ok wap-wsg-idm-ecid-wtls7: ... ok wap-wsg-idm-ecid-wtls9: ... ok wap-wsg-idm-ecid-wtls10: ... ok wap-wsg-idm-ecid-wtls11: ... ok wap-wsg-idm-ecid-wtls12: ... ok -- / Leader de Projet Communauté| I'm working, but not speaking for \ G11N http://fr.opensolaris.org | Bull Services http://www.bull.com / FOSUG http://guses.org | __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: solaris x86 32-bit compile problem
Andy Harrison a écrit : I'm trying to compile with the following options, but it's insisting on using the 64 bit version and I can't seem to get around this. # ./config --install_prefix=/usr/src/OPENSSL --prefix=/usr/local/ssl --openssldir=/usr/local/ssl --shared solaris-x86-gcc Operating system: i86pc-whatever-solaris2 Configuring for solaris64-x86_64-gcc target already defined - solaris64-x86_64-gcc (offending arg: solaris-x86-gcc) Any ideas how I can force it to 32-bit? Just use: ./Configure solaris-x86-gcc other options For some reason, OpenSSL now defaults to 64 bits on S10 on AMD64, while still 32 on SPARCv9. You'd rather use Studio 11 which will give you a faster binary with less dependencies (remember to patch it before building OpenSSL). Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: solaris x86 32-bit compile problem
Neetee Pawa a écrit :
However for me .. the binaries did not work once i compiled in 32 bit
mode. May be they work for you.
Depending on what your issue was, that reminds me that I use the exact
following to build:
PREFIX=openssl-0.9.8d
export LD_OPTIONS=-R/usr/local/${PREFIX}/lib
./Configure solaris-x86-cc \
--prefix=/usr/local/${PREFIX} shared \
-R/usr/local/${PREFIX}/lib
The LD_OPTIONS is important, else the openssl command lacks the RUNPATH
needed to find its own corresponding library, and won't run (it's a bug
in the OpenSSL build script that do not use the -R added on the command
line, nor the --prefix to set a correct RUNPATH).
The libraries themselves worked.
Laurent
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Trouble compiling and openssl 0.9.8 d or e on solari10
[EMAIL PROTECTED] a écrit : I surely did something wrong, it's ok now. Thanks for quick and efficient help. Btw it seems that I have seen several people having the same problem. Maybe adding a test for the right patches in the configuration step could be fine. Wouldn't be portable. It would need checking the compiler version. The only thing I slightly object to is the use of «-fast» by default on Solaris systems: it's not a recommended setting, and IMO, it should be left to the choice of the builder to add it at build time. ;) I'm doing more and more the same. But I have had big trouble with some c++ progs. But that's out of topic. Ah, yes, C++. Lots of issues there since ABI are not standardized. At least, the Sun compilers-built programs and libs are backward compatible, unlike those built with GCC. But a lot of FOSS contains too many GCCisms to be built by something else. Well, as you said, It's OT here :-) Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Trouble compiling and openssl 0.9.8 d or e on solari10
[EMAIL PROTECTED] a écrit : I'm trying to find the corresponding sparc ones.. I believe I'll get the answer monday. They are those: 120760-12 Sun Studio 11: Compiler Common patch for Sun C C++ F77 F95 120761-03 Sun Studio 11: Patch for Performance Analyzer Tools 121015-04 Sun Studio 11: Patch for Sun C 5.8 compiler 121017-10 Sun Studio 11: Patch for Sun C++ 5.8 compiler 121021-06 Sun Studio 11: Patch for Fortran 95 Dynamic Libraries 121019-05 Sun Studio 11: Patch for Fortran 95 8.2 Compiler 121023-04 Sun Studio 11: Patch for Sun dbx 7.5 Debugger 122135-02 Sun Studio 11: Patch for Sun Performance Library 120760-12 121015-04 And it still does not work. How did you build it? On Solaris SPARC, I simply use that: export \ PATH=/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/SUNWspro/bin:/usr/perl5/bin export LD_OPTIONS=-R/opt/openssl-0.9.8e/lib ./config --prefix=/opt/openssl-0.9.8e shared \ -R/opt/openssl-0.9.8e/lib make make test make install Did you do make test? Was the result ok? I'm so used to gcc... Well, it's your choice. You have both on Solaris. When you'll have spent a few days trying to sort out the various GCC incompatibilities between versions, and how to upgrade one library without breaking others, you'll understand what I mean. Been there, done that, gave up GCC when possible. Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Trouble compiling and openssl 0.9.8 d or e on solari10
Frederic Goudal a écrit : I'm in trouble with openlls 0.9.8 on solaris10 : I compile it either witch gcc or sun cc (studio11), and when I try an s_client command on our web server I got the following error : Did you patch Studio 11? the original version had issues with OpenSSL when built with -fast (as OpenSSL does by default). It built, but then «make test» failed. It was one of the flags added by -fast (I can't remember which) that was the cause. With the most recent patches, there's no such problem, and at least, it works for me (Solaris 10 U3 x64 / Studio 11 w/ patches / OpenSSL 0.9.8e). $ ./openssl s_client -host www.enseirb.fr -port 443 CONNECTED(0004) depth=1 /C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=FR/O=0330196J/CN=www.enseirb.fr/[EMAIL PROTECTED] i:/C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] 1 s:/C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] i:/C=FR/O=CRU/CN=ac-racine/[EMAIL PROTECTED] --- Server certificate -BEGIN CERTIFICATE- Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Trouble compiling and openssl 0.9.8 d or e on solari10
[EMAIL PROTECTED] a écrit : I don't know. Which patch ? Those are the latest for Studio 11 on Solaris x86: 120759-10 Sun Studio 11_x86: Sun Compiler Common patch for x86 backend 120762-03 Sun Studio 11_x86: Patch for Performance Analyzer Tools 121016-05 Sun Studio 11_x86: Patch for Sun C_x86 5.8 Compiler 121018-10 Sun Studio 11_x86: Patch for Sun C++ 5.8 compiler 121020-05 Sun Studio 11_x86: Patch for x86 Fortran 95 8.2 Compiler 121022-03 Sun Studio 11_x86: Patch for Fortran 95 Dynamic Libraries 121616-04 Sun Studio 11_x86: Patch for Sun dbx 7.5_x86 Debugger 122136-02 Sun Studio 11_x86: Performance Library Patch It's probably 121016-05 that fixes that, but better to install them all, I suppose. Well it seems I'm not alone in this case I have seen several case on the web. Btw it's a cipher problem. I have tried with -cipher RC4-SHA and it worked. Is there any gcc version that is supposed to work ? I have tried without -O3 and it did not work. I have no idea. GCC generates much slower code, and brings in libgcc_s dependencies that I don't want to bother with. I've been using only Studio for OpenSSL in years, and the only issue was that optimization bug some months ago. Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL make instal error on Solaris 9
CHASTAIN, TIGE (CONTRACTOR) a e'crit : I was having problems building OpenSSL 0.9.7k on Solaris 9. The error was similar to problems other people have with building it on Solaris 9, but not exactly the same. The error is: installing fips-1.0... [snip] I thought someone might find this of interest. Me. Thanks! I had the same problem with 0.9.7l, it broke my installation process, and I couldn't understand what I had done wrong. Note that I got the same error using gmake, but unlike with make, the install continued to the end. Since make test worked, I guess it's just a matter of gmake considering the issue unimportant. installing fipsld cp: cannot access fipscanister.o cp: cannot access fipscanister.o.sha1 fipscanister.o: No such file or directory gmake[1]: Leaving directory `/var/home/lblume/openssl-0.9.7l/fips-1.0' Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Solaris installation: Text relocation remains...
I've seen you fixed your issue, glad I could help.
PATH issues are common on Solaris, where there are many commonly
installed tools. That's why I always keep a very simple one when
building, to be sure what's used for a given source tarball, SunCC, GCC,
make, gmake, and so on.
Marc Girod a écrit :
export LD_OPTIONS=-R${PREFIX}/lib
Er... What is that?
-Rdir[:dir] Build runtime search path list into executable
I don't believe it should affect... not do I want it in fact.
Anyway, I try...
LD_OPTIONS is used by Solaris ld, it's like its contents are put as
parameters. I add this because at some point, the -R option was not used
in OpenSSL to build the tools, and they couldn't find the libs are runtime.
It doesn't hurt to have it set this way, it's redundant to the -R given
to configure.
And -R is used just for that, so the binaries look there at runtime for
the libs, without the need to set LD_LIBRARY_PATH (which is never a good
solution), or crle (which is not too good either, and tricky).
Laurent
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Solaris installation: Text relocation remains...
Marc Girod a écrit :
I try to build and install on various platforms,
(Solaris sparcv9, HP-UX, AIX), to a non-standard path,
for use with subversion.
A first attempt showed me that svn expected shared libraries,
so that I try to produce them, first on Solaris.
My build fails at link time with 'text relocation' errors,
which doesn't prevent 'make test' from succeeding!?
[snip]
I'd be glad if somebody could tell me what I do wrong...
Thanks,
I can't say I'm sure, because the only problems I've had were with
shared libs, not the static ones.
FWIW, I can tell you that the following commands do work for me, Solaris
8 to 10, SPARC x86, Studio 9 to 11, OpenSSL 0.9.7 and 0.9.8.
export PATH=/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/SUNWspro/bin:/usr/perl5/bin
export LD_OPTIONS=-R${PREFIX}/lib
./config --prefix=${PREFIX} shared \
-R${PREFIX}/lib
make
make test
make install
You should also check that there's nothing in the build environment that
could cause a collision with an older version.
Laurent
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Runpath definition missing for libssl.so
Andreas Almroth wrote: As it is Solaris, use export LD_OPTIONS='-R/usr/local/openssl-0.9.7g/lib -L/usr/local/openssl-0.9.7g/lib' The linker will take that into consideration, and if you do a dump -Lv on the output file, the RUNPATH should be included. I confirm that that fix is perfect for me. I still thinks it's probably a flaw in the Makefile that my -R parameter was used for bin/openssl, and not lib/libssl.so. Anyway, looks good now, thanks again! Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Runpath definition missing for libssl.so
Hello all, I've got a relatively minor problem with OpenSSL linking, it may be a flaw in the configure script, or just me not finding the right option. Here is is: I want to build OpenSSL with an integrated linker runpath, so I don't need LD_LIBRARY_PATH or crle hacks. Since some OpenSSL binaries depend on the library itself, I built it this way: ./config --prefix=/usr/local/openssl-0.9.7g shared \ -R/usr/local/openssl-0.9.7g/lib However, it seems it's not using my -R parameter when linking libssl.so: $ ldd lib/libssl.so libcrypto.so.0.9.7 =(file not found) libsocket.so.1 =/usr/lib/libsocket.so.1 It does work for the openssl binary, though: $ ldd bin/openssl libssl.so.0.9.7 = /usr/local/openssl-0.9.7g/lib/libssl.so.0.9.7 libcrypto.so.0.9.7 = /usr/local/openssl-0.9.7g/lib/libcrypto.so.0.9.7 I did a very small hack to my Makefile: $ diff Makefile.bak Makefile 268c268 $(MAKE) SHLIBDIRS=ssl SHLIBDEPS='-lcrypto' build-shared; \ --- $(MAKE) SHLIBDIRS=ssl SHLIBDEPS='-lcrypto -R/usr/local/openssl-0.9.7g/lib' build-shared; \ And now that works: $ ldd lib/libssl.so libcrypto.so.0.9.7 = /usr/local/openssl-0.9.7g/lib/libcrypto.so.0.9.7 Any idea on what would be the Right Way to do it? Is there another parameter I could give to ./config? This on a Solaris 9 box, using SunCC. Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Runpath definition missing for libssl.so
prakash babu wrote: *Solution 1 :* Create a symbolic link in the system directory for libcrypto.so and libssl.so ln -s /usr/local/openssl-0.9.7g/lib/libcrypto.so /usr/lib/libcrypto.so ln -s /usr/local/openssl-0.9.7g/lib/libssl.so /usr/lib/libssl.so Evil. This is a sure road to troubles at some point (I know, some dumb sysadmins have messed with a few boxes in such ways before I arrived, they're a real PITA to update now). *Solution 2* Specify a embedded path for the library using the flag* -Wl,+b /usr/local/openssl-0.9.7g/lib* (not sure for SunCC) Yes, but how do I pass it along using the config script? -R should have done it. Thanks for answering! Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Runpath definition missing for libssl.so
Andreas Almroth wrote: As it is Solaris, use export LD_OPTIONS='-R/usr/local/openssl-0.9.7g/lib -L/usr/local/openssl-0.9.7g/lib' The linker will take that into consideration, and if you do a dump -Lv on the output file, the RUNPATH should be included. *smacks head* Ok, I wonder how I managed to never notice that in the man... Thanks a *lot*! Definitely sounds like a clean solution, that'll avoid a lot of hassle, there and for other, more broken Makefiles as well. I'll add that to my notes tomorrow. Laurent -- A hundred thousand lemmings can't be wrong! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Install problem: file is symlink to itself instead of real file
I think this is an install problem, but I'm not familiar enough with the way *.pod are converted to man to find out where it comes from. On installing 0.9.7c, the file EVP_BytesToKey.3 is a link to itself. # ls -l /opt/openssl-0.9.7c/ssl/man/man3/EVP_BytesToKey.3 lrwxrwxrwx 1 root other 16 Oct 1 14:35 /opt/openssl-0.9.7c/ssl/man/man3/EVP_BytesToKey.3 - EVP_BytesToKey.3 On 0.9.7b, the file was a real one: # ls -l /opt/openssl-0.9.7b/ssl/man/man3/EVP_BytesToKey.3 -rw-r--r-- 1 root other 6572 Apr 14 14:40 /opt/openssl-0.9.7b/ssl/man/man3/EVP_BytesToKey.3 If it matters, syste is a Solaris 8, compiler is GCC 2.95.3, and I used the same options to configure: ./config --prefix=/opt/openssl-0.9.7c shared I noticed the problem when doing a chmod -R on the directory, it complained about the infinite loop. No big deal, of course, but if it is an install script problem, better correct it! Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Compiling Errors linking OpenSSL
Victor wrote: Suggestion - add /usr/ccs/bin to your path instead of putting it on the configure line. Also, I'd go with the default as and ld - not ccs/bin. But this likely isn't your problem, just a suggestion. I used it because that's what sunfreeware did too, doesn't seem to have any affect. It's fine on Solaris, where /usr/ccs/bin/as and /usr/ccs/bin/ld are the default tools (opposed to GNU's, which might be in /opt/sfw/bin). Nothing... it can't find it... What am I doing wrong? It's obviously my environment. GCC from sunfreeware installed in usr/local, can it be looking at different includes and ignoring? But That can't be because I set -I/usr/include and it's definately looking at /usr/local, and there is a link there, still, no dice... FWIW: since I switched to GCC 3.3, on Solaris 9, I've got to add '-lgcc_s', and sometimes '-lstdc++' when I compile. I usually do it the 'easy' way, ie, I put it in LDFLAGS, CFLAGS, CXXFLAGS. I do not need to add -L/path/to/gcc/lib, though. That one I added to crle(1) so it's found at runtime. I compiled GCC 3.3 so it uses GNU binutils, not Sun, though. Not sure it can make a difference with OpenSSL... Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Compiling Errors linking OpenSSL
Victor wrote: Yes, it does exist. And yes, setting LD_LIBRARY_PATH does fix things. It wasn't set. It does seem that openssl was clear of any wrong doing, I am sorry to have posted offtopic. But you guys have been really helpful. Technically, the -L arguments should have done what LD_LIBRARY_PATH did. I'll take that to the solaris forum. It seems something just might be screwed up in this environment Ah, no, -L did the right thing: the test program were linked against what was needed. But LD_LIBRARY_PATH (as crle(1)) is for runtime link, ie, even if the test program is linked against the right lib, it may not find it when it's run (most ./configure say program was linked but could not run, something like that). -R should have done that, though, but in some cases, putting it in CFLAGS is not enough, because only LDFLAGS is used when linking. From what I understand, LD_LIBRARY_PATH is not always a good way of working wiht things, but seems much eaiser than failed builds :) http://www.visi.com/~barr/ldpath.html Well, on Solaris, rather than using LD_LIBRARY_PATH, I'd advise you to try crle(1). Carefully, because breaking it might harm your system's health :-) Many people also think that only -R should be used. Out of this slightly off-topic thread on how to compile OpenSSL on Solaris :-) Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: trouble compiling
Wayne Thomas wrote: I am attempting to compile openssl-0.9.7 on my Solaris 8 Sun Blade 100 with simply ./config and make. The following error occurs: /usr/ucbinclude/signal.h, line 49: syntax error before or at: int /usr/ucbinclude/signal.h, line 49: warning: undefined or missing type This is wrong, the ucb directories (/usr/ucb, /usr/ucbinclude, /usr/ucblib) are for backward compatibility with BSD-based SunOS 4.x, and should never be used for System V-based Solaris. You should check that none of them appear in PATH, CFLAGS, CPPFLAGS, LDFLAGS, or any other environement variable before starting ./configure or make. The only tool that's commonly used is /usr/ucb/install, but it's automatically detected by ./configure, so there no need to put it in the PATH. HTH, Laurent -- IRI-Secodip www.infores.com 4, rue André Derain mailto:[EMAIL PROTECTED] 78240 Chambourcy tel: +33 (0) 130 06 26 52 France fax: +33 (0) 130 65 09 45 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
