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: openssl-users@openssl.org 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: openssl-users@openssl.org 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.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'
THIS=${THIS:-build_crypto} MAKEFILE=Makefile MAKEOVERRIDES= TOP=.. DIR=$dir
$target ) || exit 1; fimake: Fatal error: Command failed for
target `build_crypto'
--
I would very appreciate if you could give
meany work around.
+Kiyoshi
Kiyoshi
Watanabe
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
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: 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: 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]
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 hy851CczIhyV6rMDAgMBAAGjgdswgdgwHwYDVR0jBBgwFoAURiZR7nItM4WH0lk6
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 stdio.h
60 #include cryptlib.h
61 #include openssl/x509v3.h
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: 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 stdio.h
60 #include cryptlib.h
61 #include openssl/x509v3.h
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]
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]
