Re: Issue with Private key with FIPS enabled openssl
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
