RE: ISO 15782-2
RFC2459 was obsoleted by RFC3280 - so just read this one. Regards, Jochen. > This is a general problem with the ISO documentation. The IETF > response was to generate a "profile" of X.509 for use in the > Internet; this document was also designed to give readers enough > information to skip reading the ISO document itself. > > Suggest you read this document: > > Internet X.509 Public Key Infrastructure Certificate and > CRL Profile > > This is Internet RFC 2459 and Chapter 6 is all about > Certificate Path Validation > > > There is reference to ISO 15782-2 standard in the X.509 and X9.68 > > documentation. This standard describes certificate verification > > process. I try to find this document, but meet only payd links. The > > price of 122 CHF is so expencive. Can anybody help me with this > > document? > > -- > > Charles B. (Ben) Cranston > mailto:zben@;umd.edu > 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: ISO 15782-2
This is a general problem with the ISO documentation. The IETF response was to generate a "profile" of X.509 for use in the Internet; this document was also designed to give readers enough information to skip reading the ISO document itself. Suggest you read this document: Internet X.509 Public Key Infrastructure Certificate and CRL Profile This is Internet RFC 2459 and Chapter 6 is all about Certificate Path Validation > There is reference to ISO 15782-2 standard in the X.509 and X9.68 > documentation. This standard describes certificate verification > process. I try to find this document, but meet only payd links. The > price of 122 CHF is so expencive. Can anybody help me with this > document? -- Charles B. (Ben) Cranston mailto:zben@;umd.edu http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [Crypt::SSLeay] make test fails on Linux
on 10/29/02 11:44 AM, [EMAIL PROTECTED] purportedly said: > I've just found another post on the ml archives > concerning my problem, but didn't find any reply, so: > > root@hwsx:~/.cpan/build/Crypt-SSLeay-0.45# make test > > PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib > -I/usr/lib/perl5/i386-linux -I/usr/lib/perl5 -e 'use Test::Harness > qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t > t/net_ssl...dubious > Test returned status 0 (wstat 11, 0xb) > t/ssl_context...dubious > Test returned status 0 (wstat 11, 0xb) > FAILED--2 test scripts could be run, alas--no output ever seen > make: *** [test_dynamic] Error 2 It can be many things. What URL did you provide for testing? Can you access that URL through your browser? Keary Suska Esoteritech, Inc. "Leveraging Open Source for a better Internet" __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ISO 15782-2
Hi, There is reference to ISO 15782-2 standard in the X.509 and X9.68 documentation. This standard describes certificate verification process. I try to find this document, but meet only payd links. The price of 122 CHF is so expencive. Can anybody help me with this document? -- Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OCSP request/response signing
Howard, My understanding is that there is no implied relationship between the request and response signing certificates and any certificates being verified. The request and response certificates just need to be verifiable on their own by the recipient. That assures that the request or response is coming from the expected party (or at least one who holds the private key for the signing certificate). The request is signed by any certificate (-signer, -signkey) issued by any CA known by the responder. There are two options to verify that the response comes from the expected source. One is similar to the request: the response is signed by any certificate issued by a CA specified (-CAfile option) among the OCSP client options. The second is to expect the response to be signed by a specific certificate (-VAfile option) specified among the OCSP client options. This is the way I understand it to work with the OpenSSL client and responder. -Bob -Original Message- From: Howard Chan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 29, 2002 10:41 PM To: [EMAIL PROTECTED] Subject: Re: OCSP request/response signing Dear all (Bob), Thank you. I see evidence of response verification and OCSP client/server works fine, I know. However, I'm still unclear with the relationships between the : 1) CA root cert which signed the certs I'm checking the status on, 2) OCSP request signing cert from client, 3) OCSP request verification cert from server, 4) OCSP response signing cert from server, and finally 5) OCSP response verification cert from client. I'm using version 0.9.7 beta 3 right now. Please also view my comments below. Thank you. - Howard - Original Message - From: Bob Kupperstein To: [EMAIL PROTECTED] Sent: Tuesday, October 29, 2002 11:09 PM Subject: RE: OCSP request/response signing Here’s my understanding, and it seems to work using the OpenSSL OCSP client and responder, provided the appropriate certificates are installed in the right places (I’m using a 0.9.7 stable release from 9/02. -Bob -Original Message- From: Howard Chan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 29, 2002 6:11 AM To: [EMAIL PROTECTED] Subject: OCSP request/response signing Hello all, I'm working with Openssl 0.9.7beta3's OCSP command, both client and server. I'm a bit puzzled with how to establish the following : 1. Signed requests from client The OCSP request should be signed by a CA that is known by the responder. HCHAN>>So I should sign the requests with the CA cert (ie. cacert.pem) Weird! 2. Request verification from server The responder can verify the request if it has the CA certificate of the CA that signed the OCSP request. HCHAN>>I see no evidence from the Request/Response output of any Request verification. How do I know it's doing this? 3. Signed responses from server The OCSP response should be signed with a specific certificate that is known by the client, or by any certificate signed by a CA known by the client. HCHAN>>From defining "-rsigner" of my ocsp server command, I MUST point it to a cert which is signed by the root CA (which signed the cert I'm checking the status for), and this cert must also contain the corresponding private key. Am I right or wrong here? 4. Response verification from client The OCSP client can accept a VA certificate argument (a known certificate from a particular responder that is used as the response certificate) or a CA certificate argument (specifying which CA is signing the OCSP response). HCHAN>>I'm notsure whether to use "-VAfile" or "-CAfile". Doing what I noted above for "-rsigner", can't I just parse this same cert (it's public portion only) to "-CAfile" or "-VAfile"? I know it fails when I use "-CAfile" and succeeds with "-VAfile". I cannot explain why!! Do you know?
Re: Problem creating signed certs
Mike... In the log you send shows: -The countryName field needed to be the same in the -CA certificate (AU) and the request (US) that's mean that you have in your configuration file (openssl.cnf) a sentence that don't let that the CA authority be from another country that the country of the client. That's why your certificate is left in blank... Regards, Adriano El mié, 30-10-2002 a las 01:01, MikeCC escribió: > Hello, > > I am trying to create a signed client certificate, but when I execute the > command > > openssl ca -in req.pem -out newcert.pem > > The newcert.pem file is created but it is created as an empty file. > > Here is what I see on the display: > > /openssl-engine-0.9.6g/apps > openssl ca -in req.pem -out newcert.pem > Using configuration from /usr/local/ssl/openssl.cnf > Check that the request matches the signature > Signature ok > The Subjects Distinguished Name is as follows > countryName :PRINTABLE:'US' > stateOrProvinceName :PRINTABLE:'MA' > localityName :PRINTABLE:'Arlington' > organizationName :PRINTABLE:'Brandywine mills' > organizationalUnitName:PRINTABLE:'Hobbiton' > commonName:PRINTABLE:'Frodo' > emailAddress :IA5STRING:'[EMAIL PROTECTED]' > The countryName field needed to be the same in the > CA certificate (AU) and the request (US) > > /openssl-engine-0.9.6g/apps > ls -l newcert.pem > -rw-r--r--1 root root0 Oct 29 22:29 newcert.pem > > Can anyone help me understand what I'm missing or doing incorrectly? > > > > == > Mike Cerone, CISSP, CCNA > Ad Astra! > == > __ > 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: SUN Crypto Accelerator + OpenSSL
On Wed, Oct 30, 2002, Joerg Bartholdt wrote about "Re: SUN Crypto Accelerator + OpenSSL": > Edward Chan wrote: > > > Hmm, so does that mean with the SUN Crypto Accelerator > > 1000 card, we would specify "ubsec" when initializing > > the engine? > > I tried > > openssl speed -engine ubsec > > but it complained as with any other engine id: > > can't use that engine > 4683:error:25067066:DSO support routines:DLFCN_LOAD:could not load the shared >library:dso_dlfcn.c:157: Do you have /usr/lib/libubsec.so (or whatever path mod_ssl expecects)? You'll need to compile that seperately from Apache/modssl. (Note that if you're using Red Hat Linux, for example, the "bcm5820" package that comes with Redhat already contains that shared library, so all you need to do is to make that package is installed). -- Nadav Har'El| Wednesday, Oct 30 2002, 24 Heshvan 5763 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |Attention: There will be a rain dance http://nadav.harel.org.il |Friday night, weather permitting. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SUN Crypto Accelerator + OpenSSL
Edward Chan wrote: > Hmm, so does that mean with the SUN Crypto Accelerator > 1000 card, we would specify "ubsec" when initializing > the engine? I tried openssl speed -engine ubsec but it complained as with any other engine id: can't use that engine 4683:error:25067066:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:157: 4683:error:25072066:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:230: 4683:error:260A6068:engine routines:UBSEC_INIT:DSO failure:hw_ubsec.c:347: 4683:error:2607E06D:engine routines:ENGINE_SET_DEFAULT_TYPE:init failed:engine_lib.c:400: No answer from SUN support yet. Joerg __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
X509v1 root CA certificate
Hi everybody, OpenSSL 0.9.7b3 tells me "error=24 (invalid CA certificate)" in the verify_callback when I use a certificate chain where the CAs are X509 version 1 (i.e. they are missing the X509v3 extension that says that the CA certificate is good for signing other public keys). I checked the code and there is only one place that emits X509_V_ERR_INVALID_CA, in x509_vfy.c:396. if (!X509_check_purpose(x, ctx->purpose, i)) { if (i) ctx->error = X509_V_ERR_INVALID_CA; else ctx->error = X509_V_ERR_INVALID_PURPOSE; Is there any reason, why a CA cannot have a version1 certificate? I also did not find an option to set on the SSL_CTX to allow CA with x509v1. Any idea ? Thanks a lot, Joerg __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Problem creating signed certs
Hi your should check openssl.cnf file find policy section and change your countryName = match to something like this "supplied or optional" depends on policy Anton -Original Message- From: MikeCC [mailto:mikecc@;atrek.org] Sent: Wednesday, October 30, 2002 07:02 To: [EMAIL PROTECTED] Subject: Problem creating signed certs Hello, I am trying to create a signed client certificate, but when I execute the command openssl ca -in req.pem -out newcert.pem The newcert.pem file is created but it is created as an empty file. Here is what I see on the display: /openssl-engine-0.9.6g/apps > openssl ca -in req.pem -out newcert.pem Using configuration from /usr/local/ssl/openssl.cnf Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'US' stateOrProvinceName :PRINTABLE:'MA' localityName :PRINTABLE:'Arlington' organizationName :PRINTABLE:'Brandywine mills' organizationalUnitName:PRINTABLE:'Hobbiton' commonName:PRINTABLE:'Frodo' emailAddress :IA5STRING:'[EMAIL PROTECTED]' The countryName field needed to be the same in the CA certificate (AU) and the request (US) /openssl-engine-0.9.6g/apps > ls -l newcert.pem -rw-r--r--1 root root0 Oct 29 22:29 newcert.pem Can anyone help me understand what I'm missing or doing incorrectly? == Mike Cerone, CISSP, CCNA Ad Astra! == __ 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]
Problem creating signed certs
Hello, I am trying to create a signed client certificate, but when I execute the command openssl ca -in req.pem -out newcert.pem The newcert.pem file is created but it is created as an empty file. Here is what I see on the display: /openssl-engine-0.9.6g/apps > openssl ca -in req.pem -out newcert.pem Using configuration from /usr/local/ssl/openssl.cnf Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'US' stateOrProvinceName :PRINTABLE:'MA' localityName :PRINTABLE:'Arlington' organizationName :PRINTABLE:'Brandywine mills' organizationalUnitName:PRINTABLE:'Hobbiton' commonName:PRINTABLE:'Frodo' emailAddress :IA5STRING:'[EMAIL PROTECTED]' The countryName field needed to be the same in the CA certificate (AU) and the request (US) /openssl-engine-0.9.6g/apps > ls -l newcert.pem -rw-r--r--1 root root0 Oct 29 22:29 newcert.pem Can anyone help me understand what I'm missing or doing incorrectly? == Mike Cerone, CISSP, CCNA Ad Astra! == __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]