I definitely get better results with the latest snapshot. However I still don't get my "0 depth lookup:certificate revoked" but instead get a "0 depth lookup:CRL path validation error"
Looking at the differences between my application logic and verify.c, I see that the command line uses an X509 Lookup with a file source for -CAFile, where as I simply pass in a trusted chain in my verify call, which I can achieve in the verify app using the -trusted command line switch instead. /opt/openssl_1_0_0/bin/openssl verify -x509_strict -verbose -crl_check -extended_crl -CRLfile /tmp/ind.crl -untrusted /tmp/CA0iCRL.pem -trusted /tmp/CA0.pem /tmp/AdamRosenstein.pem /tmp/AdamRosenstein.pem: O = Red Condor, OU = PKI, CN = CA0iCRL [CRL path]error 20 at 0 depth lookup:unable to get local issuer certificate O = Red Condor, OU = PKI, CN = AdamRosenstein error 54 at 0 depth lookup:CRL path validation error Am I misunderstanding the intention of the trusted stack? Does openssl provide an in-memory x509 lookup method (from a stack of X509 *'s) or do I have to roll my own? Thanks for all of your answers Dr Henson, Adam Rosenstein > -----Original Message----- > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Dr. Stephen Henson > Sent: Saturday, October 31, 2009 6:54 AM > To: openssl-users@openssl.org > Subject: Re: your mail > > On Fri, Oct 30, 2009, Adam Rosenstein wrote: > > > > > Ahh, that explains it. Thanks for looking into it. > > > > > > > > The documentation on iCRLs was a little cryptic to me. It said that > no > > > > lookup methods were used (?). Now you say the store is also not > used. > > > How > > > > do I get the iCRL into the verification process? Also, does the > current > > > > 1.0.0 icrl code enforce the "same trust-anchor" method of tying iCRL > > > issuer > > > > to the CA it is revoking for? > > > > > > > > > > You can get CRLs into the process using X509_STORE_CTX_set0_crls(). As > > > > Hmmm... my code does that but I get 'Different CRL Scope' on the SNAP > from > > the 26th. > > > > I've just committed my changes, they don't touch the verify code just adds > an > option to the verify utility. > > This is what I now get from your certs: > > openssl verify -verbose -crl_check -extended_crl -CRLfile crls > -untrusted certs -CAfile root.pem ee.pem > > ee.pem: O = Red Condor, OU = PKI, CN = AdamRosenstein > error 23 at 0 depth lookup:certificate revoked > > > > indicated in the docs, some protocols (PKCS#7 and CMS) do this > > > automatically. > > > > > > > A pkcs7 with crls in the container will automatically use them? Cool. > How > > do you tell the p7 verify function when you want to require crl checking > for > > each cert in the chain (X509_V_FLAG_CRL_CHECK_ALL) and when you just > want EE > > checking. > > You set up verification parameters as usual and then call: > > X509_STORE_set1_param(store, param); > > Then when you call PKCS7_verify() (or preferably CMS_verify() ) any CRLs > in > the PKCS#7 structure are automatically used. This works on any API that > takes > an X509_STORE parameter. > > > Also, this raises another question. I was using P7's without > > data as nice 'identity chain containers' (.p7c files) rather than > > concatenated PEM files. Of course I have to unpack them to verify the > > identity. The docs make the p7 verify function seem to be basically > about > > the data: > > > > The type of p7 must be signedData. There must be at least one > signature > > on the data and if the content is detached indata cannot be NULL. > > > > If I call p7 verify with PKCS7_NOSIGS can I verify an "empty" p7 that > has > > only certs and crls? > > > > No because the code needs to know which certificate(s) to verify. It does > that > by locating the signer(s) certificates and using any certificates or CRLs > present as well. So you need a signature with the EE certificate on it for > this to work. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
