Re: Issue with Private key with FIPS enabled openssl

2009-03-12 Thread Steve Marquess

Kyle Hamilton wrote:

It was my mistake, I had misunderstood that DES itself was not allowed
and therefore derivatives of it were not allowed either.
  


While 3DES is currently legal we can expect it to be phased out at some 
point just as plain DES has been, so AES is the better choice where you 
are free to choose between them.


Unfortunately some legacy software that you may need to interoperate 
with does not support AES.


-Steve M.

--
Steve Marquess
Veridical Systems, Inc.
marqu...@veridicalsystems.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: AIX 5.3 - FIPS_mode_set fails due to RSA self-test failure

2009-03-12 Thread Steve Marquess

Jeremy Regan wrote:

Hello,

I was able to build the FIPS 1.2 software successfully using

./config --prefix=/apps/fips_build/fips-1.2-install fipscanisterbuild
no-asm
make
make install

  
Standard nag: you built it successfully in the sense that it compiled 
and linked without error, but you can't represent the result as FIPS 
140-2 validated. The Security Policy is very specific about the fact 
that only two options to ./config are allowed, no-asm and 
fipscanisterbuild.


What you can do is build it as mandated and then copy the resulting 
module where you want it to go. I know the difference seems silly, but 
the CMVP was very adamant on that point when we were working the first 
validation.


-Steve M.

--
Steve Marquess
Veridical Systems, Inc.
marqu...@veridicalsystems.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: AIX 5.3 - FIPS_mode_set fails due to RSA self-test failure

2009-03-12 Thread rajan chittil
This is the build script i have used to build the openssl fips 1.2  and
openssl 9.8j . try this and let me know if this help you.



#!/bin/ksh



SOURCEDIR=$(pwd)



SOURCE0=$SOURCEDIR/openssl-fips-1.2.tar.gz

SOURCE1=$SOURCEDIR/openssl-0.9.8j.tar.gz







function openssl_fips_workaround_object_mode

{

  #

  # config uses /usr/bin/getconf to determine object mode.  We will set
$PATH

  # to find our own getconf first.  This getconf just returns $OBJECT_MODE.

  #

  cat getconf \EOF

#!/bin/ksh



if [[ $1 = KERNEL_BITMODE ]]; then

  echo ${OBJECT_MODE:-32};

  exit 0;

else

  exec /usr/bin/getconf $*

fi

EOF



  chmod +x getconf

}





function extract_patch_build

{

  set -x



  #

  # First we build openssl-fips.

  #

  rm -rf openssl-fips-1.2

  gunzip -c $SOURCE0 | tar -xf -

  cd openssl-fips-1.2

  openssl_fips_workaround_object_mode

  export OLDPATH=$PATH PATH=$(pwd):$PATH



  ./config fipscanisterbuild no-asm

  make



  export PATH=$OLDPATH

  fipslibdir=$(pwd)/fips

  cd ..



  #

  # Second, we build FIPS compatible openssl.

  #

  rm -rf openssl-0.9.8j

  gunzip -c $SOURCE1 | tar -xf -

  cd openssl-0.9.8j



  ./Configure -DSSL_ALLOW_ADH --prefix=/usr --openssldir=/var/ssl
--with-fipslibdir=$fipslibdir fips no-idea no-rc5 no-ec no-symlinks shared
threads aix${1}-xlc_r

  make depend

  make



  touch libcrypto.a

  make

  cd ..

}





#

# main

#

set -x

extract_patch_build



#

# build 64-bit in subdir 64

#

mkdir 64

cd 64

OBJECT_MODE=64 extract_patch_build 64

cd ..



#

# Add the 64-bit shared objects to the archives.

# Also add the fipscanisters.

#

cd openssl-0.9.8j

cp ../64/openssl-0.9.8j/libssl.so.0.9.8 libssl64.so.0.9.8

cp ../64/openssl-0.9.8j/libcrypto.so.0.9.8 libcrypto64.so.0.9.8

cp ../openssl-fips-1.2/fips/fipscanister.o .

cp ../openssl-fips-1.2/fips/fipscanister.o.sha1 .



rm -f libssl.so libcrypto.so libssl*.a libcrypto*.a

export OBJECT_MODE=32_64

/usr/bin/ar -qv libssl.a libssl.so.0.9.8 libssl64.so.0.9.8

/usr/bin/ar -qv libcrypto.a libcrypto.so.0.9.8 libcrypto64.so.0.9.8
fipscanister.o ../64/openssl-fips-1.2/fips/fipscanister.o



Try this build script .I will generate both 32 bit as well as 64 bit fips
object module with out changing any make file




On Thu, Mar 12, 2009 at 2:31 AM, Steve Marquess 
marqu...@veridicalsystems.com wrote:

 Jeremy Regan wrote:

 Hello,

 I was able to build the FIPS 1.2 software successfully using

 ./config --prefix=/apps/fips_build/fips-1.2-install fipscanisterbuild
 no-asm
 make
 make install



 Standard nag: you built it successfully in the sense that it compiled and
 linked without error, but you can't represent the result as FIPS 140-2
 validated. The Security Policy is very specific about the fact that only two
 options to ./config are allowed, no-asm and fipscanisterbuild.

 What you can do is build it as mandated and then copy the resulting module
 where you want it to go. I know the difference seems silly, but the CMVP was
 very adamant on that point when we were working the first validation.

 -Steve M.

 --
 Steve Marquess
 Veridical Systems, Inc.
 marqu...@veridicalsystems.com

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org



Certificate path validation and EKU's

2009-03-12 Thread Steffen Fiksdal

Hi!

I am currently looking into the usage of EKU's for CA certificates and 
hope someone of you guys can help me.


Given the following scenario:
1) A CA certificate with EKU Client Authentication.
2) An enterprise certificate issued by the CA certificate in 1) with EKU 
Client Authentication and Server Authentication


And my questions are:
1) What is the purpose of setting EKU's for CA certificates?
2) Is the scenario above allowed ?
3) Should a certificate chain validation of the above scenario succeed?

I tried the openssl verify -purpose sslclient on the above scenario and 
the validation succeeded. If openssl says it's ok, then it is ok :)


My reason for asking is that we struggle with a chain validation of the 
above scenario using some other technology...



Best regards,
Steffen Fiksdal

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Certificate path validation and EKU's

2009-03-12 Thread Patrick Patterson
Hi Steffen:

On March 12, 2009 06:41:33 am Steffen Fiksdal wrote:
 Hi!

 I am currently looking into the usage of EKU's for CA certificates and
 hope someone of you guys can help me.

 Given the following scenario:
 1) A CA certificate with EKU Client Authentication.
This would mean that the CA certificate is ONLY usable for Client 
Authentication - as is stated in RFC5280:

If the extension is present, then the certificate MUST only be used
for one of the purposes indicated.

It says earlier:

In general, this extension will appear only in end entity certificates.

And, specifically, it mentions for CA Certificates:

 Certificate using
   applications MAY require that the extended key usage extension be
   present and that a particular purpose be indicated in order for the
   certificate to be acceptable to that application.

   If a CA includes extended key usages to satisfy such applications,
   but does not wish to restrict usages of the key, the CA can include
   the special KeyPurposeId anyExtendedKeyUsage in addition to the
   particular key purposes required by the applications.

So, while what you are doing is not, strictly speaking, disallowed by the RFC, 
it is certainly NOT encouraged.

 2) An enterprise certificate issued by the CA certificate in 1) with EKU
 Client Authentication and Server Authentication

I presume that you mean an End Entity Certificate... 

 And my questions are:
 1) What is the purpose of setting EKU's for CA certificates?

These isn't one - the EKU values in CA Certificates should be empty as 
indicated above. Otherwise you can have some very strange effects, depending 
on your interpretation of the RFC.

 2) Is the scenario above allowed ?

As I mentioned above, it may be allowed, but it would mean that the CA 
certificate is only usable for (depending on your interpretation):

1) Performing Client Authentication ONLY with the CA Certificate (i.e.: you 
couldn't use the CA certificate to sign other certificates)

or

2) That the CA is *ONLY* allowed to issue certificates that are used for 
client Authentication *ONLY*.

 3) Should a certificate chain validation of the above scenario succeed?

I would say probably not - since the serverAuth Key Usage is outside of 
the allowed uses for the CA Certificate.

 I tried the openssl verify -purpose sslclient on the above scenario and
 the validation succeeded. If openssl says it's ok, then it is ok :)

 My reason for asking is that we struggle with a chain validation of the
 above scenario using some other technology...

Please keep in mind that the path validation built into OpenSSL is fairly 
rudimentary, and doesn't fully implement the entire algorithm in RFC5280 
(unless, I believe, you a) are somehow able to provide all of the CRL or OCSP 
information, and b) you are using the most up to date OpenSSL, which has the 
understanding of nameConstraints, policyMappings, and even then, the support 
is somewhat hit and miss if you have nameConstraints set to critical ), so 
relying on it to perform 100% correct RFC3280/RFC5280 PDVal is not always 
possible.

If you are looking for a tool that more fully supports full PDVal (and which 
integrates with OpenSSL), you may want to take a look at Pathfinder :)

http://www.carillon.ca/tools/pathfinder.php

Have fun.

-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: AIX 5.3 - FIPS_mode_set fails due to RSA self-test failure

2009-03-12 Thread Jeremy Regan
 

Thank you all again for your valuable information.  I have been working
with our system administrators on the point of running make install with
sudo privileges, they are recalcitrant in allowing me to put software
into the machine that I cannot give them exact instructions on how to
build on their own and install, and as you know it is not that
straightforward =) and I am also not used to that kind of restriction.
In the meantime, I will attempt use Rajan's script to get around the
object mode problem.  Once I know that works, then I will be able to
re-do the install and build with the root privileges.  An interesting
side question - if the machine has the openssl and openssl-dev AIX RPM
packages installed, would this represent any conflict when trying to use
the SSH installation once I have built my own openssl and installed it? 

 

Regards,

Jeremy R.



PBE Key creation

2009-03-12 Thread brechmos

I am relatively new at openssl and am just figuring out its power.  One thing
I do not understand is the key creation.  For example,

$ openssl des3 -nosalt -P -in bob.txt 

and I type in the password 1234 (not my normal password :-) and it comes up
with:

Verifying - enter des-ede3-cbc encryption password:
key=81DC9BDB52D04DC20036DBD8313ED055CC5776D16A1FB6E4
iv =AFA34B18395DA656

Is there a way to create the key shown above using an ssl command line?

$ echo 1234 | openssl not sure here

Any suggestion would be appreciated.
-- 
View this message in context: 
http://www.nabble.com/PBE-Key-creation-tp22476230p22476230.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


native ssl version for fips 1.2 compile

2009-03-12 Thread ABDUL BASIT
Hello,

is there any requirement that a particular version of openssl must be
installed on the host where
you are compiling openssl FIPS 1.2?

I am trying to compile openssl FIPS 1.2 natively on powerpc, and I have
openssl 0.9.8g on this system.
I am following the build instructions in user guide (./config
fipscanisterbuild no-asm; make), the object
module fipscanister.o is getting built, but after the build create the
shared library libcrypto.so.0.9.8 it then
calls fips_premain_dso to sign it, and fips_premain_dso is hung forever, on
my trace back, I found that
when in fips_premain.c BIO_new(BIO_s_file()); is called, it blocks forever.

please help !

Thanks,
- basit


Re: native ssl version for fips 1.2 compile

2009-03-12 Thread Kyle Hamilton
There is no prerequisite (other than compiler and development
environment) for building FIPS 1.2.

You *MUST* have OpenSSL 0.9.8j or later to build a version of openssl
that includes the resultant fipscanister.

-Kyle H

On Thu, Mar 12, 2009 at 8:06 AM, ABDUL BASIT ba...@basit.pk wrote:
 Hello,

 is there any requirement that a particular version of openssl must be
 installed on the host where
 you are compiling openssl FIPS 1.2?

 I am trying to compile openssl FIPS 1.2 natively on powerpc, and I have
 openssl 0.9.8g on this system.
 I am following the build instructions in user guide (./config
 fipscanisterbuild no-asm; make), the object
 module fipscanister.o is getting built, but after the build create the
 shared library libcrypto.so.0.9.8 it then
 calls fips_premain_dso to sign it, and fips_premain_dso is hung forever, on
 my trace back, I found that
 when in fips_premain.c BIO_new(BIO_s_file()); is called, it blocks forever.

 please help !

 Thanks,
 - basit

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: native ssl version for fips 1.2 compile

2009-03-12 Thread ABDUL BASIT
Kyle, Thanks for quick reply.

my understanding is that the openssl fips-1.2 build will also produce the
shared libraries
(libssl.so.0.9.8 and libcrypto.so.0.9.8) that includes this resultant
fipscanister.o,
so I would just need to link against the resultant shared libraries ??

- Basit


On Thu, Mar 12, 2009 at 11:10 AM, Kyle Hamilton aerow...@gmail.com wrote:

 There is no prerequisite (other than compiler and development
 environment) for building FIPS 1.2.

 You *MUST* have OpenSSL 0.9.8j or later to build a version of openssl
 that includes the resultant fipscanister.

 -Kyle H

 On Thu, Mar 12, 2009 at 8:06 AM, ABDUL BASIT ba...@basit.pk wrote:
  Hello,
 
  is there any requirement that a particular version of openssl must be
  installed on the host where
  you are compiling openssl FIPS 1.2?
 
  I am trying to compile openssl FIPS 1.2 natively on powerpc, and I have
  openssl 0.9.8g on this system.
  I am following the build instructions in user guide (./config
  fipscanisterbuild no-asm; make), the object
  module fipscanister.o is getting built, but after the build create the
  shared library libcrypto.so.0.9.8 it then
  calls fips_premain_dso to sign it, and fips_premain_dso is hung forever,
 on
  my trace back, I found that
  when in fips_premain.c BIO_new(BIO_s_file()); is called, it blocks
 forever.
 
  please help !
 
  Thanks,
  - basit
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org



Re: native ssl version for fips 1.2 compile

2009-03-12 Thread Dr. Stephen Henson
On Thu, Mar 12, 2009, ABDUL BASIT wrote:

 Kyle, Thanks for quick reply.
 
 my understanding is that the openssl fips-1.2 build will also produce the
 shared libraries
 (libssl.so.0.9.8 and libcrypto.so.0.9.8) that includes this resultant
 fipscanister.o,
 so I would just need to link against the resultant shared libraries ??
 

It will but the version of OpenSSL in the 1.2 validated source is older
and lacking many bug fixes. Due to compiler issues with newer versions of
gcc it may well not even work at all.

So linking against OpenSSL 0.9.8j is pretty much mandatory.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: BSD 32-bit FIPS issues

2009-03-12 Thread The Doctor
On Wed, Mar 11, 2009 at 11:51:23AM +0100, Ger Hobbelt wrote:
 On Tue, Mar 10, 2009 at 8:02 PM, The Doctor doc...@doctor.nl2k.ab.ca wrote:
  This is happening again
 
 Holy (beep)!
 
 ... would you do me a favor, please? (and maybe make some others
 happy in the process as well)
 
 I love an essay, but let's just say that the combination of riding the
 bleeding edge of development using snapshots, combined with the
 glaring ability to feed an entire make  make test console output,
 unfiltered for optimum appreciation, produces a rather, ah,
 unprofesssional, impression.
 
 To the point: thank you very much for reporting failures; even more
 thanks when you can strip away obvious (successful?) parts. E.g. all
 those lucky compiler invocations.
 
 Here's how one might go about, reducing cruft in feedback: here's your
 report, reduced to maybe-relevant bits -- and I didn't even do this
 thoroughly; this is the result of a rush job to kill the most obvious
 clutter only:
 
  Script started on Tue Mar 10 12:06:29 2009
  [r...@ns1 /usr/source/openssl-0.9.8-stable-SNAP-20090310]# cat 
  /usr/local/bin/co
  nfigopenssl
 
  ./Configure threads shared experimental-store  enable-capieng enable-cms 
  enable-montasm enable-krb5 enable-tlsext enable-seed  enable-fips fipsdso 
  enable-camellia enable-rfc3779 enable-gmp enable-mdc2 enable-rc5 
  zlib-dynamic --prefix=/usr/ --openssldir=/usr/ BSD-x86-elf -g -O3 -Wall ; 
  make depend
 
  [r...@ns1 /usr/source/openssl-0.9.8-stable-SNAP-20090310]# make  make test
 [...]  make -e PLATFORM='BSD-x86-elf' PROCESSOR=''  CC='gcc'
 CFLAG='-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
 -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O3
 -Wall  -DL_ENDIAN -DTERMIOS -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'
 AS='gcc' ASFLAG='-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
 -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN
 -DHAVE_DLFCN_H -g -O3 -Wall  -DL_ENDIAN -DTERMIOS -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 -c' AR='ar  r'
 PERL='/usr/bin/perl5' RANLIB='/usr/bin/ranlib'   SDIRS='objects
 md2 md4 md5 sha mdc2 hmac ripemd  des aes rc2 rc4 rc5 idea bf cast
 camellia seed  bn ec rsa dsa ecdsa dh ecdh dso engine  buffer bio
 stack lhash rand err  evp asn1 pem x509 x509v3 conf txt_db pkcs7
 pkcs12 comp ocsp ui krb5  store cms pqueue' LIBRPATH='/usr/lib'
 INSTALL_PREFIX=''   INSTALLTOP='/usr' OPENSSLDIR='/usr'
  MAKEDEPEND='$${TOP}/util/domd $${TOP} -MD gcc'
 DEPFLAG='-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_JPAKE'
 MAKEDEPPROG='gcc'   SHARED_LDFLAGS=''
  KRB5_INCLUDES='' LIBKRB5='' EXE_EXT=''
 SHARED_LIBS='libfips.so.0.9.8 libcrypto.so.0.9.8 libssl.so.0.9.8'
 SHLIB_EXT='.so.0.9.8' SHLIB_TARGET='bsd-shared' PEX_LIBS=''
 EX_LIBS=''  CPUID_OBJ='x86cpuid-elf.o'
 BN_ASM='bn86-elf.o co86-elf.o mo86-elf.o' DES_ENC='dx86-elf.o
 yx86-elf.o'   AES_ASM_OBJ='ax86-elf.o'
 BF_ENC='bx86-elf.o' CAST_ENC='c_enc.o'  RC4_ENC='rx86-elf.o
 rc4_skey.o' RC5_ENC='r586-elf.o'SHA1_ASM_OBJ='sx86-elf.o
 s512sse2-elf.o'MD5_ASM_OBJ='mx86-elf.o'
 RMD160_ASM_OBJ='rm86-elf.o' FIPSLIBDIR=''
  FIPSCANLIB=${FIPSCANLIB:-libfips}
 FIPSCANISTERINTERNAL='y'FIPS_EX_OBJ='../crypto/aes/aes_cfb.o
 [...]
  making all in crypto...
 
  ( echo #ifndef MK1MF_BUILD;  echo '  /* auto-generated by crypto/Makefile 
  for crypto/cversion.c */';  echo '  #define CFLAGS gcc -fPIC -DOPENSSL_PIC 
  -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT 
  -DDSO_DLFCN -DHAVE_DLFCN_H -g -O3 -Wall  -DL_ENDIAN -DTERMIOS -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';  echo 
  '  #define PLATFORM BSD-x86-elf';  echo   #define DATE \`LC_ALL=C 
  LC_TIME=C date`\;  echo '#endif' ) buildinf.h
 [...]
  making all in crypto/objects...
 [...]
  testing...
 [...]
 Testing SHA-384 ... passed.
 
 if [ -n libfips ]; then  ../util/shlib_wrap.sh ./fips_shatest 
 SHAmix.r | diff -w SHAmix.x - ;  fi
 
 ERROR:2d06c071:lib=45,func=108,reason=113:file=fips.c:line=276:
 
 1,129d0
 
  [L = 64]
 
  Len = 16
  Msg = 98a1
  MD = 
 74d78642f70ca830bec75fc60a585917e388cfa4cd1d23daab1c4d9ff1010cac3e67275df64db5a6a7c7d0fda24f1fc3eb272678a7c8becff6743ee812129078
 
  Len = 104
  Msg = 35a37a46df4ccbadd815942249
  MD = 
 6f5589ea195e745654885d50de687d7fe682affc8da1fb09e681540525f04ecb93022361a27759b9e272c883564223c5e4ecafeb0daaf1abce6caa4bd4153379
 
  Len = 352
  Msg = 
 a93aed0fa5e163a82c9a934aebaab8180edf7de0b32f0fe99f9c75ec305b24609334cefa372c7c758262dc8f
  MD = 
 

Re: BSD 32-bit FIPS issues

2009-03-12 Thread Michael S. Zick
On Thu March 12 2009, The Doctor wrote:
 On Wed, Mar 11, 2009 at 11:51:23AM +0100, Ger Hobbelt wrote:
  On Tue, Mar 10, 2009 at 8:02 PM, The Doctor doc...@doctor.nl2k.ab.ca 
  wrote:
   This is happening again
  
  Holy (beep)!
  
  ... would you do me a favor, please? (and maybe make some others
  happy in the process as well)
  
  I love an essay, but let's just say that the combination of riding the
  bleeding edge of development using snapshots, combined with the
  glaring ability to feed an entire make  make test console output,
  unfiltered for optimum appreciation, produces a rather, ah,
  unprofesssional, impression.
  
  To the point: thank you very much for reporting failures; even more
  thanks when you can strip away obvious (successful?) parts. E.g. all
  those lucky compiler invocations.
  
  Here's how one might go about, reducing cruft in feedback: here's your
  report, reduced to maybe-relevant bits -- and I didn't even do this
  thoroughly; this is the result of a rush job to kill the most obvious
  clutter only:
  
   Script started on Tue Mar 10 12:06:29 2009
   [r...@ns1 /usr/source/openssl-0.9.8-stable-SNAP-20090310]# cat 
   /usr/local/bin/co
   nfigopenssl
  
   ./Configure threads shared experimental-store  enable-capieng enable-cms 
   enable-montasm enable-krb5 enable-tlsext enable-seed  enable-fips fipsdso 
   enable-camellia enable-rfc3779 enable-gmp enable-mdc2 enable-rc5 
   zlib-dynamic --prefix=/usr/ --openssldir=/usr/ BSD-x86-elf -g -O3 -Wall 
   ; make depend
  
   [r...@ns1 /usr/source/openssl-0.9.8-stable-SNAP-20090310]# make  make 
   test
  [...]  make -e PLATFORM='BSD-x86-elf' PROCESSOR=''  CC='gcc'
  CFLAG='-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
  -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O3
  -Wall  -DL_ENDIAN -DTERMIOS -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'
  AS='gcc' ASFLAG='-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
  -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN
  -DHAVE_DLFCN_H -g -O3 -Wall  -DL_ENDIAN -DTERMIOS -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 -c' AR='ar  r'
  PERL='/usr/bin/perl5' RANLIB='/usr/bin/ranlib'   SDIRS='objects
  md2 md4 md5 sha mdc2 hmac ripemd  des aes rc2 rc4 rc5 idea bf cast
  camellia seed  bn ec rsa dsa ecdsa dh ecdh dso engine  buffer bio
  stack lhash rand err  evp asn1 pem x509 x509v3 conf txt_db pkcs7
  pkcs12 comp ocsp ui krb5  store cms pqueue' LIBRPATH='/usr/lib'
  INSTALL_PREFIX=''   INSTALLTOP='/usr' OPENSSLDIR='/usr'
   MAKEDEPEND='$${TOP}/util/domd $${TOP} -MD gcc'
  DEPFLAG='-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_JPAKE'
  MAKEDEPPROG='gcc'   SHARED_LDFLAGS=''
   KRB5_INCLUDES='' LIBKRB5='' EXE_EXT=''
  SHARED_LIBS='libfips.so.0.9.8 libcrypto.so.0.9.8 libssl.so.0.9.8'
  SHLIB_EXT='.so.0.9.8' SHLIB_TARGET='bsd-shared' PEX_LIBS=''
  EX_LIBS=''  CPUID_OBJ='x86cpuid-elf.o'
  BN_ASM='bn86-elf.o co86-elf.o mo86-elf.o' DES_ENC='dx86-elf.o
  yx86-elf.o'   AES_ASM_OBJ='ax86-elf.o'
  BF_ENC='bx86-elf.o' CAST_ENC='c_enc.o'  RC4_ENC='rx86-elf.o
  rc4_skey.o' RC5_ENC='r586-elf.o'SHA1_ASM_OBJ='sx86-elf.o
  s512sse2-elf.o'MD5_ASM_OBJ='mx86-elf.o'
  RMD160_ASM_OBJ='rm86-elf.o' FIPSLIBDIR=''
   FIPSCANLIB=${FIPSCANLIB:-libfips}
  FIPSCANISTERINTERNAL='y'FIPS_EX_OBJ='../crypto/aes/aes_cfb.o
  [...]
   making all in crypto...
  
   ( echo #ifndef MK1MF_BUILD;  echo '  /* auto-generated by 
   crypto/Makefile for crypto/cversion.c */';  echo '  #define CFLAGS gcc 
   -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread 
   -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O3 -Wall  
   -DL_ENDIAN -DTERMIOS -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';  echo '  #define PLATFORM 
   BSD-x86-elf';  echo   #define DATE \`LC_ALL=C LC_TIME=C date`\;  
   echo '#endif' ) buildinf.h
  [...]
   making all in crypto/objects...
  [...]
   testing...
  [...]
  Testing SHA-384 ... passed.
  
  if [ -n libfips ]; then  ../util/shlib_wrap.sh ./fips_shatest 
  SHAmix.r | diff -w SHAmix.x - ;  fi
  
  ERROR:2d06c071:lib=45,func=108,reason=113:file=fips.c:line=276:
  
  1,129d0
  
   [L = 64]
  
   Len = 16
   Msg = 98a1
   MD = 
  74d78642f70ca830bec75fc60a585917e388cfa4cd1d23daab1c4d9ff1010cac3e67275df64db5a6a7c7d0fda24f1fc3eb272678a7c8becff6743ee812129078
  
   Len = 104
   Msg = 35a37a46df4ccbadd815942249
   MD = 
  6f5589ea195e745654885d50de687d7fe682affc8da1fb09e681540525f04ecb93022361a27759b9e272c883564223c5e4ecafeb0daaf1abce6caa4bd4153379
  
   Len = 352
   Msg = 
  

save an EC_KEY in a file and load it after

2009-03-12 Thread neorom
Hello everybody

I'm doing code with the ECDSA library. I would like to put an EC_KEY
in a file, copy the file to another computer, then load this file and
find again my EC_KEY.
I don't know which functions of openssl to use to pack the EC_KEY
structure in a binary format and then unpack it to recover the initial
EC_KEY in its structure.

Could you please help me,

Regards,

Romain Hinfray
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: BSD 32-bit FIPS issues

2009-03-12 Thread The Doctor
On Thu, Mar 12, 2009 at 11:58:34AM -0500, Michael S. Zick wrote:
 On Thu March 12 2009, The Doctor wrote:
  On Wed, Mar 11, 2009 at 11:51:23AM +0100, Ger Hobbelt wrote:
   On Tue, Mar 10, 2009 at 8:02 PM, The Doctor doc...@doctor.nl2k.ab.ca 
   wrote:
This is happening again
   
   Holy (beep)!
   
   ... would you do me a favor, please? (and maybe make some others
   happy in the process as well)
   
   I love an essay, but let's just say that the combination of riding the
   bleeding edge of development using snapshots, combined with the
   glaring ability to feed an entire make  make test console output,
   unfiltered for optimum appreciation, produces a rather, ah,
   unprofesssional, impression.
   
   To the point: thank you very much for reporting failures; even more
   thanks when you can strip away obvious (successful?) parts. E.g. all
   those lucky compiler invocations.
   
   Here's how one might go about, reducing cruft in feedback: here's your
   report, reduced to maybe-relevant bits -- and I didn't even do this
   thoroughly; this is the result of a rush job to kill the most obvious
   clutter only:
   
Script started on Tue Mar 10 12:06:29 2009
[r...@ns1 /usr/source/openssl-0.9.8-stable-SNAP-20090310]# cat 
/usr/local/bin/co
nfigopenssl
   
./Configure threads shared experimental-store  enable-capieng 
enable-cms enable-montasm enable-krb5 enable-tlsext enable-seed  
enable-fips fipsdso enable-camellia enable-rfc3779 enable-gmp 
enable-mdc2 enable-rc5 zlib-dynamic --prefix=/usr/ --openssldir=/usr/ 
BSD-x86-elf -g -O3 -Wall ; make depend
   
[r...@ns1 /usr/source/openssl-0.9.8-stable-SNAP-20090310]# make  make 
test
   [...]  make -e PLATFORM='BSD-x86-elf' PROCESSOR=''  CC='gcc'
   CFLAG='-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
   -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O3
   -Wall  -DL_ENDIAN -DTERMIOS -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'
   AS='gcc' ASFLAG='-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
   -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN
   -DHAVE_DLFCN_H -g -O3 -Wall  -DL_ENDIAN -DTERMIOS -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 -c' AR='ar  r'
   PERL='/usr/bin/perl5' RANLIB='/usr/bin/ranlib'   SDIRS='objects
   md2 md4 md5 sha mdc2 hmac ripemd  des aes rc2 rc4 rc5 idea bf cast
   camellia seed  bn ec rsa dsa ecdsa dh ecdh dso engine  buffer bio
   stack lhash rand err  evp asn1 pem x509 x509v3 conf txt_db pkcs7
   pkcs12 comp ocsp ui krb5  store cms pqueue' LIBRPATH='/usr/lib'
   INSTALL_PREFIX=''   INSTALLTOP='/usr' OPENSSLDIR='/usr'
MAKEDEPEND='$${TOP}/util/domd $${TOP} -MD gcc'
   DEPFLAG='-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_JPAKE'
   MAKEDEPPROG='gcc'   SHARED_LDFLAGS=''
KRB5_INCLUDES='' LIBKRB5='' EXE_EXT=''
   SHARED_LIBS='libfips.so.0.9.8 libcrypto.so.0.9.8 libssl.so.0.9.8'
   SHLIB_EXT='.so.0.9.8' SHLIB_TARGET='bsd-shared' PEX_LIBS=''
   EX_LIBS=''  CPUID_OBJ='x86cpuid-elf.o'
   BN_ASM='bn86-elf.o co86-elf.o mo86-elf.o' DES_ENC='dx86-elf.o
   yx86-elf.o'   AES_ASM_OBJ='ax86-elf.o'
   BF_ENC='bx86-elf.o' CAST_ENC='c_enc.o'  RC4_ENC='rx86-elf.o
   rc4_skey.o' RC5_ENC='r586-elf.o'SHA1_ASM_OBJ='sx86-elf.o
   s512sse2-elf.o'MD5_ASM_OBJ='mx86-elf.o'
   RMD160_ASM_OBJ='rm86-elf.o' FIPSLIBDIR=''
FIPSCANLIB=${FIPSCANLIB:-libfips}
   FIPSCANISTERINTERNAL='y'FIPS_EX_OBJ='../crypto/aes/aes_cfb.o
   [...]
making all in crypto...
   
( echo #ifndef MK1MF_BUILD;  echo '  /* auto-generated by 
crypto/Makefile for crypto/cversion.c */';  echo '  #define CFLAGS gcc 
-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread 
-D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O3 -Wall  
-DL_ENDIAN -DTERMIOS -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';  echo '  #define 
PLATFORM BSD-x86-elf';  echo   #define DATE \`LC_ALL=C LC_TIME=C 
date`\;  echo '#endif' ) buildinf.h
   [...]
making all in crypto/objects...
   [...]
testing...
   [...]
   Testing SHA-384 ... passed.
   
   if [ -n libfips ]; then  ../util/shlib_wrap.sh ./fips_shatest 
   SHAmix.r | diff -w SHAmix.x - ;  fi
   
   ERROR:2d06c071:lib=45,func=108,reason=113:file=fips.c:line=276:
   
   1,129d0
   
[L = 64]
   
Len = 16
Msg = 98a1
MD = 
   74d78642f70ca830bec75fc60a585917e388cfa4cd1d23daab1c4d9ff1010cac3e67275df64db5a6a7c7d0fda24f1fc3eb272678a7c8becff6743ee812129078
   
Len = 104
Msg = 35a37a46df4ccbadd815942249
MD = 
   

Re: BSD 32-bit FIPS issues

2009-03-12 Thread Michael S. Zick
On Thu March 12 2009, The Doctor wrote:
 On Thu, Mar 12, 2009 at 11:58:34AM -0500, Michael S. Zick wrote:
  On Thu March 12 2009, The Doctor wrote:
   On Wed, Mar 11, 2009 at 11:51:23AM +0100, Ger Hobbelt wrote:
On Tue, Mar 10, 2009 at 8:02 PM, The Doctor doc...@doctor.nl2k.ab.ca 
wrote:
 This is happening again

Holy (beep)!

... would you do me a favor, please? (and maybe make some others
happy in the process as well)

I love an essay, but let's just say that the combination of riding the
bleeding edge of development using snapshots, combined with the
glaring ability to feed an entire make  make test console output,
unfiltered for optimum appreciation, produces a rather, ah,
unprofesssional, impression.

To the point: thank you very much for reporting failures; even more
thanks when you can strip away obvious (successful?) parts. E.g. all
those lucky compiler invocations.

Here's how one might go about, reducing cruft in feedback: here's your
report, reduced to maybe-relevant bits -- and I didn't even do this
thoroughly; this is the result of a rush job to kill the most obvious
clutter only:

 Script started on Tue Mar 10 12:06:29 2009
 [r...@ns1 /usr/source/openssl-0.9.8-stable-SNAP-20090310]# cat 
 /usr/local/bin/co
 nfigopenssl

 ./Configure threads shared experimental-store  enable-capieng 
 enable-cms enable-montasm enable-krb5 enable-tlsext enable-seed  
 enable-fips fipsdso enable-camellia enable-rfc3779 enable-gmp 
 enable-mdc2 enable-rc5 zlib-dynamic --prefix=/usr/ --openssldir=/usr/ 
 BSD-x86-elf -g -O3 -Wall ; make depend

 [r...@ns1 /usr/source/openssl-0.9.8-stable-SNAP-20090310]# make  
 make test
[...]  make -e PLATFORM='BSD-x86-elf' PROCESSOR=''  CC='gcc'
CFLAG='-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
-pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O3
-Wall  -DL_ENDIAN -DTERMIOS -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'
AS='gcc' ASFLAG='-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
-DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -g -O3 -Wall  -DL_ENDIAN -DTERMIOS -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 -c' AR='ar  r'
PERL='/usr/bin/perl5' RANLIB='/usr/bin/ranlib'   SDIRS='objects
md2 md4 md5 sha mdc2 hmac ripemd  des aes rc2 rc4 rc5 idea bf cast
camellia seed  bn ec rsa dsa ecdsa dh ecdh dso engine  buffer bio
stack lhash rand err  evp asn1 pem x509 x509v3 conf txt_db pkcs7
pkcs12 comp ocsp ui krb5  store cms pqueue' LIBRPATH='/usr/lib'
INSTALL_PREFIX=''   INSTALLTOP='/usr' OPENSSLDIR='/usr'
 MAKEDEPEND='$${TOP}/util/domd $${TOP} -MD gcc'
DEPFLAG='-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_JPAKE'
MAKEDEPPROG='gcc'   SHARED_LDFLAGS=''
 KRB5_INCLUDES='' LIBKRB5='' EXE_EXT=''
SHARED_LIBS='libfips.so.0.9.8 libcrypto.so.0.9.8 libssl.so.0.9.8'
SHLIB_EXT='.so.0.9.8' SHLIB_TARGET='bsd-shared' PEX_LIBS=''
EX_LIBS=''  CPUID_OBJ='x86cpuid-elf.o'
BN_ASM='bn86-elf.o co86-elf.o mo86-elf.o' DES_ENC='dx86-elf.o
yx86-elf.o'   AES_ASM_OBJ='ax86-elf.o'
BF_ENC='bx86-elf.o' CAST_ENC='c_enc.o'  RC4_ENC='rx86-elf.o
rc4_skey.o' RC5_ENC='r586-elf.o'SHA1_ASM_OBJ='sx86-elf.o
s512sse2-elf.o'MD5_ASM_OBJ='mx86-elf.o'
RMD160_ASM_OBJ='rm86-elf.o' FIPSLIBDIR=''
 FIPSCANLIB=${FIPSCANLIB:-libfips}
FIPSCANISTERINTERNAL='y'FIPS_EX_OBJ='../crypto/aes/aes_cfb.o
[...]
 making all in crypto...

 ( echo #ifndef MK1MF_BUILD;  echo '  /* auto-generated by 
 crypto/Makefile for crypto/cversion.c */';  echo '  #define CFLAGS 
 gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
 -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g 
 -O3 -Wall  -DL_ENDIAN -DTERMIOS -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';  echo '  #define 
 PLATFORM BSD-x86-elf';  echo   #define DATE \`LC_ALL=C LC_TIME=C 
 date`\;  echo '#endif' ) buildinf.h
[...]
 making all in crypto/objects...
[...]
 testing...
[...]
Testing SHA-384 ... passed.

if [ -n libfips ]; then  ../util/shlib_wrap.sh ./fips_shatest 
SHAmix.r | diff -w SHAmix.x - ;  fi

ERROR:2d06c071:lib=45,func=108,reason=113:file=fips.c:line=276:

1,129d0

 [L = 64]

 Len = 16
 Msg = 98a1
 MD = 

RE: PBE Key creation

2009-03-12 Thread Dave Thompson
 From: owner-openssl-us...@openssl.org On Behalf Of brechmos
 Sent: Thursday, 12 March, 2009 08:25

 I am relatively new at openssl and am just figuring out its 
 power.  One thing

General suggestion: for any of the openssl commandline 
functions, you can get a brief usage display by adding -? .
On a Unix-type installation (I believe including cygwin) 
there are also man pages (you may need to adjust your 
MANPATH depending on where OpenSSL is installed).
Note that the command for symmetric crypto is actually 'enc';
'des3' is really 'enc -des3', 'rc2-ofb' is 'enc -rc2-ofb', etc.;
so the man page is for 'enc' not for a specific ciphername.

 I do not understand is the key creation.  For example,
 
 $ openssl des3 -nosalt -P -in bob.txt 
 
 and I type in the password 1234 (not my normal password :-) and 
 it comes up  with:
 
 Verifying - enter des-ede3-cbc encryption password:
 key=81DC9BDB52D04DC20036DBD8313ED055CC5776D16A1FB6E4
 iv =AFA34B18395DA656
 
 Is there a way to create the key shown above using an ssl command line?
 
From openssl enc -? :
-k passphrase is the next argument
-pass argpass phrase source
(and elsewhere several options for arg are given including pass:value)
Hence:
openssl enc -des3 -k 1234 -nosalt 
openssl enc -des3 -pass pass:1234 -nosalt


Subject to the usual caveat: on some OSes and/or in some situations, 
commandline parameters can be seen by other programs, and possibly
other users on a multiuser system; this may be insecure for you.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Can't recognize intermediate CA

2009-03-12 Thread Rene Hollan
Corrected yahoo.pem:

-BEGIN CERTIFICATE- 
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
MDkwNloXDTExMDEwNDE3MDkwNloweDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
SW5jLjEOMAwGA1UECxMFWWFob28xGDAWBgNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA484iMII/1qq0eEs8UQ1B4HHWD9Qj 
ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg 
1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W7qyiacBd5dbiLIySj
9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0bR6FQpE4wTDEgMB4G
A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgNVBAsTCEZpcmV3YXJl
MRUwEwYDVQQDFgxSZXNpZ25pbmdfQ0GCCQCLda47dCCwQDANBgkqhkiG9w0BAQUF 
AAOCAQEAMS8EfpQrc/5ymRU4bMH8zg/ADJ2mAk8+BsHMBIaWBMDycVHMJUImmnfD 
PXFOS7+XnDLE7fVwgiNcY/k7223s6BMI/AMmtBg8qm7sR9V+7fv9Jq7BGWgmUPdG
BkqWYmfsd2uVei/rZchAvGiFc4hEVbt7s6pazASAFYN/RectfQtx8LBdJVC78SfF
DuO+l/hclIGJec5uzlpCenVydGVgToddvpV7Qg4Z+Rap2xiXx63KugGSRjA/1tnR
sQ2OcZejF/Kjh7SHmM/NHIfSuraWJcayb4njNt8vKRYazfiFF8G2O7cOOe674KM9 
TpMPay5Ei0HMRb1uQjRaFmxVd1RoKw== 
-END CERTIFICATE- 

-Original Message-
From: Rene Hollan 
Sent: Thursday, March 12, 2009 3:01 PM
To: 'openssl-users@openssl.org'
Subject: Can't recognize intermediate CA

I'm tearing my hair out trying to get an intermediate CA to be
recognized.

I have cacert.pem signing intcert.pem signing (well, resigning),
yahoo.pem

Openssl verify verifiies intcert.pem against cacert.pem, but won't
verify yahoo.pem against intcert.pem.

Subject/issuer match. AKID dirname and issuer subject match, AKID serial
number and issuer serial number match. AKID and issuer SKID match. Basic
Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good
measure) cert. Key usage CertSign and CRLSign on both root and
intermediate cert.

Can anyone see what is wrong? I'm including PEM versions of these certs.

Cacert.pem:

-BEGIN CERTIFICATE-
MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
AvScpmyMe2Mb
-END CERTIFICATE-


Intcert.pem:

-BEGIN CERTIFICATE-
MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m

FW: Can't recognize intermediate CA

2009-03-12 Thread Rene Hollan


 Arg can't even get end cert to paste in email window. Trying once more:

-BEGIN CERTIFICATE-
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
MDkwNloXDTExMDEwNDE3MDkwNloweDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
SW5jLjEOMAwGA1UECxMFWWFob28xGDAWBgNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA484iMII/1qq0eEs8UQ1B4HHWD9Qj
ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg
1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W7qyiacBd5dbiLIySj
9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0bR6FQpE4wTDEgMB4G
A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgNVBAsTCEZpcmV3YXJl
MRUwEwYDVQQDFgxSZXNpZ25pbmdfQ0GCCQCLda47dCCwQDANBgkqhkiG9w0BAQUF
AAOCAQEAMS8EfpQrc/5ymRU4bMH8zg/ADJ2mAk8+BsHMBIaWBMDycVHMJUImmnfD
PXFOS7+XnDLE7fVwgiNcY/k7223s6BMI/AMmtBg8qm7sR9V+7fv9Jq7BGWgmUPdG
BkqWYmfsd2uVei/rZchAvGiFc4hEVbt7s6pazASAFYN/RectfQtx8LBdJVC78SfF
DuO+l/hclIGJec5uzlpCenVydGVgToddvpV7Qg4Z+Rap2xiXx63KugGSRjA/1tnR
sQ2OcZejF/Kjh7SHmM/NHIfSuraWJcayb4njNt8vKRYazfiFF8G2O7cOOe674KM9
TpMPay5Ei0HMRb1uQjRaFmxVd1RoKw== -END CERTIFICATE-

-Original Message-
From: Rene Hollan
Sent: Thursday, March 12, 2009 3:21 PM
To: Rene Hollan; 'openssl-users@openssl.org'
Subject: RE: Can't recognize intermediate CA

Corrected yahoo.pem:

-BEGIN CERTIFICATE- 
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMU
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+mVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+MDkwNloXDTExMDEwNDE3MDkwNloweDELM
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+AkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhI
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+ENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+SW5jLjEOMAwGA1UECxMFWWFob28xGDAWB
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+gNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCg
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+YEA484iMII/1qq0eEs8UQ1B4HHWD9Qj
ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg
1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
1OHrG+NI66pQE4A3+2uTpVuX+DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAM
1OHrG+NI66pQE4A3+2uTpVuX+CBPAwHQYDVR0lBBYw
1OHrG+NI66pQE4A3+2uTpVuX+FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W
1OHrG+NI66pQE4A3+2uTpVuX+7qyiacBd5dbiLIySj
1OHrG+NI66pQE4A3+2uTpVuX+9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0
1OHrG+NI66pQE4A3+2uTpVuX+bR6FQpE4wTDEgMB4G
1OHrG+NI66pQE4A3+2uTpVuX+A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgN
1OHrG+NI66pQE4A3+2uTpVuX+VBAsTCEZpcmV3YXJl
1OHrG+NI66pQE4A3+2uTpVuX+MRUwEwYDVQQDFgxSZXNpZ25pbmdfQ0GCCQCLda47dCCwQDA
1OHrG+NI66pQE4A3+2uTpVuX+NBgkqhkiG9w0BAQUF
AAOCAQEAMS8EfpQrc/5ymRU4bMH8zg/ADJ2mAk8+BsHMBIaWBMDycVHMJUImmnfD 
PXFOS7+XnDLE7fVwgiNcY/k7223s6BMI/AMmtBg8qm7sR9V+7fv9Jq7BGWgmUPdG
PXFOS7+BkqWYmfsd2uVei/rZchAvGiFc4hEVbt7s6pazASAFYN/RectfQtx8LBdJVC78SfF
PXFOS7+DuO+l/hclIGJec5uzlpCenVydGVgToddvpV7Qg4Z+Rap2xiXx63KugGSRjA/1tnR
PXFOS7+sQ2OcZejF/Kjh7SHmM/NHIfSuraWJcayb4njNt8vKRYazfiFF8G2O7cOOe674KM9
TpMPay5Ei0HMRb1uQjRaFmxVd1RoKw==
-END CERTIFICATE- 

-Original Message-
From: Rene Hollan
Sent: Thursday, March 12, 2009 3:01 PM
To: 'openssl-users@openssl.org'
Subject: Can't recognize intermediate CA

I'm tearing my hair out trying to get an intermediate CA to be
recognized.

I have cacert.pem signing intcert.pem signing (well, resigning),
yahoo.pem

Openssl verify verifiies intcert.pem against cacert.pem, but won't
verify yahoo.pem against intcert.pem.

Subject/issuer match. AKID dirname and issuer subject match, AKID serial
number and issuer serial number match. AKID and issuer SKID match. Basic
Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good
measure) cert. Key usage CertSign and CRLSign on both root and
intermediate cert.

Can anyone see what is wrong? I'm including PEM versions of these certs.

Cacert.pem:

-BEGIN CERTIFICATE-
MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC

Can't recognize intermediate CA

2009-03-12 Thread Rene Hollan
I'm tearing my hair out trying to get an intermediate CA to be
recognized.

I have cacert.pem signing intcert.pem signing (well, resigning),
yahoo.pem

Openssl verify verifiies intcert.pem against cacert.pem, but won't
verify yahoo.pem against intcert.pem.

Subject/issuer match. AKID dirname and issuer subject match, AKID serial
number and issuer serial number match. AKID and issuer SKID match. Basic
Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good
measure) cert. Key usage CertSign and CRLSign on both root and
intermediate cert.

Can anyone see what is wrong? I'm including PEM versions of these certs.

Cacert.pem:

-BEGIN CERTIFICATE-
MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
AvScpmyMe2Mb
-END CERTIFICATE-


Intcert.pem:

-BEGIN CERTIFICATE-
MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m
NQxsY8NqwWswXHtRLLWJgAzZKWeN1PYMGgRmmGaH2lPYGT0xcpRuZfhTE5HlJ9VC
B3hV3JMD+VzPTzzcFm3gCCyR+dgNI0FmpoxtJzlirVj4BjHqTl+v4uhaX/wCgBvz
QcAWftj4GiemnficByogBS3QdbDwQGephQX2qySXzv0o8+qOV+RNMdPHH1T4o/tN
mjwXr099i5XcIvlfR9v677Q=
-END CERTIFICATE-


Yahoo.pem:

-BEGIN CERTIFICATE- 
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
MDkwNloXDTExMDEwNDE3MDkwNloweDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
SW5jLjEOMAwGA1UECxMFWWFob28xGDAWBgNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA484iMII/1qq0eEs8UQ1B4HHWD9Qj 
ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg 
1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W7qyiacBd5dbiLIySj
9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0bR6FQpE4wTDEgMB4G
A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgNVBAsTCEZpcmV3YXJl
MRUwEwYDVQQDFgxSZXNpZ25pbmdfQ0GCCQCLda47dCCwQDANBgkqhkiG9w0BAQUF 
AAOCAQEAMS8EfpQrc/5ymRU4bMH8zg/ADJ2mAk8+BsHMBIaWBMDycVHMJUImmnfD 
PXFOS7+XnDLE7fVwgiNcY/k7223s6BMI/AMmtBg8qm7sR9V+7fv9Jq7BGWgmUPdG
BkqWYmfsd2uVei/rZchAvGiFc4hEVbt7s6pazASAFYN/RectfQtx8LBdJVC78SfF
DuO+l/hclIGJec5uzlpCenVydGVgToddvpV7Qg4Z+Rap2xiXx63KugGSRjA/1tnR

RE: Can't recognize intermediate CA

2009-03-12 Thread Giang Nguyen

the cacert has pathlen:1 in its X509v3 Basic Constraints


 Subject: Can't recognize intermediate CA
 Date: Thu, 12 Mar 2009 15:00:47 -0700
 From: rene.hol...@watchguard.com
 To: openssl-users@openssl.org

 I'm tearing my hair out trying to get an intermediate CA to be
 recognized.

 I have cacert.pem signing intcert.pem signing (well, resigning),
 yahoo.pem

 Openssl verify verifiies intcert.pem against cacert.pem, but won't
 verify yahoo.pem against intcert.pem.

 Subject/issuer match. AKID dirname and issuer subject match, AKID serial
 number and issuer serial number match. AKID and issuer SKID match. Basic
 Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good
 measure) cert. Key usage CertSign and CRLSign on both root and
 intermediate cert.

 Can anyone see what is wrong? I'm including PEM versions of these certs.

 Cacert.pem:

 -BEGIN CERTIFICATE-
 MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
 CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
 YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
 hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
 ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
 96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
 AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
 Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
 eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
 iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
 mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
 ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
 VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
 MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
 MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
 RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
 dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
 FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
 bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
 r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
 AvScpmyMe2Mb
 -END CERTIFICATE-


 Intcert.pem:

 -BEGIN CERTIFICATE-
 MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
 IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
 d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
 AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
 wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
 COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
 qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
 NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
 yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
 BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
 dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
 b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
 b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
 DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
 ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
 kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m
 NQxsY8NqwWswXHtRLLWJgAzZKWeN1PYMGgRmmGaH2lPYGT0xcpRuZfhTE5HlJ9VC
 B3hV3JMD+VzPTzzcFm3gCCyR+dgNI0FmpoxtJzlirVj4BjHqTl+v4uhaX/wCgBvz
 QcAWftj4GiemnficByogBS3QdbDwQGephQX2qySXzv0o8+qOV+RNMdPHH1T4o/tN
 mjwXr099i5XcIvlfR9v677Q=
 -END CERTIFICATE-


 Yahoo.pem:

 -BEGIN CERTIFICATE-
 MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
 DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
 VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
 MDkwNloXDTExMDEwNDE3MDkwNloweDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
 bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
 SW5jLjEOMAwGA1UECxMFWWFob28xGDAWBgNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
 nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA484iMII/1qq0eEs8UQ1B4HHWD9Qj
 ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg
 1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
 DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYw
 FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W7qyiacBd5dbiLIySj
 9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0bR6FQpE4wTDEgMB4G
 A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgNVBAsTCEZpcmV3YXJl
 

RE: Can't recognize intermediate CA

2009-03-12 Thread Rene Hollan
I tried it with no (i.e. infinite) pathlen specified in cacert.pem. Same
effect.

Am I wrong in understanding that pathlen:0 implies no intermediate CAs
and pathlen:1 implies at most one intermediate CA (as is the case here)?

I used openssl with the intermediate CA to sign a separate cert, which
had a AKID keyid but no issuer, and that chain recongizes fine.

Could the problem be the fact that yahoo.pem has an AKID keyid AND
issuer? (onr or the other is sufficient, but I could find nothing that
said that both were illegal).
 

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Giang Nguyen
Sent: Thursday, March 12, 2009 3:49 PM
To: openssl-users@openssl.org
Subject: RE: Can't recognize intermediate CA


the cacert has pathlen:1 in its X509v3 Basic Constraints


 Subject: Can't recognize intermediate CA
 Date: Thu, 12 Mar 2009 15:00:47 -0700
 From: rene.hol...@watchguard.com
 To: openssl-users@openssl.org

 I'm tearing my hair out trying to get an intermediate CA to be 
 recognized.

 I have cacert.pem signing intcert.pem signing (well, resigning), 
 yahoo.pem

 Openssl verify verifiies intcert.pem against cacert.pem, but won't 
 verify yahoo.pem against intcert.pem.

 Subject/issuer match. AKID dirname and issuer subject match, AKID 
 serial number and issuer serial number match. AKID and issuer SKID 
 match. Basic Constraints CA:TRUE, pathlen:1 on both root and 
 intermediate (for good
 measure) cert. Key usage CertSign and CRLSign on both root and 
 intermediate cert.

 Can anyone see what is wrong? I'm including PEM versions of these
certs.

 Cacert.pem:

 -BEGIN CERTIFICATE-
 MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
 CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
 YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
 hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
 ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
 96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
 AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
 Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
 eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
 iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
 mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
 ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
 VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
 MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
 MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
 RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
 dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
 FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
 bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
 r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
 AvScpmyMe2Mb
 -END CERTIFICATE-


 Intcert.pem:

 -BEGIN CERTIFICATE-
 MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
 IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
 d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
 AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
 wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
 COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
 qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
 NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
 yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
 BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
 dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
 b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
 b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
 DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
 ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
 kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m
 NQxsY8NqwWswXHtRLLWJgAzZKWeN1PYMGgRmmGaH2lPYGT0xcpRuZfhTE5HlJ9VC
 B3hV3JMD+VzPTzzcFm3gCCyR+dgNI0FmpoxtJzlirVj4BjHqTl+v4uhaX/wCgBvz
 QcAWftj4GiemnficByogBS3QdbDwQGephQX2qySXzv0o8+qOV+RNMdPHH1T4o/tN
 mjwXr099i5XcIvlfR9v677Q=
 -END CERTIFICATE-


 Yahoo.pem:

 -BEGIN CERTIFICATE-
 MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
 

RE: Can't recognize intermediate CA

2009-03-12 Thread Giang Nguyen


 I tried it with no (i.e. infinite) pathlen specified in cacert.pem. Same
 effect.

 Am I wrong in understanding that pathlen:0 implies no intermediate CAs
 and pathlen:1 implies at most one intermediate CA (as is the case here)?

i believe you're right: the pathlen isnt the problem. (i just read 
http://www.openssl.org/docs/apps/x509v3_config.html#Basic_Constraints_ again.)


 I used openssl with the intermediate CA to sign a separate cert, which
 had a AKID keyid but no issuer, and that chain recongizes fine.

 Could the problem be the fact that yahoo.pem has an AKID keyid AND
 issuer? (onr or the other is sufficient, but I could find nothing that
 said that both were illegal).

using -verbose and -issuer_checks showed, along with error 29:
error 31 at 0 depth lookup:authority and issuer serial number mismatch

so i compared the serial numbers and the key id's. they looked ok to me. so at 
this point, i dont have any ideas.



 -Original Message-
 From: owner-openssl-us...@openssl.org
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of Giang Nguyen
 Sent: Thursday, March 12, 2009 3:49 PM
 To: openssl-users@openssl.org
 Subject: RE: Can't recognize intermediate CA


 the cacert has pathlen:1 in its X509v3 Basic Constraints

 
 Subject: Can't recognize intermediate CA
 Date: Thu, 12 Mar 2009 15:00:47 -0700
 From: rene.hol...@watchguard.com
 To: openssl-users@openssl.org

 I'm tearing my hair out trying to get an intermediate CA to be
 recognized.

 I have cacert.pem signing intcert.pem signing (well, resigning),
 yahoo.pem

 Openssl verify verifiies intcert.pem against cacert.pem, but won't
 verify yahoo.pem against intcert.pem.

 Subject/issuer match. AKID dirname and issuer subject match, AKID
 serial number and issuer serial number match. AKID and issuer SKID
 match. Basic Constraints CA:TRUE, pathlen:1 on both root and
 intermediate (for good
 measure) cert. Key usage CertSign and CRLSign on both root and
 intermediate cert.

 Can anyone see what is wrong? I'm including PEM versions of these
 certs.

 Cacert.pem:

 -BEGIN CERTIFICATE-
 MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
 CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
 YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
 hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
 ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
 96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
 AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
 Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
 eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
 iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
 mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
 ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
 VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
 MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
 MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
 RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
 dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
 FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
 bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
 r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
 AvScpmyMe2Mb
 -END CERTIFICATE-


 Intcert.pem:

 -BEGIN CERTIFICATE-
 MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
 IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
 d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
 AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
 wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
 COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
 qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
 NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
 yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
 BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
 dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
 b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
 b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
 DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
 ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
 kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m
 

RE: Can't recognize intermediate CA

2009-03-12 Thread Giang Nguyen


 I used openssl with the intermediate CA to sign a separate cert, which
 had a AKID keyid but no issuer, and that chain recongizes fine.

 Could the problem be the fact that yahoo.pem has an AKID keyid AND
 issuer? (onr or the other is sufficient, but I could find nothing that
 said that both were illegal).

it might be a bug in openssl X509_check_issued() function.

im using openssl 0.9.8i.

line 650 in v3_purp.c:

if(nm  X509_NAME_cmp(nm, X509_get_issuer_name(issuer)))
return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH;

nm is the DirName thing in the subject cert's AKID, ie 
/O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
and issuer is the intermediate CA cert, so its X509_get_issuer_name(issuer) 
will be name of root CA.
so the comparsion will fail, and you get the error.

looks like it should be X509_get_subject_name(issuer)
_
Windows Live™ Groups: Create an online spot for your favorite groups to meet.
http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Can't recognize intermediate CA

2009-03-12 Thread Giang Nguyen

 I used openssl with the intermediate CA to sign a separate cert, which
 had a AKID keyid but no issuer, and that chain recongizes fine.

 Could the problem be the fact that yahoo.pem has an AKID keyid AND
 issuer? (onr or the other is sufficient, but I could find nothing that
 said that both were illegal).

 it might be a bug in openssl X509_check_issued() function.

 im using openssl 0.9.8i.

 line 650 in v3_purp.c:

 if(nm  X509_NAME_cmp(nm, X509_get_issuer_name(issuer)))
 return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH;

 nm is the DirName thing in the subject cert's AKID, ie 
 /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
 and issuer is the intermediate CA cert, so its 
 X509_get_issuer_name(issuer) will be name of root CA.
 so the comparsion will fail, and you get the error.

 looks like it should be X509_get_subject_name(issuer)


$ ./openssl version
OpenSSL 0.9.8i 15 Sep 2008
$
$ ./openssl verify -CApath cas cas/int.pem
cas/int.pem: OK
$
$ ./openssl verify -CApath cas yahoo.pem
yahoo.pem: /C=US/ST=California/L=Santa Clara/O=Yahoo! 
Inc./OU=Yahoo/CN=login.yahoo.com
error 20 at 0 depth lookup:unable to get local issuer certificate
$
$
$ gdb --args ./openssl verify -CApath cas yahoo.pem
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
(gdb)
(gdb) b v3_purp.c:630
Breakpoint 1 at 0x812d0e7: file v3_purp.c, line 630.
(gdb) b v3_purp.c:651
Breakpoint 2 at 0x812d186: file v3_purp.c, line 651.
(gdb) r
Starting program: ./openssl verify -CApath cas yahoo.pem

Breakpoint 2, X509_check_issued (issuer=0x8204e68, subject=0x8204760) at 
v3_purp.c:651
651 return 
X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH;
(gdb) p nm
$1 = (X509_NAME *) 0x820bf18
(gdb) p X509_NAME_oneline(nm,0,0)
$2 = 0x820c0f8 /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
(gdb) p issuer
$3 = (X509 *) 0x8204e68
(gdb) set nm=X509_get_issuer_name(issuer)
(gdb) p nm
$4 = (X509_NAME *) 0x8206310
(gdb) p X509_NAME_oneline(nm,0,0)
$5 = 0x820c208 /C=US/ST=Washington/O=Foobar/OU=foobar/CN=Foo B. 
Ar/emailaddress=...@bar.com
(gdb) set nm=X509_get_subject_name(issuer)
(gdb) p nm
$6 = (X509_NAME *) 0x82083b0
(gdb) p X509_NAME_oneline(nm,0,0)
$7 = 0x820c318 /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
(gdb)


_
Windows Live™: Life without walls.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Can't recognize intermediate CA

2009-03-12 Thread Rene Hollan
Yeah, I just noticed that.

I've been comparing how my intermediate CA resigned an existing cert
(it's part of a proxy that decrypts, examines, and reencrypts -- the
downstream client sharing a trust hierarchy with the intermediate
resigning CA) with what OpenSSL ca ... does.

OpenSSL ca ... actually puts the issuer of the issuer into the AKID
issuer field of the signed cert, along with the issuer serial number.
When the issuer is a root ca, it is it's own issuer, so the issuer
(which is what my resigning code was using), and issuer's issuer are the
same. But, when the issuer is an intermediate CA, they are different.
  
So, either I'm doing it wrong, or OpenSSL ca ... Is doing it wrong (but
consistent with how OpenSSL verify ... checks).

At this point, I think the error is mine. At least browsers accept the
cert when OpenSSL signs it with an intermediate CA, and not when I do.

Think about it: the purpose of the AKID is to identify the public key of
the signer, either by matching the SKID of the signer, or some other
means of identifying the signer. Well, the signer's serial number is
unique within those issued by IT'S signer, so the combination of IT's
signer and IT's serial number should be probabilistically unique.

This whole SKID/AKID mess comes about because issuer and subject DNs are
not guaranteed to be globally unique, but the combination of issuer's
issuer DN, and issuer's serial number within the issuer's issuer's DN
are statistically more so. (Without SKID/AKID, one would have to verify
a prospective issuer by unhashing the signature with the issuer's public
key, which is arguably more computationally expensive that comparing
SKID and AKID. One should still do this anyway, but the SKID/AKID check
preemptively eliminates the wrong issuer).

Sigh. X500 looks like a royal designed by non-technical committee
mess.

Thanks for the help, now excuse me while I make a code change.

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Giang Nguyen
Sent: Thursday, March 12, 2009 4:56 PM
To: openssl-users@openssl.org
Subject: RE: Can't recognize intermediate CA



 I used openssl with the intermediate CA to sign a separate cert, which

 had a AKID keyid but no issuer, and that chain recongizes fine.

 Could the problem be the fact that yahoo.pem has an AKID keyid AND 
 issuer? (onr or the other is sufficient, but I could find nothing that

 said that both were illegal).

it might be a bug in openssl X509_check_issued() function.

im using openssl 0.9.8i.

line 650 in v3_purp.c:

if(nm  X509_NAME_cmp(nm, X509_get_issuer_name(issuer)))
return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH;

nm is the DirName thing in the subject cert's AKID, ie
/O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
and issuer is the intermediate CA cert, so its
X509_get_issuer_name(issuer) will be name of root CA.
so the comparsion will fail, and you get the error.

looks like it should be X509_get_subject_name(issuer)
_
Windows Live(tm) Groups: Create an online spot for your favorite groups
to meet.
http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Can't recognize intermediate CA

2009-03-12 Thread Dr. Stephen Henson
On Thu, Mar 12, 2009, Rene Hollan wrote:

 Yeah, I just noticed that.
 
 I've been comparing how my intermediate CA resigned an existing cert
 (it's part of a proxy that decrypts, examines, and reencrypts -- the
 downstream client sharing a trust hierarchy with the intermediate
 resigning CA) with what OpenSSL ca ... does.
 
 OpenSSL ca ... actually puts the issuer of the issuer into the AKID
 issuer field of the signed cert, along with the issuer serial number.
 When the issuer is a root ca, it is it's own issuer, so the issuer
 (which is what my resigning code was using), and issuer's issuer are the
 same. But, when the issuer is an intermediate CA, they are different.
   
 So, either I'm doing it wrong, or OpenSSL ca ... Is doing it wrong (but
 consistent with how OpenSSL verify ... checks).
 
 At this point, I think the error is mine. At least browsers accept the
 cert when OpenSSL signs it with an intermediate CA, and not when I do.
 
 Think about it: the purpose of the AKID is to identify the public key of
 the signer, either by matching the SKID of the signer, or some other
 means of identifying the signer. Well, the signer's serial number is
 unique within those issued by IT'S signer, so the combination of IT's
 signer and IT's serial number should be probabilistically unique.
 
 This whole SKID/AKID mess comes about because issuer and subject DNs are
 not guaranteed to be globally unique, but the combination of issuer's
 issuer DN, and issuer's serial number within the issuer's issuer's DN
 are statistically more so. (Without SKID/AKID, one would have to verify
 a prospective issuer by unhashing the signature with the issuer's public
 key, which is arguably more computationally expensive that comparing
 SKID and AKID. One should still do this anyway, but the SKID/AKID check
 preemptively eliminates the wrong issuer).
 
 Sigh. X500 looks like a royal designed by non-technical committee
 mess.
 
 Thanks for the help, now excuse me while I make a code change.
 

If it's any consolation you aren't alone with that, it gets commented on quite
often so much so in fact that it has an FAQ entry:

http://www.openssl.org/support/faq.html#USER15

You can just leave out the issuer+serial number combination from AKID too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Can't recognize intermediate CA

2009-03-12 Thread Giang Nguyen





Sincerely,

Giang Nguyen







 Date: Fri, 13 Mar 2009 00:22:56 +0100
 From: st...@openssl.org
 To: openssl-users@openssl.org
 Subject: Re: Can't recognize intermediate CA

 On Thu, Mar 12, 2009, Rene Hollan wrote:

 Yeah, I just noticed that.

 I've been comparing how my intermediate CA resigned an existing cert
 (it's part of a proxy that decrypts, examines, and reencrypts -- the
 downstream client sharing a trust hierarchy with the intermediate
 resigning CA) with what OpenSSL ca ... does.

 OpenSSL ca ... actually puts the issuer of the issuer into the AKID
 issuer field of the signed cert, along with the issuer serial number.
 When the issuer is a root ca, it is it's own issuer, so the issuer
 (which is what my resigning code was using), and issuer's issuer are the
 same. But, when the issuer is an intermediate CA, they are different.

 So, either I'm doing it wrong, or OpenSSL ca ... Is doing it wrong (but
 consistent with how OpenSSL verify ... checks).

 At this point, I think the error is mine. At least browsers accept the
 cert when OpenSSL signs it with an intermediate CA, and not when I do.

 Think about it: the purpose of the AKID is to identify the public key of
 the signer, either by matching the SKID of the signer, or some other
 means of identifying the signer. Well, the signer's serial number is
 unique within those issued by IT'S signer, so the combination of IT's
 signer and IT's serial number should be probabilistically unique.

 This whole SKID/AKID mess comes about because issuer and subject DNs are
 not guaranteed to be globally unique, but the combination of issuer's
 issuer DN, and issuer's serial number within the issuer's issuer's DN
 are statistically more so. (Without SKID/AKID, one would have to verify
 a prospective issuer by unhashing the signature with the issuer's public
 key, which is arguably more computationally expensive that comparing
 SKID and AKID. One should still do this anyway, but the SKID/AKID check
 preemptively eliminates the wrong issuer).

 Sigh. X500 looks like a royal designed by non-technical committee
 mess.

 Thanks for the help, now excuse me while I make a code change.


 If it's any consolation you aren't alone with that, it gets commented on quite
 often so much so in fact that it has an FAQ entry:

 http://www.openssl.org/support/faq.html#USER15


doh, that makes sense! thanks.

_
Hotmail® is up to 70% faster. Now good news travels really fast. 
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Can't recognize intermediate CA

2009-03-12 Thread Rene Hollan
 Yup. That fixed it.. At least as far as openssl verify -CAfile
cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.

Oddly, firefox still rejects the end cert, even though both cacert.pem
and intcert2.pem are in it's trust store. Is it possible that browsers
actually ignore intermediate CA certs in their trust store and expect
servers to provide them? That's the next thing for me to try (if only I
can remember how to do that with openssl... :-)).


-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openssl-users@openssl.org
Subject: Re: Can't recognize intermediate CA


If it's any consolation you aren't alone with that, it gets commented on
quite often so much so in fact that it has an FAQ entry:

http://www.openssl.org/support/faq.html#USER15

You can just leave out the issuer+serial number combination from AKID
too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Can't recognize intermediate CA

2009-03-12 Thread Rene Hollan
True, but (a) it doesn't hurt to have both, and (b) if  the issuer
doesn't have a SKID, AKID issuer/serial takes the place of an AKID
keyid.

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openssl-users@openssl.org
Subject: Re: Can't recognize intermediate CA


You can just leave out the issuer+serial number combination from AKID
too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Can't recognize intermediate CA

2009-03-12 Thread Rene Hollan
 Sigh.

Well, I added the intermediate CA to the cert chain sent by my proxy
(and verified this with wireshark).

OpenSSL s_client -CAfile cacert.pem -host login.yahoo.com -port 443
works and shows the trust chain.

But, Firefox, with cacert.pem loaded into it's trust store still
complains. :-(

 

-Original Message-
From: Rene Hollan 
Sent: Thursday, March 12, 2009 5:39 PM
To: 'openssl-users@openssl.org'
Subject: RE: Can't recognize intermediate CA

 Yup. That fixed it.. At least as far as openssl verify -CAfile
cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.

Oddly, firefox still rejects the end cert, even though both cacert.pem
and intcert2.pem are in it's trust store. Is it possible that browsers
actually ignore intermediate CA certs in their trust store and expect
servers to provide them? That's the next thing for me to try (if only I
can remember how to do that with openssl... :-)).


-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openssl-users@openssl.org
Subject: Re: Can't recognize intermediate CA


If it's any consolation you aren't alone with that, it gets commented on
quite often so much so in fact that it has an FAQ entry:

http://www.openssl.org/support/faq.html#USER15

You can just leave out the issuer+serial number combination from AKID
too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Can't recognize intermediate CA

2009-03-12 Thread Rene Hollan
Great, just great.

My changes worked for IE, but not for Firefox.

Apparently, Firefox does more stringent checking that IE, and indeed,
than OpenSSL s_client ... (which gives a nice cert chain).
 

-Original Message-
From: Rene Hollan 
Sent: Thursday, March 12, 2009 6:34 PM
To: 'openssl-users@openssl.org'
Subject: RE: Can't recognize intermediate CA

 Sigh.

Well, I added the intermediate CA to the cert chain sent by my proxy
(and verified this with wireshark).

OpenSSL s_client -CAfile cacert.pem -host login.yahoo.com -port 443
works and shows the trust chain.

But, Firefox, with cacert.pem loaded into it's trust store still
complains. :-(

 

-Original Message-
From: Rene Hollan
Sent: Thursday, March 12, 2009 5:39 PM
To: 'openssl-users@openssl.org'
Subject: RE: Can't recognize intermediate CA

 Yup. That fixed it.. At least as far as openssl verify -CAfile
cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.

Oddly, firefox still rejects the end cert, even though both cacert.pem
and intcert2.pem are in it's trust store. Is it possible that browsers
actually ignore intermediate CA certs in their trust store and expect
servers to provide them? That's the next thing for me to try (if only I
can remember how to do that with openssl... :-)).


-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openssl-users@openssl.org
Subject: Re: Can't recognize intermediate CA


If it's any consolation you aren't alone with that, it gets commented on
quite often so much so in fact that it has an FAQ entry:

http://www.openssl.org/support/faq.html#USER15

You can just leave out the issuer+serial number combination from AKID
too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org