>From the looks of the PR1424 code, that original patch is not going to work, and has been resolved in another way (the code has to take CRLs and delta CRLs into account, all from the same issuer)
If my analysis is correct, your call to add_crl should produce and error: Can you check if, when adding your new new CRL, X509_STORE_add_crl produces and error code X509_R_CERT_ALREADY_IN_HASH_TABLE - because you MUST get an error when your crl is not added to the collection. ERR_print_errors() or something similar (see err.h / ERR lib man page) can show you the error. Code: CRLs are matched inside the call to X509_OBJECT_retrieve_match() by checking the issuer, then the CRL SHA1 hash. X509_STORE_add_crl() uses X509_OBJECT_retrieve_match() to check if the given CRL is already in the collection. X509_OBJECT_retrieve_match() produces a non-NULL answer when: - the CRL issuer matches with one or more entries found in the store (X509_CRL_cmp) AND - the CRL hash EQUALS the hash of one of those issuer-matching CRLs already in the store. (X509_CRL_match) Hence it hinges on the hash match: a new CRL should have a different hash then a previous CRL. Two possibilities arise then: - either the hash doesn't cover all relevant fields OR - new CRL and old CRL have the same content, thus producing the same hash. The hash is calculated using the X509_CRL_digest() function; it is useful to ensure the old and new CRL data structure produce different hash values indeed (and if not, well, that's a hint when the CRL is not added (updated) while you get an error code. When you do not get an error report, the CRL is pushed into the store and the CRL count should've gone up by one after vs. before the call to X509_add_crl. The number of CRLs in store can be determined through the X509_OBJECT_idx_by_subject() function, where the type argument == X509_LU_CRL and the name argument should be your CRL issuer name. On Thu, Apr 9, 2009 at 9:03 AM, Mike McCauley via RT <[email protected]> wrote: > Hi All, > > I have found that if you use X509_STORE_add_crl in an attempt to update a CRL > for the same issuer that has previously been added, the old CRL is left in > the store and the updated CRL is not added. > > There appears to be no other way to remove an existing CRL, nor to force an > update, so there seems to be no way to freshen/replace a CRL in a > long-running server. > > In 2006 Donn Cave submitted a report and patch for this problem see > http://rt.openssl.org/Ticket/Display.html?id=1424&user=guest&pass=guest > > but it appears this patch has not been applied yet. > > Can we please have a fix for this problem, or at least have the patch applied? > > Cheers. > > > -- > Mike McCauley [email protected] > Open System Consultants Pty. Ltd > 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au > Phone +61 7 5598-7474 Fax +61 7 5598-7070 > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, DIAMETER etc. Full source > on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [email protected] mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
