Bug #2291
closedSNI doesn't actually work, returns a random certificate
Description
Following the directions on <http://redmine.lighttpd.net/wiki/1/Docs:SSL>, I added this to my SSL configuration.
$SERVER["socket"] == "0.0.0.0:8443" {
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/server.pem"
$HTTP["host"] == "glyph.im" {
ssl.pemfile = "/etc/lighttpd/glyph.im.pem"
ssl.ca-file = "/etc/lighttpd/gandi.pem"
}
$HTTP["host"] == "ying.li" {
ssl.pemfile = "/etc/lighttpd/ying.li.pem"
ssl.ca-file = "/etc/lighttpd/gandi.pem"
}
}
It appeared to work at first, but then some people started reporting problems. So I looked at the output of:
openssl s_client -servername glyph.im -connect glyph.im:8443
and
openssl s_client -servername ying.li -connect glyph.im:8443
and noticed that it seemed to be randomly returning a certificate; sometimes preferring one or the other for a while, but inevitably flipping randomly between the two.
This is lighttpd/1.4.26 as packaged on on Ubuntu 10.04.1.
Updated by glyph almost 14 years ago
I've left the server running on 8443 in case anyone would like to look at it, although I'm going to go for another solution to my SNI problems on 443.
Updated by nitrox almost 14 years ago
- Status changed from New to Need Feedback
Please see #2125 and test openssl first.
Also there have been fixes at 1.4.27 to address minor issues, so you want to upgrade that one too, but first concentrate on openssl.
Updated by glyph almost 14 years ago
I just configured nginx on the same machine with the same openssl, and it works reliably (as far as I've been able to tell, at least; it's running on 443).
Also, I'm using OpenSSL 0.9.8k, as shown here:
# dpkg -l openssl Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii openssl 0.9.8k-7ubuntu Secure Socket Layer (SSL) binary and related
Updated by nitrox almost 14 years ago
- Status changed from Need Feedback to Missing Feedback
Ok, so you solved it that way. I´ll close this with "Missing Feedback".
Updated by glyph almost 14 years ago
- Status changed from Missing Feedback to Reopened
Is there a PPA of more recent lighttpd packages that I could install on my Ubuntu installation, to test this? The bug is definitely real, and is not a result of the OpenSSL issue you're talking about.
Updated by glyph almost 14 years ago
None of the changes in 1.4.27 look like they fix this; is there one in particular I might look at? Is this issue a duplicate?
Updated by nitrox almost 14 years ago
http://packages.ubuntu.com/source/lighttpd
Please also try on :443.
Updated by glyph almost 14 years ago
Looks like .28 is only packaged in Natty, and all others are .26?
I tried first on :443. I only moved it to 8443 so that observers of this bug could see the behavior; I want 443 to actually work on my server :).
Updated by jae almost 14 years ago
glyph wrote:
Looks like .28 is only packaged in Natty, and all others are .26?
Using 1.4.28, Debian package, bug still there. I did use a patch from #2125 (I think) and it seemed to fix it. Why it's back (or seems to be), I have no idea.
Updated by peacememories almost 13 years ago
I'm a bit disappointed that there seems to be neither progress with nor interest in this bug. I'm still using 1.4.26 (bug can of course be observed there).
Unfortunately this bug can't be easily worked around (multiple IP addresses, etc) since *NIC doesn't acknowledge the need for multiple SSL certificates as reason for additional addresses anymore (with SNI being supported by almost all major browsers and servers).
I know nginx and apache both have stable SNI implementations, but I would really like to see it in lighttpd, because apart from that flaw it is vastly superior to the other two in my use case.
Updated by stbuehler almost 13 years ago
- Status changed from Reopened to Duplicate
There you go, "fixed".
Also available in: Atom