Thomas - Executed
o ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
BEEDB7A167EC486D98CFAFBDA541DDB308B27BFCF9D5732599DEDB1A3E2D45B2
Session-ID-ctx:
Master-Key:
5E7AD6C866CEAAC0AE0868858ADDE392406533185DFD5CE7BCA7E12E7FE6A5
Is your nginx system a Linux one? If so, then you can do something like
this:
`openssl s_client -connect localhost:443`
from the nginx box and see what handshake errors you're getting.
Thomas
On 11/19/20 2:03 PM, sachingp wrote:
Hi Thomas - We are using digicert, I don't have access to the
Hi Thomas - We are using digicert, I don't have access to the client logs,
what more I can do to go deeper
Sachin
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,290009,290013#msg-290013
___
nginx mailing list
nginx@nginx.org
http://mailman
Provide SSL logs from the client side - if you can, using OpenSSL and
its `s_connect` framework or similar to get the actual SSL handshake
errors/logs. Chances are something's wrong with the handshake or your
cert. (since I can't scan your infra directly yourself, you'll have t
}
We see a lot of SSL handshake errors
2020/11/19 18:28:08 [info] 5784#0: *5771518 peer closed connection in SSL
handshake while SSL handshaking, client: 169.53.151.196, server:
0.0.0.0:443
2020/11/19 18:28:08 [info] 5786#0: *5771519 peer closed connection in SSL
handshake while SSL han
}
We see a lot of SSL handshake errors
2020/11/19 18:28:08 [info] 5784#0: *5771518 peer closed connection in SSL
handshake while SSL handshaking, client: 169.53.151.196, server:
0.0.0.0:443
2020/11/19 18:28:08 [info] 5786#0: *5771519 peer closed connection in SSL
handshake while SSL han
Hi Josh,
There are bugs in OpenSSL 1.0.1e that could trigger this which is why I
asked. The two other things I would suggest trying are:
1. Look again at your cipher list, missing important ones out can
trigger this error, especially with ssl_prefer_server_ciphers set.
Judging by the quick s
Hi Andrew,
To clarify the setup earlier,
I continued to use the Ubuntu compiled version of NGINX from apt-get.
The specific procedure I used to change the lib that NGINX would load
was by replacing the libssl.so.1.0.0 and libcrypto.so.1.0.0 files in the
path referenced by ldd for the NGINX bi
Hi Josh,
When you installed the newer OpenSSL did you recompile NGINX to use the
newer version? If not then it may still have been using the older
OpenSSL with this bug in it. It is likely to be pinned to a specific
version. You can check by running "ldd" on your NGINX binary.
Kind Regards
A
Recently I tried setting up a basic nginx reverse proxy in production on
Ubuntu 14.04 using their default supported version of nginx 1.4.6.
Basic config as follows:
server {
listen 127.0.0.1:443;
server_name myhost.ca;
ssl on;
ssl_certificate /etc/nginx/certs/cert.chained.with
I am facing the same problem. I had one ssl certificate setup for the
following domains:
firstdomain.com
*.firstdomain.com
a.firstdomain.com
b.firstdomain.com
a.seconddomain.com
b.seconddomain.com
When i read that it could be due to multiple different domains using the
same ssl certificate, i rem
do want to add the cert I was using was subdomain wildcard and the blocks
where for different subdomains so that should not have been a problem with
the cert.. maybe its an access issue to the cert? (nginx can't access it
multiple times at the same moment or something)
Posted at Nginx Forum:
http
Yeah I removed the double blocks and it solved the problem...
The 'possible bug' though is that the problem seems completely random..
instead of giving error all the time sometimes it works and sometimes it
doesn't... Just refreshing the site a few times and it worked..
So it looks like Nginx just
I am facing the same issue on my Debian 7 Server. I downgraded to
1.0.1e-2+deb7u12 version of libssl1.0.0 and restarted nginx but the issue is
still occurring for me. I can still see the same logs.
I also tried following these instructions(installed the deb packages made by
these instructions) but
Hello!
On Tue, Jul 14, 2015 at 09:58:52PM -0400, tempspace wrote:
> Here's what we've learned so far:
>
> The issue is related to a new security feature that blocks TLS Fallback,
> which is a client that connects with one version of TLS, then tries to
> downgrade the connection and connect with
Here's what we've learned so far:
The issue is related to a new security feature that blocks TLS Fallback,
which is a client that connects with one version of TLS, then tries to
downgrade the connection and connect with a lower TLS version.. It was a
feature made in light of the Poodle SSL vulnera
Out of thin air, I suspect it is a certificate problem.
You seem to have configured *the same* certificate (and private key) for
those 2 domains. Since certificates are generally tied to a single domain,
that could explain errors.
Another idea: have you checked nginx has been built with SNI suppor
I found myself with the same problem and found the cause (and obvious
solution).
On my nginx server I run various website and they all have their own server
{} config block in separate files under 'sites-available' folder.
Some sites are on different IP's and some are on the same IP.
Now the caus
First off, thanks to all who contributed to this thread. I must admit I did
not understand much of it, however as someone plagued by this bug (we have a
bunch of cherrypy REST servers talking to iOS and Android clients and have
seen a lot of those fallback errors), I must admit I'm a bit of a loss
Just an update: as of today, even Debian provides
libssl1.0.0:1.0.1e-2+deb7u16 which still generates these error logs, so it
looks like the only way is still to fallback to
libssl1.0.0:1.0.1e-2+deb7u12.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,256373,258186#msg-258186
___
That surely helps. So as of now the only way to resolve the issue is going
back to u12 version of libssl?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,256373,257705#msg-257705
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/
Hello!
On Sat, Mar 21, 2015 at 11:59:17AM -0400, tempspace wrote:
> I should specify that I agree with what is happening. We have clients that
> are falling back under normal conditions, and the latest libssl that
> implemented fallback prevention for TLS is stopping. I have downgraded our
> lib
I should specify that I agree with what is happening. We have clients that
are falling back under normal conditions, and the latest libssl that
implemented fallback prevention for TLS is stopping. I have downgraded our
libssl and I'm looking in my logs, and I see plenty of iOS 8 devices that
auto-
Maxim,
I have been playing with the ciphers as well, and it doesn't appear to be
cipher related. It happens for every cipher I've tried. I tried with turning
off the prefer on the server, and it uses the same cipher with the prefer
on. I then turned prefer server ciphers back on, and tailed our acc
Hello!
On Fri, Mar 20, 2015 at 02:15:42PM -0400, tempspace wrote:
> I had to start looking at this issue again now that yet another openssl
> security issue. Now that I know I can go back to a working setup just by
> downgrading SSL, I am able to gather more information.
>
> This morning, I upda
I had to start looking at this issue again now that yet another openssl
security issue. Now that I know I can go back to a working setup just by
downgrading SSL, I am able to gather more information.
This morning, I updated the libssl libraries and restarted nginx, and the
errors started flooding
I am seeing similar error as well. It is showing up for lot of people and am
not sure why it is happening and if actually the clients facing the error
are actually able to browse through the website or not. Can someone please
help me understanding that is it safe to downgrade to the earlier version
> We've been unable to reproduce it with any one browser or IP address. It
> really is very intermittent. Fortunately, I believe we've gotten to the
> bottom of this. It looks like our data center switched us over to anti-DDoS
> route. This means all of our traffic has been passing through hardware
We've been unable to reproduce it with any one browser or IP address. It
really is very intermittent. Fortunately, I believe we've gotten to the
bottom of this. It looks like our data center switched us over to anti-DDoS
route. This means all of our traffic has been passing through hardware that
pe
You are absolutely correct, but I figured you would want a working
environment while we work with nginx/openssl on figuring out how to fix this
bug. Knowing that it worked for you also increases my own comfort that the
issue is mitigated on my side and I won't have performance issues at my next
pea
The errors went away, and now the only errors I see in our logs relating to
SSL are handshake timeouts when I turn debug logs on.
Now that I think about it, though, isn't this to be expected? The errors
immediately went away as soon as I downgraded far enough back to a version
of OpenSSL that didn
> I just finished running an experiment that has shed some light on the issue.
> It has not yet been solved though.
>
> I setup another nginx server with the same configuration with an upstream
> app that always responds with HTTP 200. I included JS on each page load in
> production to make a singl
Eric,
Did you try to downgrade your libssl to the previous version I mentioned
earlier? Would love to hear if your issues go away.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,256373,256428#msg-256428
___
nginx mailing list
nginx@nginx.org
I just finished running an experiment that has shed some light on the issue.
It has not yet been solved though.
I setup another nginx server with the same configuration with an upstream
app that always responds with HTTP 200. I included JS on each page load in
production to make a single request t
My first question is do these
I have been fighting a similar issue with SSL handshake issues for the past
few days. After reboots and upgrades for GHOST, we started seeing errors
like this in our error logs constantly:
*579 SSL_do_handshake() failed (SSL: error:140A1175:SSL
routines:SSL_BYTES_TO_
Prior to this issue starting, we had not changed our ciphers in several
months. I have tried changing them once since. We have also tried restarting
nginx several times on each server to clear the cache, but it has not
helped.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,256373,256406
Hi
Le 31 janv. 2015 20:02, "Richard Stanway" a
écrit :
>>
>> ...
>> 2015/01/13 12:22:59 [crit] 11871#0: *140260577 SSL_do_handshake()
>> failed (SSL: error:1408A0D7:SSL
>> routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL
>> handshaking, client: *.*.*.*, server: 0.0.0.0:443
>>
>
>
>
> ...
> 2015/01/13 12:22:59 [crit] 11871#0: *140260577 SSL_do_handshake()
> failed (SSL: error:1408A0D7:SSL
> routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL
> handshaking, client: *.*.*.*, server: 0.0.0.0:443
>
>
According to the openssl code, this occurs when a client attempts
Hi,
We are using round-robin DNS to distribute requests to three servers
all running identically configured nginx. Connections then go upstream
to HAProxy and then to our Rails app.
About two weeks ago, users began to experience intermittent SSL
handshake errors. Users reported that these
39 matches
Mail list logo
