My answer was incorrect...
What happens when trying to find a CRL is that get_cert_by_subject (in
crypto/x509/by_dir.c) gets called, and it will try to load every file it finds
(so both $hash{sub_ca}.r0 and $hash{sub_ca}.r1). However, when trying to
storing them in the internal store, it will only do so if no other object with
the same hash is already there. Hence, $hash{sub_ca}.r1 will essentially be
ignored.
Either way, if both CRLs (with the same issuer name) were stored internally, it
would still be a good question which one would actually be used. How would that
be determined.
I suggest you try with replacing the old with the new.
Furthermore, I'm not sure this is a bug, at least in current OpenSSL. Maybe
this will be reconsidered in the future, but that will certainly be seen as a
new feature.
Time to close this ticket.
Cheers,
Richard
On Tue Jul 19 08:31:18 2016, levitte wrote:
> So let me see if I understand this correctly... $hash(sub_ca).r1 and
> $hash(sub_ca).r0, being of the same sub_ca, will of course have the
> same issuer
> name. Right?
>
> Unless I misread the source, OpenSSL will actually load both files.
> However,
> since both CRLs have the same issuer, and cached CRLs are looked up by
> issuer
> name, only one of them will be used (whichever the code happens to
> find first).
>
> If one of those CRLs was a delta CRL, things might work differently
> (I'm
> frankly not sure, I haven't experimented with that, and haven't spent
> enough
> time studying that part of the code)... I assume that this isn't the
> case.
>
> Is there a reason in particular you want to have two active CRLs for
> the
> sub-CA? Does simply replacing the old with the new now work for you
> somehow?
>
> Cheers,
> Richard
>
> On Thu Jul 14 11:25:22 2016, patel3.anir...@gmail.com wrote:
> > Hi,
> >
> > I have a query related to how these APIs X509_STORE_add_lookup()
> > and X509_LOOKUP_add_dir() work. Let me give you a brief explanation
> > of what
> > I am doing:
> >
> > Purpose was to add lookup for CRLs.
> >
> > First when my server starts and my SSL initializes I have
> > successfully
> > created a store to which lookup has been added for CRL directory.
> >
> > - pLookup = X509_STORE_add_lookup(store, X509_LOOKUP_hash_dir());
> > - X509_LOOKUP_add_dir(pLookup, mCRLPath.c_str(), X509_FILETYPE_PEM)
> >
> > Example CRL Directory: /var/cert/CRL/
> > Scenario:
> > 1) When the system start no CRL files are present in the CRL
> > Directory
> > 2) Client_1 initiates a connection to my server (using openssl
> > s_client)
> > 3) Openssl does the lookup of CRLs for the corresponding (Sub) CAs
> > and does
> > not find anything thus, giving error in the verify_callback
> > (UNABLE_TO_GET_CRL). In the application code I have handled these
> > errors gracefully Callback is again called for further validation and
> > the
> > connection is accepted.
> > *Result: Satisfied*
> >
> > 1) Now, I place two CRLs (Sub CA,Root CA) in the CRL directory
> > (server was
> > still up and I did not stopped it)
> > I have created a crl -hash (issuer hash) and linked them to CRL pem
> > certificates.
> > *$hash(rootca).r0 -> root_ca.pem*
> > *$hash(subca).r0 -> sub_ca.pem*
> > 2) Client_1 again initiates a connection to my server (using openssl
> > s_client) (client certificate chain is : ID/Sub CA/Root CA)
> > 3) Openssl does a lookup of CRLs and does not throw any error.
> > Validation
> > happened with verify_callback getting invoked 3 times with
> > preverify_ok =
> > 1. Client connection is accepted
> > *Result: Satisfied*
> >
> > 1) Now, I removed the above CRL files (Sub CA/Root CA) from the CRL
> > directory. Based on the manual page these CRLs should be now in the
> > cached
> > memory of X509_OBJECT.
> > 2) I repeated steps (2) and (3). Connection gets accepted from the
> > client.
> > Everything still works fine because openssl maintined CRL files in
> > its
> > cache and found them during the lookup.
> > *Result: Satisfied*
> >
> > Now from here the problem starts:
> > =========================
> > 1) My Sub_CA revoked Client_1 certificate (since Sub_CA was the
> > issuing CA
> > in the first place)
> > 2) I recreated Sub_CA CRL and placed it in the CRL Directory.
> > 3) Created the hash and linked it as follows:
> > *$hash(sub_ca).r1* -> sub_ca.pem (hoping that openssl still has
> > $hash(sub_ca).r0 in its cache, since above we have seen that the
> > lookup
> > worked even when I removed the CRL files from the CRL Directory)
> > 4) Client_1 initiates a connection to my server and gets accepted
> > successfully ==== Should Not Have Happened
> > Based on the manual page for *X509_LOOKUP_hash_dir
> > - https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html
> > <https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html>*
> >
> > > When checking for new CRLs once one CRL for given hash value is
> > > loaded,
> > > hash_dir lookup method checks only for certificates with sequence
> > > number
> > > greater than that of the already cached CRL.
> >
> > Since, the sequence number has changed from r0 to r1 for same issuer
> > (sub_ca in my case) openssl should have done a lookup and based on
> > the
> > latest sequence number should have given me an error stating Client
> > Certificate has been revoked.
> >
> > Just to let you know, I have tested revoked certificates with the CRL
> > and
> > it works fine. So no problem with that.
> > Openssl Version I am using is *OpenSSL 1.0.1e-fips 11 Feb 2013*
> >
> > Eagerly awaiting your response. Need to implement CRL functionality
> > ASAP
> > and hoping to get all the help from you guys.
> >
> > Regards,
> > Anirudh
>
>
> --
> Richard Levitte
> levi...@openssl.org
--
Richard Levitte
levi...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
