https://issues.apache.org/bugzilla/show_bug.cgi?id=56192
Bug ID: 56192
Summary: SSLUseStapling does not work if default host has it
disabled
Product: Apache httpd-2
Version: 2.4.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_ssl
Assignee: [email protected]
Reporter: [email protected]
using "SSLUseStapling On" on a SNI vhost does not work if the first ssl-enabled
vhost has "SSLUseStapling Off" for example if the first one has a self-signed
certificate
you can verify that behavior with https://www.ssllabs.com/ssltest/
Protocol Details -> OCSP stapling: No
verified with the developer of the ssl-test where i first reported a SNI
problem of the test
-------- Original-Nachricht --------
Betreff: Re: [ssllabs-discuss] incorrect SNI usage
Datum: Tue, 04 Feb 2014 21:29:30 +0000
Von: Ivan Ristic <[email protected]>
An: [email protected]
On 04/02/2014 18:21, Reindl Harald wrote:
> hi
>
> i just realized "OCSP stapling No" one one of our servers
> well, the reason is "SSLUseStapling Off" on the default
> host which is more or less a honeypot
>
> the vhost which was checkd has this value enabled
> after enable it on the default host -> Yes
>
> both a working fine even with MSIE6 because they use
> the same wildcard-certificate and are in the same domain
My OCSP stapling checks do use SNI, but it's possible that the SNI
information does not match the virtual host.
If you can, please disable OCSP stapling in the default server and send
me the hostname; I will check it
______________________________________
$ openssl s_client -connect secure.thelounge.net:443 -status -servername
secure.thelounge.net | grep OCSP
OCSP response: no response sent
I've heard of an Nginx bug that requires OCSP Stapling to be enabled in
the main server and not in a virtual host, but maybe Apache has the same
problem?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
