I recently hit a pretty long certificate list with what appears to be crap past the end of its valid portion. I have no indication about how this was generated, but it is supposed to be in production within a CA, initially using a release of OpenLDAP without detailed CL validation in place (remember this was released in 2.4). I'm not posting this to the ITS because it's data I'm not allowed to disclose. To make a long story short, I got the CL in LDIF format; I could convert it to DER and have openssl crl play with it. Apparently, openssl crl recognizes it and deals with its contents correctly, but our CL validator fails because when it expects to be at the end there is still stuff to be parsed (some 40KB of what appears to be garbage). Howard found a small issue in CL validation and fixed it (schema_init.c 1.459 -> 1.460), but nevertheless the issue remains. Howard also discovered that regenerating the CL in DER form using openssl clr would yield a shorter certificate that passes OpenLDAP's validator. I'm raising it here because we need to understand how important it is for us to be able to deal with broken CL, and how broken we can accept them to be. In this case, the CL looks fine until the end, with garbage at the end. This could be tolerated. Or, we could just ignore any type of error, as soon as we don't need to deal with its contents (slapd is merely acting as a container, and needs not know whether it's containing good or bad data). This latter argument may be not valid as soon as our slapd takes over as much certificate handling as possible, performing certificate validation internally rather than delegating it to some external package (I understand Howard would probably like to follow that path, eventually). Unless there is strong opposition, I'd relax the last check about being at the end of the CL, in order to accept CL with this type of brokenness, possibly logging about the issue. p.