Hi again.
The following is my own opinion, and does not reflect an upstream
consensus.
On Thu, 14 Nov 2013 18:40:30 +0100
Roland Koebler r.koeb...@yahoo.de wrote:
Hi,
This is a loop.
yes and no: It's not exactly a loop, since the two certificates belong
to certificate-chains of two
Package: lighttpd
Version: 1.4.31-4+deb7u1
Severity: important
The last security update completely broke SSL/SNI.
Before the update, SSL and SNI worked fine, but after the update, no more
SSL-connections are possible! Trying to connect to the lighttpd with SSL
results in timeouts (Firefox
Hi,
I think this may be related to 729480, but I could be wrong (shouldn't
have merged so quickly, sorry).
On Thu, 14 Nov 2013 10:00:25 +0100
r.koeb...@yahoo.de wrote:
The last security update completely broke SSL/SNI.
Before the update, SSL and SNI worked fine, but after the update, no
more
Hi,
I think this may be related to 729480, but I could be wrong (shouldn't
have merged so quickly, sorry).
I don't know if it's related. It's certainly not the same, since I don't
use client certificates at all.
I usually test my patches at least in the area they are made for. So
SSL (and
Hi,
On Thu, 14 Nov 2013 12:48:04 +0100
Roland Koebler r.koeb...@yahoo.de wrote:
Hmm, here it *is* completely broken. I've attached a minimized
config-file. If the $HTTP-section or the ssl.ca-file-line is
removed, I can connect to lighttpd with SSL again; but if they are
there, no
Hi,
As only new openssl versions have X509_STORE and the api still looks
incomplete / broken, the ssl.ca-file certificates need to be preloaded
into all SSL_CTX (previously we had a SSL_CTX for each SNI host, but
that didn't work well - that was the basic problem behind the security
bug); if
Am Donnerstag, 14. November 2013, 14:05:14 schrieb Roland Koebler:
Hi,
I have packages with an updated patch from upstream for a
different
ssl related regression (#729480). Unfortunately, I am at the
moment
short of time to test it. If you could check if these packages fix
your
Hi,
On Thu, 14 Nov 2013 14:41:32 +0100
Roland Koebler r.koeb...@yahoo.de wrote:
My guess is that the two private CAs you configured have a name
(Issuer/Subject) conflict; in that case openssl probably can't
figure out which one to use.
that sounds reasonable, since I now figured out that
Hi,
This is a loop.
yes and no: It's not exactly a loop, since the two certificates belong
to certificate-chains of two different certificates, in this case:
Cert1 signed by PositiveSSL CA 2
PositiveSSL CA 2signed by AddTrust External CA Root
AddTrust
9 matches
Mail list logo