Re: OpenSSL FIPS Certification
Are you going to support not only 0.9.7 branch, but also 0.9.8 branch? +Kiyoshi Kiyoshi Watanabe - Original Message - From: "Dr. Stephen Henson" <[EMAIL PROTECTED]> To: Sent: Monday, January 30, 2006 10:07 PM Subject: Re: OpenSSL FIPS Certification On Sun, Jan 29, 2006, Kyle Hamilton wrote: 0.9.7h is FIPS certified, as long as you build with unmodified sources (and this is checked with an SHA check on the sources in question). Err no IT IS NOT. The version submitted for validation included various changes to sequestered code (the stuff under fips/). No released version of OpenSSL currently includes these changes. The current 0.9.7-stable snapshot sequestered code matches the submitted version. 0.9.7j (not yet released) and later releases will also match it. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
secure code guidance
Hi Team, This might be dev topic, but let me ask. Is there any coding guidance for the core team and application developer? Is anybody doing the source code review like open bsd team does for their code? Thanks! With Best Regards, Kiyoshi Kiyoshi Watanabe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Doubt regarding x509_verify_cert
The Bridge CA is a CA(hub) to bridge the two different CAs, so no need to have a Self-signed certificate for BridgeCA. If you are relying party in Root CA1 domain and if you want to create a certificate path, you will probably have: SelfCert1byRootCA1, CrossCertFromRootCA1toBridgeCA, CrossCertFromBridgeCAtoRootCA2, UserCertByRootCA2 - Original Message - From: "Suram Chandra Sekhar" <[EMAIL PROTECTED]> To: Sent: Friday, December 09, 2005 10:22 PM Subject: Doubt regarding x509_verify_cert Hi, I have a doubt regarding the x509_verify_cert. I used openssl to generate two Root CA certificates (Self signed) say Root CA1, Root CA2. I got two self-certificates say SelfCert1 from Root CA1 and SelfCert2 from Root CA2. In an effort to simulate a bridge CA, one more root CA is generated say BridgeCA. I simulated a cross certification to RootCA1 by BridgeCA (Say CCofRootCA1ByBridgeCA with Issuer as BridgeCA, Subject: RootCA1, PubKey of RootCA1). Now I try to verfiy SelfCert1, CCofRootCA1ByBridgeCA, BridgeCA using x509_verify_cert. This function is throwing an error saying "unable to find the local issuer cert" for SelfCert1. My question is 1. Is the above scenario correct. 2. If so why should it fail. I expect it to work because The issuer name of SelfCert1(RootCA1) is the subject name in CCofRootCA1ByBridgeCA whose IssuerName, BridgeCA is the subjectName in BridgeCA which is self-signed. Awaiting your valuable responses... Regards Suram __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
installation problem on openssl 0.9.8a to solaris 10 x86 intel under virtual pc
Hi team,
I got encountered the following error when
I installed the openssl 0.9.8a to solaris 10 intel box under virtual
pc.
>./Configure
solaris-x86-gcc
> make
--
.
.
.
gcc -I.. -I../.. -I../../include
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3
-fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM -c randfile.cIn file included from
/usr/include/sys/wait.h:24,
from
/usr/include/stdlib.h:22,
from randfile.c:64:/usr/include/sys/siginfo.h:259: error: parse error before
"ctid_t"/usr/include/sys/siginfo.h:292: error: parse error before '}'
token/usr/include/sys/siginfo.h:294: error: parse error before '}'
tokenIn file included from
/usr/include/sys/procset.h:24,
from
/usr/include/sys/wait.h:25,
from
/usr/include/stdlib.h:22,
from randfile.c:64:/usr/include/sys/signal.h:85: error: parse error before
"siginfo_t"In file included from
/usr/include/stdlib.h:22,
from randfile.c:64:/usr/include/sys/wait.h:86: error: parse error before
"siginfo_t"*** Error code 1make: Fatal error: Command failed for target
`randfile.o'Current working directory
/home/kiyoshi/tmp/openssl-0.9.8a/crypto/rand*** Error code 1The
following command caused the error:target=all; [ -n "objects md2 md4
md5 sha hmac ripemd des aes rc2 rc4 idea bf cast 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 pqueue" ]
&& for i in objects md2 md4 md5 sha hmac ripemd des aes rc2
rc4 idea bf cast 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 pqueue ; do (cd $i && echo "making
$target in crypto/$i..." && make -e TOP=../.. DIR=$i
INCLUDES='-I.. -I../.. -I../../include' $target ) || exit 1;
done;make: Fatal error: Command failed for target `subdirs'Current
working directory /home/kiyoshi/tmp/openssl-0.9.8a/crypto*** Error code
1The following command caused the error:dir=crypto; target=all; if [ -d
"$dir" ]; then ( cd $dir &&
echo "making $target in $dir..." && TOP= && unset TOP
${LIB+LIB} ${LIBS+LIBS} ${INCLUDE+INCLUDE}
${INCLUDES+INCLUDES} ${DIR+DIR}
${DIRS+DIRS}
${SRC+SRC}
${LIBSRC+LIBSRC} ${LIBOBJ+LIBOBJ} ${ALL+ALL}
${EXHEADER+EXHEADER}
${HEADER+HEADER}
${GENERAL+GENERAL}
${CFLAGS+CFLAGS}
${ASFLAGS+ASFLAGS}
${AFLAGS+AFLAGS}
${LDCMD+LDCMD}
${LDFLAGS+LDFLAGS}
${SHAREDCMD+SHAREDCMD}
${SHAREDFLAGS+SHAREDFLAGS}
${SHARED_LIB+SHARED_LIB} ${LIBEXTRAS+LIBEXTRAS} && make -e
PLATFORM='solaris-x86-gcc' PROCESSOR='' CC='gcc' CFLAG='-DOPENSSL_THREADS
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium
-Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS
-DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM
-DAES_ASM'
AS='gcc' ASFLAG='-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3
-fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM -c' AR='ar r' PERL='/bin/perl'
RANLIB='/usr/ccs/bin/ranlib'
SDIRS='objects md2 md4 md5 sha hmac ripemd des aes rc2 rc4 idea bf
cast 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 pqueue' LIBRPATH='/usr/local/ssl/lib'
INSTALL_PREFIX=''
INSTALLTOP='/usr/local/ssl'
OPENSSLDIR='/usr/local/ssl'
MAKEDEPEND='$${TOP}/util/domd $${TOP} -MD gcc'
DEPFLAG='-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_GMP -DOPENSSL_NO_MDC2
-DOPENSSL_NO_RC5'
MAKEDEPPROG='gcc'
SHARED_LDFLAGS='-shared'
KRB5_INCLUDES='' LIBKRB5='' EXE_EXT=''
SHARED_LIBS='' SHLIB_EXT='.so.0.9.8'
SHLIB_TARGET='solaris-shared' PEX_LIBS=''
EX_LIBS='-lsocket -lnsl -ldl'
CPUID_OBJ='x86cpuid-elf.o'
BN_ASM='bn86-elf.o co86-elf.o' DES_ENC='dx86-elf.o yx86-elf.o'
AES_ASM_OBJ='ax86-elf.o'
BF_ENC='bx86-elf.o'
CAST_ENC='cx86-elf.o'
RC4_ENC='rx86-elf
Re: Certificate fetching for bridge CA configuration
Charles, One question: Are you talking about the NIST bridge CA concept or some other variants? It is too hard to understand the diagram. With my understanding, the bridge CA is a hub between different CA domains. Thus each root CA (or principal CA) issues a cross certificate to bridge. -Kiyoshi Kiyoshi Watanabe > So, this is perhaps the most simple "bridge" PKI arrangement: > > +-+---++-+---+ > |T| ||T| | > +-+---++-+---+ > | P Root++ +---+ Q Root| > +-+| | +-+ > v v > +--+--+ +--+--+ > (1) | (P Root) | | (Q Root) | > +-+ +-+ > | Bridge+--+--+ Bridge| > +-+ | +-+ > | > +-+-+ > v v > +--+--+ +--+--+ > | (Bridge) | | (Bridge) | > +-+ +-+ > ++ P Sign| | Q Sign++ > |+-+ +-+| > v v > +--+--+ +--+--+ > | (P Sign) | | (Q Sign) | > +-+ +-+ > | P End User | | Q End User | > +-+ +-+ > > Here P and Q are two separate PKIs bridged by the bridge Bridge. > > Let an email sender (or an SSL server) be the "offerer", > and let the email reader (or the SSL client) be the > "relying party" (latter is standard usage). > > An "offerer" in the Q PKI interacts with a "relying party" > in the P PKI. The P relying party needs this certificate > chain: > > +-+---+ > |T| | Presumably this is configured into the relying > +-+---+ party software, or available from a server that > | P Root| is secure and trusted by users of the P PKI > +-+ > > +-+ > | (P Root) | (1) This is the toughie -- could be configured into > +-+ the P relying party or fetched from P LDAP but > | Bridge| is NOT reasonable for Q offerer to supply... > +-+ > > +-+ > | (Bridge) | The Q offerer could supply this along with the > +-+ End User certificate > | Q Sign| > +-+ > > +-+ > | (Q Sign) | The Q offerer would supply this > +-+ > | Q End User | > +-+ > > So, where would you suspect the (1) certificate would be obtained? > It is unreasonable for Q End User to supply it, since she does not > necessarily know client is from P and so would have to supply EVERY > other PKI's bridge certificate. Perhaps it could be loaded from > a source named by an Authority Information Access extension in > (what? the end user certificate, or the signing certificate?) > > The only other alternative I can see is to load all the bridge > certificates (1) into all the relying parties. > > -- > Charles B (Ben) Cranston > mailto: [EMAIL PROTECTED] > http://www.wam.umd.edu/~zben > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: crlDistributionPoints with DirName value?
Hi, > crlDistributionPoints = DirName:/C=FI/O=SSH Communications Security Corp/CN=SSH Test > CA 2 No Liabilities How about crlDistributionPoints = @crl_dist [ crl_dist ] DirName = /C=FI/O=SSH Communications Security Corp/CN=SSH Test CA 2 No Liabilities -Kiyoshi Kiyoshi Watanabe > and when I attempt to use openssl ca to sign the certificate I get: > > # openssl ca -in req.pem -out cert.pem > Using configuration from /usr/share/ssl/openssl.cnf > Enter PEM pass phrase: > Error Loading extension section usr_cert > 6355:error:22075075:X509 V3 routines:v2i_GENERAL_NAME:unsupported > option:v3_alt.c:380:name=DirName > 6355:error:2206B080:X509 V3 routines:X509V3_EXT_conf:error in > extension:v3_conf.c:91:name=crlDistributionPoints, value=DirName:/C=FI/O=SSH > Communications Security Corp/CN=SSH Test CA 2 No Liabilities > > >From my reading of the source code it appears that I can only use email, > URI, DNS, RID, and IP type values for this extension. Is there some > other way to get a value of type DirName into this extension? > > Thanks very much :) > > -- > | Mike Acar | [EMAIL PROTECTED] | > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: retrive the private key from RSA KEON CA certificate
> Why don't you convert or issue the PKCS#11 in DER format. I believe PKCS#12, not PKCS#11 sorry for my typo. -Kiyoshi Kiyoshi Watanabe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: retrive the private key from RSA KEON CA certificate
Hello, >-BEGIN CERTIFICATE AND KEY- Is this the standard PEM encorded pkcs12 format? As long as I see the header checking definitions for PEM formats in pem.h, no such a header is defined. Why don't you convert or issue the PKCS#11 in DER format. I believe the openssl will read the starndard PKCS12 binary file without having any problem and you can use FORMAT_PKCS12. -Kiyoshi Kiyoshi Watanabe > I have a CA certificate exported from RSA KEON, which is PEM encoded pkcs#12 > certificate (listed below.) > It seems encoded by base64 , I have tried different methods to try to get > the private key inside the certificate by the functions in the openssl. ( > such as using FORMAT_PKCS12 and FORMAT_PEM in apps.c/load_key().) > But it always failed. > It is exported by me so I know password used for the private key protection. > > Question: > 1,So, is it possible to retrive the private key inside the pkcs#12 > certificate as follows exported from KEON? > 2,If it is possible , how can I retrieve the private key in it by the > functions in OpenSSL? > > Thanks in advance. > > / the certificate exported from KEON > */ > The following passphrase protected PKCS #12 object, displayed in PEM encoded > format, contains the certificate and private key for CATest1_1. It also > contains the friendly name "CATest1_1". > >-BEGIN CERTIFICATE AND KEY- > MIIF0wIBAzCCBY0GCSqGSIb3DQEHAaCCBX4EggV6MIIFdjCCBXIGCSqGSIb3DQEH > AaCCBWMEggVfMIIFWzCCAvAGCyqGSIb3DQEMCgECoIICpTCCAqEwGwYKKoZIhvcN > AQwBAzANBAhGyCbImOLSZwIBAQSCAoDPZJurj3+1kM7e4/cPp1kYM1qcsLPAQsIQ > 5eycmvECjgi7ZILdv28dvm3RNjTlmrH/Zr29i2gHANSgxRW8VQ5KFq/BZIEOG+KN > EsyVC/Xwpp1joEvxODb2UIymruFxqTAJYJIbXtnH4SHUzp2WXupmt8Cme8axoTwW > 1Dms4u/G/VyP9qlCVQOFfBpEdBzy+U9DC2QTnaN4XA6Sx8BxMS8TGTP+3LTPDK4b > k3ROX80znDIqd3povWsPk1MGCi1s6l6c817Nm2k8eu9S7agGsKmtYw/VzdbRIGYM > oP6l8H6IL9dvWBeMW8WgZj9rWFDg89CZW9qX3LuJ6IDqSJ8MU9xvs1ZdJHbjtABh > nzoZoSoPuMEYHf6L2JctLIEHNUJNYefh+Ck+INsNlofWW7OnavgT9Omrb4TiW1IA > mGe4F6gK6benv1bDTltTDPabraLE3jJY4VE4CtlsZeFLwZ6Y5q2JnSbSJCxZtMBP > zp6OOIkS8ZJK1BCZBQCIIw+1NLTRzrrfnJQuEcJ41LZhfCw2xdwVM4qtc7I3SXQA > Xs/UYFlvif4dMWyG5PtuQ/PrzM4OJ5KVXzjYRqa8ixLvDtqYsqwzlzGezz1HnKvE > vNTbT9qajK8AIxwnhhQ4ErMDVTbtjYrvWNfseu8WwRTIZfy3YLJS1vbwHNmdukql > AbsXmYGDEjgEgOuzS0I0qH3m/CoH1g6QEOxAFqXBU9HuZ91I+s7gprJwi5/dziMv > rl9WRkcDnTltijijvpXnTIGylWpS9To4pQhEuxa5GsNyvUgmQtU5v11hZWF+V3a4 > G3ZMDksr34VzflfHsIjfx6to3NUWVP1xo6Q+LjNKfie2ceM1fESUMTgwEwYJKoZI > hvcNAQkVMQYEBAEwIQYJKoZIhvcNAQkUMRQeEgBDAEEAVABlAHMAdAAxAF8A > MTCCAmMGCyqGSIb3DQEMCgEDoIICGDCCAhQGCiqGSIb3DQEJFgGgggIEBIICADCC > AfwwggFlAhB5U/4UwzOflq9K1i22Xqv3MA0GCSqGSIb3DQEBBQUAMD0xCzAJBgNV > BAYTAkpQMRIwEAYDVQQKEwlGdWppeGVyb3gxDDAKBgNVBAsTA0NTVzEMMAoGA1UE > AxMDV3UxMB4XDTAzMDYxOTA2MDAxMVoXDTA2MDQyNjExMDAxMVowQTELMAkGA1UE > BhMCSlAxCzAJBgNVBAoTAmZ4MQwwCgYDVQQLEwNjc3cxFzAVBgNVBAMTDnNvbiBv > ZiBDQVRlc3QxMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDegClxP28gBnrJ > s5RVqY5TMM5AIoHHDmQeIvj55DtMmIuRHnk6kBPmZJtqNetPwRfRwMIBtu9/T1Vy > psOO4QuAZz1C5wvRbC4Ylh4/nAnR1xY4fIN5lTflam1ohVUFZmx9jRNxp89VznSp > 56wcsiJMzNrB6Nev3j4bfKlz7iULCQIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAF2l > QSp+wQ7n98p7VeBh9wVnv/TTzb9ebgDEZSb9I6FZpeQ3242/cTsoe2y2NtmhjmmY > OURbW66jhV/pKZliEFM53Fc7xoPstN0SKFQyOHUsO0lQbZu+o8wk6oWptg/KPEZR > 1Xx6zu3E2Qwx+6vqOFGrfDdiQe7pDp4a4j6oYP1GMTgwEwYJKoZIhvcNAQkVMQYE > BAEwIQYJKoZIhvcNAQkUMRQeEgBDAEEAVABlAHMAdAAxAF8AMTA9MCEwCQYF > Kw4DAhoFAAQUy0Edy1Bxr38oc0jumiqofA19OeYEFIjlSSn4K2WLg6m2D9YYQgx6 > +bjkAgIEAA== > -END CERTIFICATE AND KEY- > > > wjw __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: why -issuer option in OCSP client options must be PEM format?
Hello, As you can see, the default certificate format is PEM in openssl command. I do not know the excact reason, but I agree that the ocsp command had better to have format option if you are requesting so. -Kiyoshi Kiyoshi Watanabe > Hi,all, > > Could some one tell me kindly why the -issuer option in the OpenSSL OCSP > client options MUST be PEM format ? > > > thanks, > > wjw __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Queries on SubjAltName
Dear Steve > > Any pointers on how to generate certificates using SubjAltName extension. > > > > As with all extensions doc/openssl.txt Many people including me are asking the similar questions. Do you think that it is a good idea to mention about this document in openssl.cnf file as a comment? -Kiyoshi Kiyoshi Watanabe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASK: any option for CERTID in OCSP using AKID of the cert tobe checked
Hi, I thought that two values could be the same. Both use the hash value of the subject public key field information of the issuer certificate. RFC 2560 does not have any description of the use of authority key identifer. However looking at the archives of PKIX discussion, some mentioned the use of authority key identifer to avoid the hash calculation at the client side. Or am i misunderstanding about the calculation over the two values? #The authority Key identifer has different methods to calculate, so #it is not good to rely on the authority key identifer value only. -Kiyoshi Kiyoshi Watanabe > On Sun, Jan 19, 2003, Kiyoshi WATANABE wrote: > > > > > Dear all and developers, > > > > Is any option to create the CertID.issuerKeyHash using the AKID of the > > cert to be checked, instead of using the issuer certificate itself, in > > OCSP request? > > > > In addition, do you see any security concerns over this usage if being > > developed? > > > > The OCSP standard define what CertID.issuerKeyHash should be so changing that > makes the implementation non compliant. > > Updated versions of the OCSP standards are being discussed which do allow > alternative certificate identifiers but they are still being discussed and > OpenSSL doesn't support them yet. > > Steve. > -- > Dr. Stephen Henson [EMAIL PROTECTED] > OpenSSL Project http://www.openssl.org/~steve/ > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Help for openssl verify command and its strange error message
> levitte> Since -issuer_checks sets the X509_V_FLAG_CB_ISSUER_CHECK flag and > levitte> 'issuer' isn't the issuer of 'x' during those three calls, you can see > levitte> how come the callback gets called those three times. The callback in > levitte> question is the onw in apps/verify.c, which writes those lines you > levitte> saw. > > In other words, you don't need to worry about those lines... Does this mean that openssl verify command does not check the name chain and if I put the correct value in the issuer of x in apps/verify.c, I would not get the error? or does it check in somewhere else? Sincerely, -Kiyoshi Kiyoshi Watanabe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Help for openssl verify command and its strange error message
Dear all, I generated a CA self-signed certificate and an EE certificate and try to verify the cert name chain using the openssl-0.9.7-beta3. >openssl verify -issuer_checks -CAfile cacert.pem 01.pem I encounter the following message: 01.pem: /C=JP/O=TEST/OU=TESTORG/CN=EE01 error 29 at 0 depth lookup:subject issuer mismatch /C=JP/O=TEST/OU=TESTORG/CN=EE01 error 29 at 0 depth lookup:subject issuer mismatch /C=JP/O=TEST/OU=TESTORG/CN=EE01 error 29 at 0 depth lookup:subject issuer mismatch OK I check the subject and issuer names >openssl x509 -in cacert.pem -noout -text Issuer: C=JP, O=TEST, OU=TESTORG, CN=TESTCA Validity Not Before: Nov 6 11:56:42 2002 GMT Not After : Oct 28 11:56:42 2037 GMT Subject: C=JP, O=TEST, OU=TESTORG, CN=TESTCA >openssl x509 -in 01.pem -noout -text Issuer: C=JP, O=TEST, OU=TESTORG, CN=TESTCA Validity Not Before: Nov 6 11:56:55 2002 GMT Not After : Oct 29 11:56:55 2032 GMT Subject: C=JP, O=TEST, OU=TESTORG, CN=EE01 Looks ok to me. So I decide to see the exact content inside the binary file. >openssl x509 -in 01.pem -outform DER -out 01.der >openssl x509 -in cacert.pem -outform DER -out cacert.der >dumpasn1 -hh cacert.der Hex value of CA's subject name 30 3F 31 0B 30 09 06 03 55 04 06 13 02 4A 50 31 0D 30 0B 06 03 55 04 0A >dumpasn1 -hh 01.der ...Hex value of EE's issuer name 30 3F 31 0B 30 09 06 03 55 04 06 13 02 4A 50 31 0D 30 0B 06 03 55 04 0A I think that the two values are the same to me. Please let me know why the verify command tells me the subject issuer mismatch and how I could correct this problem. I am attaching the 2 certificate for your reference. Sincerely, -Kiyoshi Kiyoshi Watanabe Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=JP, O=TEST, OU=TESTORG, CN=TESTCA Validity Not Before: Nov 6 11:56:55 2002 GMT Not After : Oct 29 11:56:55 2032 GMT Subject: C=JP, O=TEST, OU=TESTORG, CN=EE01 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a3:19:33:f3:da:8a:9c:21:c5:93:b3:21:d7:70: 5d:a0:76:dc:8a:0e:85:1f:d4:62:3e:ba:f1:a1:97: e7:de:2a:b8:96:f8:3f:cb:49:a9:2e:70:b4:ef:1d: 16:39:24:6e:0a:e1:d8:81:b1:c2:f0:fe:83:a8:1e: 58:d2:1d:e7:a1:a7:7b:a2:ac:50:bc:ba:d4:9d:0b: 69:e0:a1:95:93:49:d7:3d:0b:df:81:76:2d:39:68: b5:b9:05:b5:cc:2c:90:84:47:13:0b:a9:37:5b:ba: 96:19:62:cf:02:f1:b0:3c:3d:4f:6f:46:87:2f:39: d4:27:33:22:1c:95:ea:b3:03 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:46:26:51:EE:72:2D:33:85:87:D2:59:3A:4A:B2:F5:D3:60:0E:1F:64 X509v3 Subject Key Identifier: 73:09:C5:4D:6A:09:06:5C:E3:85:58:F1:72:FE:7D:0C:5F:1F:96:2A X509v3 Key Usage: critical Digital Signature X509v3 Certificate Policies: Policy: 0.2.440.20013.1.2002.1.10.1 X509v3 CRL Distribution Points: URI:ldap://h-re.pki-j-sim.jp/cn=TestCA,ou=TESTMM2,o=PPTG,c=JP?certificateRevocationList;binary Signature Algorithm: sha1WithRSAEncryption 6b:c6:6e:20:1b:c0:8c:97:ee:79:b6:2f:22:c8:84:ca:cd:89: c2:7b:4f:57:2d:07:c6:d7:0a:de:60:38:09:c2:f8:c0:a9:f8: 29:fd:9f:16:f0:cf:1a:51:a9:12:7b:6a:ab:a6:4a:2b:10:f0: 32:28:66:f7:32:80:30:f7:4d:24:38:dd:e6:5f:86:61:70:1a: 3e:71:b5:69:85:e5:19:27:00:b3:3a:58:98:e3:cc:95:9d:5a: 9c:83:42:28:8f:53:ac:12:5a:13:2b:76:64:90:71:a1:0c:8f: 18:a5:f8:45:dc:5c:36:55:68:31:57:e6:99:90:72:b9:44:d2: 71:30:91:a4:d0:3f:48:9e:63:3c:fc:76:3c:41:61:10:35:ec: 43:0c:1c:09:10:17:b1:c8:d1:97:d8:ba:31:60:a6:8b:09:68: 38:cc:c1:78:35:6a:35:92:66:19:c7:e0:57:33:7a:c6:94:74: a3:c5:0f:e7:0c:ef:41:7a:84:df:85:a2:8f:6b:99:0a:24:e8: 45:d8:98:33:20:ca:e6:55:9e:d2:8d:cb:6d:25:13:38:2e:f2: 77:80:53:d9:6e:9c:4e:17:d6:85:41:d8:9a:df:6b:91:74:1d: e9:62:a1:ca:78:42:cc:4b:00:64:ca:87:14:1d:5f:42:fe:07: 32:92:05:77 -BEGIN CERTIFICATE- MIIDTzCCAjegAwIBAgIBATANBgkqhkiG9w0BAQUFADA/MQswCQYDVQQGEwJKUDEN MAsGA1UEChMEVEVTVDEQMA4GA1UECxMHVEVTVE9SRzEPMA0GA1UEAxMGVEVTVENB MB4XDTAyMTEwNjExNTY1NVoXDTMyMTAyOTExNTY1NVowPTELMAkGA1UEBhMCSlAx DTALBgNVBAoTBFRFU1QxEDAOBgNVBAsTB1RFU1RPUkcxDTALBgNVBAMTBEVFMDEw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKMZM/PaipwhxZOzIddwXaB23IoO hR/UYj668aGX594quJb4P8tJqS5wtO8dFjkkbgrh2IGxwvD+g6geWNId56Gne6Ks ULy61J0LaeChlZNJ1z0L34F2LTlotbkFtcwskIRHEwupN1u6lhlizwLxsDw9T29G hy851CczIhyV6rMDAgMBAAGjgdswgdgwH
Re: How to set a CRLNumber extension in CRL
Dear Steve,
Thank you for your comment. I understand the usage of this
extension and fully agree with you.
Best Regards,
-Kiyoshi
Kiyoshi Watanabe
> On Thu, Oct 03, 2002, Kiyoshi WATANABE wrote:
>
> >
> > Dear all, I want to know the way to implement to
> > set the CRLNumber extension in CRL using openssl-0.9.7 beta 3.
> >
>
> The extension is already supported, but not in the 'ca' application which
> generates CRLs.
>
> > In the crypto/x509v3 directory, there is a flie v3_ini.c. In this
> > source code, the X509V3_EXT_MEHTOD is already defined. Fisrt I think
> > that I should add the(X509V3_EXT_S2I)s2i_ASN1_INTEGER in the structure,
> > since the s2i_ASN1_INTEGER code is also defined in v3_util.c.
> >
> > 59 #include
> > 60 #include "cryptlib.h"
> > 61 #include
> > 62
> > 63 X509V3_EXT_METHOD v3_crl_num = {
> > 64 NID_crl_number, 0, ASN1_ITEM_ref(ASN1_INTEGER),
> > 65 0,0,0,0,
> > 66 (X509V3_EXT_I2S)i2s_ASN1_INTEGER,
> > 67 0,
> > 68 0,0,0,0, NULL};
> > 69
> >
> > In line 67, I will add the (X509V3_EXT_S2I)s2i_ASN1_INTEGER
> >
> > In the CRLNumber extension, the ASN.1 in RFC 3280 says:
> >
> >CRLNumber ::= INTEGER (0..MAX)
> >
> > Then I should define the ASN1 macro, but now I do no know how to
> > define the ASN1 macro to define the ASN.1.
> >
> > Looking at some others examples, if you have a sequence tag, the macro
> > will start like :
> >
> > ASN1_SEQUENCE()
> > ...
> > ASN1_SEQUENCE_END()
> >
> > However the CRLNumber is just INTEGER. I want to know simply just
> > define the macro to use or any pointer to take a look at.
> >
> > I would be very appreciated if you give me some suggestion.
> >
>
> Its already in there: ASN1_ITEM_ref(ASN1_INTEGER).
>
> What you cannot currently do, as I mentioned is to add this extension using
> the 'ca' application. There isn't an s2i_ASN1_INTEGER in the structure for a
> reason: this is to stop the extension being used in config files.
>
> Config files are fine for the static extensions whose value will be the same,
> however CRLNumber has to increase with each new CRL issued. If you could add
> CRLNumber from a config file this may well result in distinct CRLs having the
> same number which is a bad thing(tm).
>
> What is really needed is to handle CRLNumber as a special case, for example
> via a file which is treated in a similar way to the serial number and updated
> with each CRL issued.
>
> Steve.
> --
> Dr. Stephen Henson [EMAIL PROTECTED]
> OpenSSL Project http://www.openssl.org/~steve/
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing List[EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
How to set a CRLNumber extension in CRL
Dear all, I want to know the way to implement to
set the CRLNumber extension in CRL using openssl-0.9.7 beta 3.
In the crypto/x509v3 directory, there is a flie v3_ini.c. In this
source code, the X509V3_EXT_MEHTOD is already defined. Fisrt I think
that I should add the(X509V3_EXT_S2I)s2i_ASN1_INTEGER in the structure,
since the s2i_ASN1_INTEGER code is also defined in v3_util.c.
59 #include
60 #include "cryptlib.h"
61 #include
62
63 X509V3_EXT_METHOD v3_crl_num = {
64 NID_crl_number, 0, ASN1_ITEM_ref(ASN1_INTEGER),
65 0,0,0,0,
66 (X509V3_EXT_I2S)i2s_ASN1_INTEGER,
67 0,
68 0,0,0,0, NULL};
69
In line 67, I will add the (X509V3_EXT_S2I)s2i_ASN1_INTEGER
In the CRLNumber extension, the ASN.1 in RFC 3280 says:
CRLNumber ::= INTEGER (0..MAX)
Then I should define the ASN1 macro, but now I do no know how to
define the ASN1 macro to define the ASN.1.
Looking at some others examples, if you have a sequence tag, the macro
will start like :
ASN1_SEQUENCE()
...
ASN1_SEQUENCE_END()
However the CRLNumber is just INTEGER. I want to know simply just
define the macro to use or any pointer to take a look at.
I would be very appreciated if you give me some suggestion.
Sincerely,
-Kiyoshi
Kiyoshi Watanabe
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Checking certs against CRLs
> Is there some mechanism within the openssl library for checking a > certificate against a CRL? I expected to find a function that would > take a X509 *cert and an X509_CRL *crl as arguments, and give an > indication as to whether the certificate is listed in the CRL. I have > been unable to locate any such function to use in the library. Any help > appreciated See in crypto/x509/x509_vfy.c around static int cert_crl(X509_STORE_CTX *ctx, X509_CRL *crl, X509 *x) funcions This can be found from 0.9.7 JUST Info... -kiyoshi Kiyoshi Watanabe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Creating v1 certificate?
hi, would you tell me how to create v1 certificate? I am using the following command openssl req -new -x509 -newkey rsa:2048 -keyout and I commented out the following line. [req] ... #x509_extensions = v3_ca # The extentions to add to the self signed cert Any suggestions are appreciated! Thanks in advance! Kiyoshi, Kiyoshi Watanabe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Netscape Extension
Dear all, Let me ask that if I omit to specify the nsCertType extension, the certificate can be used for keyEncippherment even I specify the digitalSignature only in keyUsage? Does anyone knows that Netscape recognizes the keyUsage bit and limits the usage of the certificate? Regards, Kiyoshi, Kiyoshi WATANANBE Hitachi, Ltd. ---openssl.cnf-- # Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing. # # # For an object signing certificate this would be used. # nsCertType = objsign # # For normal client use this is typical # nsCertType = client, email # # and for everything including object signing: # nsCertType = client, email, objsign #nsCertType = client #nsCertType = email #nsCertType = objsign #nsCertType = client, email # This is typical in keyUsage for a client certificate. keyUsage = nonRepudiation, digitalSignature, keyEncipherment __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
