I can't see how anything could cause an issue with 85 CAs. The attached
descriptions imply it might be a mod_ssl issue (not reproducible with
There is a bit more information now in our ticket:
Romain Wartel wrote:
> So 4 conditions need to be met to reproduce the bug:
> - More than ~85 root CAs installed (the exact number varies)
> - The host certificate has been issued by the CERN CA
> - OpenSSL is configured to check the client side certificate
> (optional or required)
> - Both the CERN-Root CA and the CERN-TCA CA have to be installed
However, Lassi A. Tuura then wrote:
> There is only one known condition triggering the problem,
> as quoted earlier in this thread: SSL re-negotiation response >= 12kB
> leads to failure to flush the data to socket leading to server and
> client to wait indefinitely for each other.
> There's any number of ways to trim or expand the SSL response size
> to cross that threshold.
The CERN CA has the second biggest size of all ~90 CAs currently
supported by IGTF, which might explain why only CERN services are
affected at this time. OTOH, it does not look very different from
others in the top 10:
Then again, we may need to add the size of the CERN _Root_ CA:
But there are other such chained CAs that do not cause problems...
I'd suggest trying OpenSSL 0.9.8k as well though because some code
changes might have an effect in that area.
Steve Traylen wrote:
> it hangs the same , remove a few cas and it works.
> # rpm -q httpd mod_ssl openssl fedora-release
Might it be worth trying 1.0.0 as well?
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager majord...@openssl.org