Thanks for the input! I see now how some of the options to the ocsp command would make sense (as it's being used as a test tool). What I was experimenting with here was the possibility to create a small module for Apache that could make an OCSP check before allowing a client to connect using client certificates, and the ocsp mode of OpenSSL would be perfect for that it seems.. And given that the SSLv3 client sends the actual cert chain to the server (except the root CA if I'm not mistaken), then one could extract the actual CAs needed from there and only trust the root CA, right??
Regarding Mozilla I'll take a look at how they handle the OCSP-checking. /Werner -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: den 4 augusti 2003 14:47 To: [EMAIL PROTECTED] Subject: Re: OpenSSL OCSP interaction Responses inline. On Mon, Aug 04, 2003, Werner Johansson wrote: > Hi list! > > (Tried posting this a few days back, but it got lost in the process, > trying again...) > > I have been experimenting with the OCSP "client" in OpenSSL, using a > command line like this: > > openssl ocsp -issuer level3ca.cer -cert enduser1.cer -url > http://ocsp-test -CAfile cafile.pem > > OpenSSL version is 0.9.7b compiled on Win32 using VS6.0. > > > The structure looks like this: > > Level1CA (Self-signed root, off-line, CRL being manually created every > six months) GlobalOCSPResponder > Level2CA (off-line, CRL being manually created every six months) > Level3CA (on-line, signing end-entity certs and CRLs) > Level3OCSPResponder > end-entity cert1 > end-entity cert2 > > > Case 1: > ------- > The CAfile.pem contains the Level1 CA only, and I'm trying to use the > "Global" OCSP responder which is directly signed by the root. This > gives me "root not trusted" error - but works fine if I run the > rootcert in cafile.pem through "addtrust ocspsigning" first, adding a > small sequence at the end.. The other way of getting openssl happy > here is to explicitly refer to the GlobalOCSP-certificate using > -VAfile. > > This seemed like a nice solution that could deal with all > end-entity-certs in the hierarchy, BUT when trying the same thing > using Mozilla 1.4 as an OCSP client I'm getting "Could not verify this > certificate for unknown reasons." as there seems to be no way of > "trusting" the root ca for ocsp-signing... > > Is this kind of setup supported, it seems that this scenario might not > be supported in RFC2560... ?? :( > RFC2560 has an option to use any other appropriate method to trust a public key. OpenSSL uses one method, other client may do something else. Mozilla looks like it can only set one trusted OCSP signer. Try under preferences->privacy&security->Validation then the part marked "Use OCSP preferences->to validate all certificates using this URL and signer". > > Case 2: > ------- > Here I'm using one OCSP-responder per CA (the Level3OCSPResponder in > my structure above). Obviously I need more than the root CA in the > CAfile.pem now, and as I see it only Level2 should have to be added, > so I give this a try, no -VAfile or anything strange with the root > certificate, and two CAs in the cafile (root and level2), and I get > this: > > > Response Verify Failure > 3756:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify > error:.\crypto\ocsp\ocsp_vfy.c:122:Verify error:unable to get local > issuer certificate > enduser1.cer: good > This Update: Jul 31 19:11:13 2003 GMT > > > This seems strange as the Level3-CA has already been given to openssl > through -issuer, and a quick adding of the level3-CA to cafile gives > me what I want: > > > Response verify OK > enduser1.cer: good > This Update: Jul 31 19:12:23 2003 GMT > > > Is this by design, or have I overlooked something obvious?? I'd rather > just have the first two levels of CA's in the file, as those are > unlikely to change, but other level3 CAs might be added. > > The case 2-setup also makes Mozilla happy, now it gives me the "This > certificate has been verified for the following uses:" message, which > states that this is the way to go?? > > Can anyone enlighten me a bit about the openssl handling of the > cert-chain in this case? > The ocsp command is meant to be a test frontend for the OpenSSL ocsp code so it may do things which aren't quite what you'd want. In general the issuer certificate of the CA being validated may not even be available (OCSP only really needs its public key hash) so the underlying APIs don't enforce its presence. You could howver have the OCSP responder supply the intermediate CAs in its response then you should only have to trust the root CA. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. ______________________________________________________________________ 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]
