Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Hi Steve, Do you also agree with David's proposal to change the calls to BIO_ctrl(, BIO_CTRL_INFO, ) into BIO_wpending() in ssl/*.c? It seems to make sense to me. Yes, I've applied it to all branches now. Many thanks David. Ticket resolved. Just a postscript to the issue. The above minimal fix was applied to OpenSSL but the lack of a corresponding Apache fix has resulted in some problems, not least of which is renegotiation not working because the server hello request is not flushed. As a result the OpenSSL change has been updated to call BIO_CTRL_INFO and if that returns zero BIO_CTRL_WPENDING. This should now cover all cases. Thanks for that fix and for informing us. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
[steve - Fri Jun 26 17:06:22 2009]: [jor...@redhat.com - Fri Jun 26 13:52:18 2009]: On Thu, Jun 25, 2009 at 06:05:08PM +0200, Stephen Henson via RT wrote: I agree with the analysis. Do you also agree with David's proposal to change the calls to BIO_ctrl(, BIO_CTRL_INFO, ) into BIO_wpending() in ssl/*.c? It seems to make sense to me. Yes, I've applied it to all branches now. Many thanks David. Ticket resolved. Just a postscript to the issue. The above minimal fix was applied to OpenSSL but the lack of a corresponding Apache fix has resulted in some problems, not least of which is renegotiation not working because the server hello request is not flushed. As a result the OpenSSL change has been updated to call BIO_CTRL_INFO and if that returns zero BIO_CTRL_WPENDING. This should now cover all cases. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Hi Steve, Do you also agree with David's proposal to change the calls to BIO_ctrl(, BIO_CTRL_INFO, ) into BIO_wpending() in ssl/*.c? It seems to make sense to me. Yes, I've applied it to all branches now. Many thanks David. Ticket resolved. Just a postscript to the issue. The above minimal fix was applied to OpenSSL but the lack of a corresponding Apache fix has resulted in some problems, not least of which is renegotiation not working because the server hello request is not flushed. As a result the OpenSSL change has been updated to call BIO_CTRL_INFO and if that returns zero BIO_CTRL_WPENDING. This should now cover all cases. Thanks for that fix and for informing us. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
On Thu, Jun 25, 2009 at 06:05:08PM +0200, Stephen Henson via RT wrote:
[david.sm...@cern.ch - Tue Jun 23 11:06:26 2009]:
The bug report over on the apache tracker:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46952
has been updated - there is a utility to generate a set of CA
certificates, which should allow one to reproduce the problem and more
information about when the failure has been seen.
I also sent an analysis of the sequence of events leading up to the
problem; and a trial fix - meaning that I see that it does fix the
problem but I'd like the community's opinion on the approach. Could
some of the openssl developers follow the link and consider the
analysis and possibly the change?
I agree with the analysis.
Do you also agree with David's proposal to change the calls to
BIO_ctrl(, BIO_CTRL_INFO, ) into BIO_wpending() in ssl/*.c? It seems to
make sense to me.
An alternative normally would be to try and flush any pending data in
the BIO state machine on subsequent I/O calls (i.e. including a
subsequent read) but since there can be separate read and write bios
in OpenSSL that's not guaranteed to work.
This is a good point. We already do this conditionally, in fact.
David, could you try this mod_ssl patch as an alternative solution,
which doesn't necessitate fixes to OpenSSL?
Index: ssl_engine_io.c
===
--- ssl_engine_io.c (revision 787722)
+++ ssl_engine_io.c (working copy)
@@ -481,7 +481,7 @@
* OpenSSL calls BIO_flush() at the appropriate times for
* the other protocols.
*/
-if ((SSL_version(inctx-ssl) == SSL2_VERSION) || sslconn-is_proxy) {
+if (1 || (SSL_version(inctx-ssl) == SSL2_VERSION) || sslconn-is_proxy) {
if (bio_filter_out_flush(inctx-bio_out) 0) {
bio_filter_out_ctx_t *outctx =
(bio_filter_out_ctx_t *)(inctx-bio_out-ptr);
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
On Thu, Jun 25, 2009 at 06:05:08PM +0200, Stephen Henson via RT wrote:
[david.sm...@cern.ch - Tue Jun 23 11:06:26 2009]:
The bug report over on the apache tracker:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46952
has been updated - there is a utility to generate a set of CA
certificates, which should allow one to reproduce the problem and more
information about when the failure has been seen.
I also sent an analysis of the sequence of events leading up to the
problem; and a trial fix - meaning that I see that it does fix the
problem but I'd like the community's opinion on the approach. Could
some of the openssl developers follow the link and consider the
analysis and possibly the change?
I agree with the analysis.
Do you also agree with David's proposal to change the calls to
BIO_ctrl(, BIO_CTRL_INFO, ) into BIO_wpending() in ssl/*.c? It seems to
make sense to me.
An alternative normally would be to try and flush any pending data in
the BIO state machine on subsequent I/O calls (i.e. including a
subsequent read) but since there can be separate read and write bios
in OpenSSL that's not guaranteed to work.
This is a good point. We already do this conditionally, in fact.
David, could you try this mod_ssl patch as an alternative solution,
which doesn't necessitate fixes to OpenSSL?
Index: ssl_engine_io.c
===
--- ssl_engine_io.c (revision 787722)
+++ ssl_engine_io.c (working copy)
@@ -481,7 +481,7 @@
* OpenSSL calls BIO_flush() at the appropriate times for
* the other protocols.
*/
-if ((SSL_version(inctx-ssl) == SSL2_VERSION) || sslconn-is_proxy) {
+if (1 || (SSL_version(inctx-ssl) == SSL2_VERSION) || sslconn-is_proxy) {
if (bio_filter_out_flush(inctx-bio_out) 0) {
bio_filter_out_ctx_t *outctx =
(bio_filter_out_ctx_t *)(inctx-bio_out-ptr);
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
On Jun 26, 2009, at 2:40 PM, Joe Orton wrote: This is a good point. We already do this conditionally, in fact. David, could you try this mod_ssl patch as an alternative solution, which doesn't necessitate fixes to OpenSSL? Index: ssl_engine_io.c [...] Hello Joe, Thanks for the mod_ssl only patch; I confirm this does solve our problem, in tests. So this should be sufficient for us - I'd be happy to leave it up to Stephen to consider if he wants to use BIO_wpending calls rather than the BIO_ctrl(...BIO_CTRL_INFO...) calls in ssl/*.c or not. Yours, David -- - David Smith e-mail: david.sm...@cern.chtel: +41 22 76 70677 Address: D. Smith, CERN G20610, Bat 31 2-004, 1211 Geneva 23, Switzerland - smime.p7s Description: S/MIME cryptographic signature
[openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
[jor...@redhat.com - Fri Jun 26 13:52:18 2009]: On Thu, Jun 25, 2009 at 06:05:08PM +0200, Stephen Henson via RT wrote: I agree with the analysis. Do you also agree with David's proposal to change the calls to BIO_ctrl(, BIO_CTRL_INFO, ) into BIO_wpending() in ssl/*.c? It seems to make sense to me. Yes, I've applied it to all branches now. Many thanks David. Ticket resolved. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
On Jun 26, 2009, at 2:40 PM, Joe Orton wrote: This is a good point. We already do this conditionally, in fact. David, could you try this mod_ssl patch as an alternative solution, which doesn't necessitate fixes to OpenSSL? Index: ssl_engine_io.c [...] Hello Joe, Thanks for the mod_ssl only patch; I confirm this does solve our problem, in tests. So this should be sufficient for us - I'd be happy to leave it up to Stephen to consider if he wants to use BIO_wpending calls rather than the BIO_ctrl(...BIO_CTRL_INFO...) calls in ssl/*.c or not. Yours, David -- - David Smith e-mail: david.sm...@cern.chtel: +41 22 76 70677 Address: D. Smith, CERN G20610, Bat 31 2-004, 1211 Geneva 23, Switzerland - smime.p7s Description: S/MIME cryptographic signature
[openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
[david.sm...@cern.ch - Tue Jun 23 11:06:26 2009]: Hello, The bug report over on the apache tracker: https://issues.apache.org/bugzilla/show_bug.cgi?id=46952 has been updated - there is a utility to generate a set of CA certificates, which should allow one to reproduce the problem and more information about when the failure has been seen. I also sent an analysis of the sequence of events leading up to the problem; and a trial fix - meaning that I see that it does fix the problem but I'd like the community's opinion on the approach. Could some of the openssl developers follow the link and consider the analysis and possibly the change? I agree with the analysis. An alternative normally would be to try and flush any pending data in the BIO state machine on subsequent I/O calls (i.e. including a subsequent read) but since there can be separate read and write bios in OpenSSL that's not guaranteed to work. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Hello, The bug report over on the apache tracker: https://issues.apache.org/bugzilla/show_bug.cgi?id=46952 has been updated - there is a utility to generate a set of CA certificates, which should allow one to reproduce the problem and more information about when the failure has been seen. I also sent an analysis of the sequence of events leading up to the problem; and a trial fix - meaning that I see that it does fix the problem but I'd like the community's opinion on the approach. Could some of the openssl developers follow the link and consider the analysis and possibly the change? Thanks, David -- - David Smith e-mail: david.sm...@cern.chtel: +41 22 76 70677 Address: D. Smith, CERN G20610, Bat 31 2-004, 1211 Geneva 23, Switzerland - smime.p7s Description: S/MIME cryptographic signature
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
On Mon, Jun 15, 2009, Kyle Hamilton wrote: These scripts pull the latest version of the Mozilla-approved CAs. OpenSSL is not in the business of making CA certificates available, but having the ability to do this in the stock package might be very good for the users. (Make sure that such a tool warns the user that the CA certificates are those made available by Mozilla, not the OpenSSL team, and that there's no warranty from OpenSSL on their use or misuse, such as not checking the hashes against the official locations for each CA.) Under Windows it is possible to use the CryptoAPI ENGINE to dump the standard root store in PEM format using for example: openssl engine capi -t -post store_name:ROOT -post list_options:10 -post list_certs bundle.pem Though this should be pruned to ensure no inappropriate CAs are included. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Hi Stephen, 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 s_server). There is a bit more information now in our ticket: https://savannah.cern.ch/bugs/?48458 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: 1e12d831.0 2594 1d879c6c.0 2204 9ff26ea4.0 2143 55994d72.0 2029 9dd23746.0 1996 0a2bac92.0 1976 f5ead794.0 1919 03aa0ecb.0 1907 6fee79b0.0 1903 fe102e03.0 1900 Then again, we may need to add the size of the CERN _Root_ CA: d254cc30.0 1350 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 httpd-2.2.11-8.x86_64 mod_ssl-2.2.11-8.x86_64 openssl-0.9.8k-4.fc11.x86_64 fedora-release-11-1.noarch Might it be worth trying 1.0.0 as well? Thanks, Maarten __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Hi Stephen, 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 s_server). There is a bit more information now in our ticket: https://savannah.cern.ch/bugs/?48458 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: 1e12d831.0 2594 1d879c6c.0 2204 9ff26ea4.0 2143 55994d72.0 2029 9dd23746.0 1996 0a2bac92.0 1976 f5ead794.0 1919 03aa0ecb.0 1907 6fee79b0.0 1903 fe102e03.0 1900 Then again, we may need to add the size of the CERN _Root_ CA: d254cc30.0 1350 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 httpd-2.2.11-8.x86_64 mod_ssl-2.2.11-8.x86_64 openssl-0.9.8k-4.fc11.x86_64 fedora-release-11-1.noarch Might it be worth trying 1.0.0 as well? Thanks, Maarten __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Maarten Litmaath wrote: Hi Stephen, 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 s_server). There is a bit more information now in our ticket: https://savannah.cern.ch/bugs/?48458 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: 1e12d831.0 2594 1d879c6c.0 2204 9ff26ea4.0 2143 55994d72.0 2029 9dd23746.0 1996 0a2bac92.0 1976 f5ead794.0 1919 03aa0ecb.0 1907 6fee79b0.0 1903 fe102e03.0 1900 Then again, we may need to add the size of the CERN _Root_ CA: d254cc30.0 1350 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 httpd-2.2.11-8.x86_64 mod_ssl-2.2.11-8.x86_64 openssl-0.9.8k-4.fc11.x86_64 fedora-release-11-1.noarch Might it be worth trying 1.0.0 as well? Thanks, Maarten __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org In the past we can download a file with CA certificates ( ca-bundle.crt.tar.gz ) from mod_ssl site. Now file is removed but it contain more then 90 certificates (PEM format concatenated together). I could confirm that problem is not in the number of certificates in file or hash-dir as I test regularly with various OpenSSL versions starting from 0.9.6. May be problem is in 64-bit OpenSSL (fedora?) build ? Roumen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Maarten Litmaath wrote: Hi Stephen, 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 s_server). There is a bit more information now in our ticket: https://savannah.cern.ch/bugs/?48458 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: 1e12d831.0 2594 1d879c6c.0 2204 9ff26ea4.0 2143 55994d72.0 2029 9dd23746.0 1996 0a2bac92.0 1976 f5ead794.0 1919 03aa0ecb.0 1907 6fee79b0.0 1903 fe102e03.0 1900 Then again, we may need to add the size of the CERN _Root_ CA: d254cc30.0 1350 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 httpd-2.2.11-8.x86_64 mod_ssl-2.2.11-8.x86_64 openssl-0.9.8k-4.fc11.x86_64 fedora-release-11-1.noarch Might it be worth trying 1.0.0 as well? Thanks, Maarten __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org In the past we can download a file with CA certificates ( ca-bundle.crt.tar.gz ) from mod_ssl site. Now file is removed but it contain more then 90 certificates (PEM format concatenated together). I could confirm that problem is not in the number of certificates in file or hash-dir as I test regularly with various OpenSSL versions starting from 0.9.6. May be problem is in 64-bit OpenSSL (fedora?) build ? Roumen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Hi Roumen, it hangs the same , remove a few cas and it works. # rpm -q httpd mod_ssl openssl fedora-release httpd-2.2.11-8.x86_64 mod_ssl-2.2.11-8.x86_64 openssl-0.9.8k-4.fc11.x86_64 fedora-release-11-1.noarch [...] May be problem is in 64-bit OpenSSL (fedora?) build ? We see the same problem on 32-bit architectures. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Hi, Roumen Petrov schrieb: In the past we can download a file with CA certificates ( ca-bundle.crt.tar.gz ) from mod_ssl site. Now file is removed but it contain more then 90 certificates (PEM format concatenated together). many use the Perl script I've hacked for cURL to create a ca-bundle.crt: http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl I've also hacked a WSH script for Win32 users who might not have Perl: http://www.gknw.net/vb/scripts/mk-ca-bundle.vbs and also a PHP commandline version: http://www.gknw.net/php/phpscripts/mk-ca-bundle.phps I'm fine with contributing any of these scripts to the OpenSSL project if there's any interest. Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
These scripts pull the latest version of the Mozilla-approved CAs. OpenSSL is not in the business of making CA certificates available, but having the ability to do this in the stock package might be very good for the users. (Make sure that such a tool warns the user that the CA certificates are those made available by Mozilla, not the OpenSSL team, and that there's no warranty from OpenSSL on their use or misuse, such as not checking the hashes against the official locations for each CA.) -Kyle H On Mon, Jun 15, 2009 at 4:31 PM, Guenterli...@gknw.net wrote: Hi, Roumen Petrov schrieb: In the past we can download a file with CA certificates ( ca-bundle.crt.tar.gz ) from mod_ssl site. Now file is removed but it contain more then 90 certificates (PEM format concatenated together). many use the Perl script I've hacked for cURL to create a ca-bundle.crt: http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl I've also hacked a WSH script for Win32 users who might not have Perl: http://www.gknw.net/vb/scripts/mk-ca-bundle.vbs and also a PHP commandline version: http://www.gknw.net/php/phpscripts/mk-ca-bundle.phps I'm fine with contributing any of these scripts to the OpenSSL project if there's any interest. Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
[maarten.litma...@cern.ch - Fri Jun 05 06:52:54 2009]: Dear OpenSSL developers, please have a look at the following bug about a bad interaction between mod_ssl and openssl 0.9.7, 0.9.8 and possibly higher versions when the server side supports more than 85 CAs: https://issues.apache.org/bugzilla/show_bug.cgi?id=46952 So far this has only caused problems for services whose certs were issued by the CERN CA, a standard Microsoft CA instance. The mod_ssl developer who responded thinks this might be a bug in openssl rather than mod_ssl: can you comment? This issue is steadily moving toward becoming a big nuisance for CERN and the projects it participates in, e.g. EGEE. For completeness, our problem is documented here: https://savannah.cern.ch/bugs/?48458 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 s_server). I'd suggest trying OpenSSL 0.9.8k as well though because some code changes might have an effect in that area. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
Dear OpenSSL developers, please have a look at the following bug about a bad interaction between mod_ssl and openssl 0.9.7, 0.9.8 and possibly higher versions when the server side supports more than 85 CAs: https://issues.apache.org/bugzilla/show_bug.cgi?id=46952 So far this has only caused problems for services whose certs were issued by the CERN CA, a standard Microsoft CA instance. The mod_ssl developer who responded thinks this might be a bug in openssl rather than mod_ssl: can you comment? This issue is steadily moving toward becoming a big nuisance for CERN and the projects it participates in, e.g. EGEE. For completeness, our problem is documented here: https://savannah.cern.ch/bugs/?48458 Thanks, Maarten __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
