ocsp responder certificate generation documentation
Hi, There is nothing (that I could find) in the ocsp(1) doc on how to generate OCSP responder certificates with openssl. In the openssl.cnf you need: [ ocsp_cert ] extendedKeyUsage = OCSP Signing then add -extensions ocsp_cert on the openssl ca command to generate the cert. Note the space in the OID name! Using OCSPsigning doesn't work. There is also an unrelated mistake in the doc: OCSP Response verification ... Initially the OCSP responder certificate is located and the signature on the OCSP request checked using the responder certificate's public key. Should be ... and the signature on the OCSP response checked OCSP request checking is something different. Regards, Simon McMahon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1381] [PATCH] set rpath on shared library for openssl command proper loading
Platform: NetBSD 1.6.1 x86 (full ./testlog attached below) OpenSSL: 0.9.8b openssl command fails to load, when built with libssl and libprypto as both shared, and the OS tries a good job on finding shared library dependencies on runtime. [EMAIL PROTECTED] /usr/ssl/bin/openssl Shared object libcrypto.so.0.9.8 not found Standard problems, such as missing RPATH in the executable, is already eliminated. What is happening: 1) openssl executable is built with RPATH=/usr/ssl/lib, and NEEDED libssl.so.0.9.8, libcrypto.so.0.9.8, libc.so.12 . 2) The dynamic loader first pulls in libssl.so.0.9.8 and libcrypto.so.0.9.8, using the executable's RPATH=/usr/ssl/lib as the search path, which succeeds in loading /usr/ssl/lib/libssl.so.0.9.8 and /usr/ssl/lib/libcrypto.so.0.9.8 . 3) The pulled in libssl.so.0.9.8 is built with NEEDED libcrypto.so.0.9.8, and no RPATH. 4) The dynamic loader thus tries to load libcrypto.so.0.9.8, this time using the default search path only, which tries for only /usr/lib/libcrypto.so.0.9.8, and fails. (This particular loader seems not try to compare filename or signature for already loaded library) Setting LD_DEBUG=1 will reveal the steps: [EMAIL PROTECTED] env LD_DEBUG=1 /usr/ssl/bin/openssl version processing mapping libm.so.0 machdep.fpu_present 1:libm387.so.0,libm.so.0 library libm.so.0 sysctl machdep.fpu_present sysctl 7, 1 sysctl 7, 2 library libm387.so.0 library libm.so.0 key 1 /usr/libexec/ld.elf_so is initialized, base address = 0x480a2000 processing main program's program header added path /usr/ssl/lib RPATH of openssl preloading objects loading needed objects load by name libssl.so.0.9.8 0x480af000 Searching for libssl.so.0.9.8 (0x480af200) request by openssl Trying /usr/ssl/lib/libssl.so.0.9.8 0x480b5000 .. 0x480eefff: /usr/ssl/lib/libssl.so.0.9.8 load by name libcrypto.so.0.9.8 0x480af000 Searching for libcrypto.so.0.9.8 (0x480af200) request by openssl Trying /usr/ssl/lib/libcrypto.so.0.9.8 0x480ef000 .. 0x48212fff: /usr/ssl/lib/libcrypto.so.0.9.8 load by name libc.so.12 0x480af000 Searching for libc.so.12 (0x480af200) request by openssl Trying /usr/ssl/lib/libc.so.12 Trying /usr/lib/libc.so.12 added path /usr/lib 0x48213000 .. 0x482b2fff: /usr/lib/libc.so.12 load by name libcrypto.so.0.9.8 0x480af000 Searching for libcrypto.so.0.9.8 (0x480af400) request by libssl.so Trying /usr/lib/libcrypto.so.0.9.8 tries only default path, as RPATH of libssl.so is unset Shared object libcrypto.so.0.9.8 not found The attached patch will always add the $(LIBRPATH) to RPATH, also when building a shared library. Workaround without the patch: Build with make SHARED_LDFLAGS=-Wl,-rpath,/usr/ssl/lib Note that the method of recursive searching the dependent shared library is different on each OS; - some os just ignores RPATH on *.so and only use the executable's RPATH (Solaris) - some will use RPATH on the *.so individually for each loaded library (NetBSD) - some will MERGE the current RPATH with the loaded *.so (IRIX) so some platforms are, as the result, unaffected whether there's RPATH on *.so or not. There seems a debate many times on the list about setting RPATH on the shared library, but it should NOT be a problem using ELF platform on normal circumstances. The Normal Circumstances: - When compiling yourselves, you set the correct --prefix, install where it should and off you go. - When the Distributor wants the package to go to different directory, he should first compile with --prefix with that directory. - When the Administrator wants to install the package into directory different from which the package defaults, he should setup LD_LIBRARY_PATH himself. That's what the environ is for. It could be a problem when the admin wants a twisted setup like - the OS has /usr/lib/libz, /usr/lib/libssl and /usr/lib/libcrypto - admin compiled the latest OpenSSL on /usr/local/lib - he has another libz on /usr/local/lib/libz, which may or may not be new (not unrealistic when you had built X11R* yourself) - he wants the executables to use /usr/local/lib/libssl, /usr/local/lib/libcrypto with /usr/lib/libz but the admin already needs to grok with Makefile to properly link with libs he wants. OpenSSL does't have to support that far. OpenSSL self-test report: OpenSSL version: 0.9.8b Last change: When applying a cipher rule check to see if string matc... Options: --prefix=/usr/ssl --openssldir=/usr/ssl enable-shared enable-zlib-dynamic no-asm no-gmp no-idea no-krb5 no-mdc2 no-rc5 OS (uname): NetBSD vega.sra-tohoku.jp 1.6.1 NetBSD 1.6.1 (QQQ) #10: Thu Jun 19 18:21:56 JST 2003 [EMAIL PROTECTED]:/export/NetBSD/sys/arch/i386/compile/QQQ i386 OS (config): i686-whatever-netbsd Target (default): BSD-x86-elf Target: BSD-x86-elf Compiler:
Re: [openssl.org #1381] [PATCH] set rpath on shared library for openssl command proper loading
Setting a built-in shared library search path should be optional. If you build a shared library based openssl dist for inclusion in a software distribution packet that can be installed in another location on the target machine you don't want a built-in path to the install location on the build machine. I know that on some platforms it can be very hard to avoid that the linker automatically includes a search path to the location of the shared libraries at link time, but when it is possible I think it should be made optional. /leif [EMAIL PROTECTED] via RT wrote: Platform: NetBSD 1.6.1 x86 (full ./testlog attached below) OpenSSL: 0.9.8b openssl command fails to load, when built with libssl and libprypto as both shared, and the OS tries a good job on finding shared library dependencies on runtime. [EMAIL PROTECTED] /usr/ssl/bin/openssl Shared object "libcrypto.so.0.9.8" not found Standard problems, such as missing RPATH in the executable, is already eliminated. What is happening: 1) openssl executable is built with RPATH=/usr/ssl/lib, and NEEDED libssl.so.0.9.8, libcrypto.so.0.9.8, libc.so.12 . 2) The dynamic loader first pulls in libssl.so.0.9.8 and libcrypto.so.0.9.8, using the executable's RPATH=/usr/ssl/lib as the search path, which succeeds in loading /usr/ssl/lib/libssl.so.0.9.8 and /usr/ssl/lib/libcrypto.so.0.9.8 . 3) The pulled in libssl.so.0.9.8 is built with NEEDED libcrypto.so.0.9.8, and no RPATH. 4) The dynamic loader thus tries to load libcrypto.so.0.9.8, this time using the default search path only, which tries for only /usr/lib/libcrypto.so.0.9.8, and fails. (This particular loader seems not try to compare filename or signature for already loaded library) Setting LD_DEBUG=1 will reveal the steps: [EMAIL PROTECTED] env LD_DEBUG=1 /usr/ssl/bin/openssl version processing mapping "libm.so.0 machdep.fpu_present 1:libm387.so.0,libm.so.0 " library "libm.so.0" sysctl "machdep.fpu_present" sysctl 7, 1 sysctl 7, 2 library "libm387.so.0" library "libm.so.0" key "1" /usr/libexec/ld.elf_so is initialized, base address = 0x480a2000 processing main program's program header added path "/usr/ssl/lib" RPATH of openssl preloading objects loading needed objects load by name libssl.so.0.9.8 0x480af000 Searching for "libssl.so.0.9.8" (0x480af200) request by openssl Trying "/usr/ssl/lib/libssl.so.0.9.8" 0x480b5000 .. 0x480eefff: /usr/ssl/lib/libssl.so.0.9.8 load by name libcrypto.so.0.9.8 0x480af000 Searching for "libcrypto.so.0.9.8" (0x480af200) request by openssl Trying "/usr/ssl/lib/libcrypto.so.0.9.8" 0x480ef000 .. 0x48212fff: /usr/ssl/lib/libcrypto.so.0.9.8 load by name libc.so.12 0x480af000 Searching for "libc.so.12" (0x480af200) request by openssl Trying "/usr/ssl/lib/libc.so.12" Trying "/usr/lib/libc.so.12" added path "/usr/lib" 0x48213000 .. 0x482b2fff: /usr/lib/libc.so.12 load by name libcrypto.so.0.9.8 0x480af000 Searching for "libcrypto.so.0.9.8" (0x480af400) request by libssl.so Trying "/usr/lib/libcrypto.so.0.9.8" tries only default path, as RPATH of libssl.so is unset Shared object "libcrypto.so.0.9.8" not found The attached patch will always add the $(LIBRPATH) to RPATH, also when building a shared library. Workaround without the patch: Build with "make SHARED_LDFLAGS=-Wl,-rpath,/usr/ssl/lib" Note that the method of recursive searching the dependent shared library is different on each OS; - some os just ignores RPATH on *.so and only use the executable's RPATH (Solaris) - some will use RPATH on the *.so individually for each loaded library (NetBSD) - some will MERGE the current RPATH with the loaded *.so (IRIX) so some platforms are, as the result, unaffected whether there's RPATH on *.so or not. There seems a debate many times on the list about setting RPATH on the shared library, but it should NOT be a problem using ELF platform on normal circumstances. The Normal Circumstances: - When compiling yourselves, you set the correct --prefix, install where it should and off you go. - When the Distributor wants the package to go to different directory, he should first compile with --prefix with that directory. - When the Administrator wants to install the package into directory different from which the package defaults, he should setup LD_LIBRARY_PATH himself. That's what the environ is for. It could be a problem when the admin wants a twisted setup like - the OS has /usr/lib/libz, /usr/lib/libssl and /usr/lib/libcrypto - admin compiled the latest OpenSSL on /usr/local/lib - he has another libz on /usr/local/lib/libz, which may or may not be new (not unrealistic when you had built X11R* yourself) - he wants the executables to use /usr/local/lib/libssl, /usr/local/lib/libcrypto with /usr/lib/libz but the admin already needs to grok with Makefile to properly link with libs he wants. OpenSSL does't
Re: openssl ca - configuration file options - oid_section (0.9.8b)
On Thu, Aug 31, 2006, Simon McMahon wrote: Hi, I must have something wrong in the configuration file and there dont seem to be samples to cover additional OIDs. I just want to know how to use the 'oid_section' in the openssl.cnf file correctly. Btw, I am simply adding the OCSPsigning extendedKeyUsage attribute to the cert. I can do that but not using the oid that I defined. I tried adding the following lines to the standard (supplied) openssl.cnf file: [ CA_default ] oid_section = oids [ oids ] OCSPsigning = 1.3.6.1.5.5.7.3.9 [ ocsp_cert ] extendedKeyUsage = OCSPsigning Note: the sections have other stuff in them also - I am just showing the additions. Then running: openssl ca -in csr.pem -out xcert.pem -extensions ocsp_cert gives output: Error Loading extension section ocsp_cert 2920:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:. \crypto\asn1\a_object.c:108: 2920:error:2206706E:X509 V3 routines:V2I_EXTENDED_KEY_USAGE:invalid object ident ifier:.\crypto\x509v3\v3_extku.c:135:section:,name:OCSPsigning,value: 2920:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:.\crypt o\x509v3\v3_conf.c:93:name=extendedKeyUsage, value=OCSPsigning If I switch to: [ ocsp_cert ] extendedKeyUsage = 1.3.6.1.5.5.7.3.9 It works fine giving output: Certificate Details: ... X509v3 extensions: ... X509v3 Extended Key Usage: OCSP Signing How do I get the oid_section to work so I can use those oids that I defined? First this should be in openssl-users... The old oid_section stuff is now obsolete. The preferred method is via the config module section which then works for all the openssl utility applications and other config module savvy apps too. See: http://www.openssl.org/docs/apps/config.html for details and examples. However the OID is already part of OpenSSL so it doesn't need to be added: it is called OCSPSigning though. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Crash inside SMIME_read_PKCS7 if input is not MIME
Mats Nilsson wrote: Hi [OpenSSL-0.9.7i, Windows XP, sp2] While hacking limited support for CMS compression on top of OpenSSL, I accidentally sent a BER encoded CMS file (using compression) into SMIME_read_PKCS7, which caused an access violation somewhere in: [Visual studio 6 stack dump] mime_param_cmp(const MIME_PARAM * const * 0x00439888, const MIME_PARAM * const * 0x004398e0) line 658 + 20 bytes MSVCRT! 77c36ff7() sk_find(stack_st * 0x004375e8, char * 0x0012f8ec) line 226 + 23 bytes SMIME_read_PKCS7(bio_st * 0x0040557c, bio_st * * 0x00437418) line 256 + 19 bytes Apparently, it found some bizarre headers in the binary stream, but was unable to search for a content-type header. Also using the command line, I managed to induce a similar crash: openssl smime -verify -in bash.compressed where 'bash.compressed' is the BER encoded compressed test file (a compressed 'bash' binary in a CMS envelope). Available upon request. could you send me the data as I was unable to reproduce this problem with arbitrary data. Do you have the same problem with newer openssl version ? Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1380] x86cpuid-elf.s does not compile
After commit of crypto/perlasm/x86unix.pl v.1.45: $ ./config -g shared zlib make ... gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -march=pentium -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM -c -o x86cpuid-elf.o x86cpuid-elf.s x86cpuid-elf.s: Assembler messages: x86cpuid-elf.s:69: Error: symbol `.PIC_me_up' is already defined x86cpuid-elf.s:135: Error: symbol `.PIC_me_up' is already defined x86cpuid-elf.s:220: Error: symbol `.PIC_me_up' is already defined http://cvs.openssl.org/chngview?cn=15510. I'm dismissing the case. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl ca - configuration file options - oid_section (0.9.8b)
Hi Steve, Thanks for your reply. I found out what I did wrong. Dr Stephen N. Henson wrote: for details and examples. However the OID is already part of OpenSSL so it doesn't need to be added: it is called OCSPSigning though. It appears to be called OCSP Signing which caused me a bit of a problem since it is most often referred to without the space. Maybe the space could be dropped? Cheers, Simon McMahon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl ca - configuration file options - oid_section (0.9.8b)
On Fri, Sep 01, 2006, Simon McMahon wrote: Hi Steve, Thanks for your reply. I found out what I did wrong. Dr Stephen N. Henson wrote: for details and examples. However the OID is already part of OpenSSL so it doesn't need to be added: it is called OCSPSigning though. It appears to be called OCSP Signing which caused me a bit of a problem since it is most often referred to without the space. Maybe the space could be dropped? OIDs have two names: a short name and a long name. The short name is normally used in config files and command line arguments whereas the long name is normally used for human readable text output. Either type can be used but they are case sensitive. The short name is OCSPSigning and the long name OCSP Signing. The definitions are in crypto/objects/objects.txt Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1382] [patch] Windows ms/uplink.c - wrong variable used
Typo in ms\uplink.c in openssl-0.9.8b If the static 'applinktable' is already initialized, the block which sets the local 'p' is not executed. After this block, 'applinktable' should be used to lookup the max index and the function address. Curiously, this doesn't cause problems when compiled with VC8 /MD. It causes access violations when compiled with the static C runtime library - /MT. Patch follows. -tom- Index: ms/uplink.c === --- ms/uplink.c (revision 1) +++ ms/uplink.c (working copy) @@ -72,10 +72,10 @@ applinktable = p; } - if (index (int)p[0]) + if (index (int)applinktable[0]) break; - if (p[index]) func = p[index]; + if (applinktable[index]) func = applinktable[index]; } while (0); table[index] = func; __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
