• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

How can I fix this problem?

Floren

Well-known member
#6
Is this a ssl/https mis-configuration?
I experienced this on a client site. Once I installed my own OpenSSL packages into server, all issues were gone. Honestly, I'm not sure if it was just related to SSL, as I did a server revamp and installed all Axivo rpm's (PHP, MariaDB, Nginx, OpenSSL).
 

MattW

Well-known member
#7
https://code.google.com/p/chromium/issues/detail?id=288992

http://src.chromium.org/svn/trunk/src/net/socket/ssl_client_socket_pool.cc

Code:
  SSLClientSocket::NextProtoStatus status =
      SSLClientSocket::kNextProtoUnsupported;
  std::string proto;
  std::string server_protos;
  // GetNextProto will fail and and trigger a NOTREACHED if we pass in a socket
  // that hasn't had SSL_ImportFD called on it. If we get a certificate error
  // here, then we know that we called SSL_ImportFD.
  if (result == OK || IsCertificateError(result))
    status = ssl_socket_->GetNextProto(&proto, &server_protos);

  // If we want spdy over npn, make sure it succeeded.
  if (status == SSLClientSocket::kNextProtoNegotiated) {
    ssl_socket_->set_was_npn_negotiated(true);
    NextProto protocol_negotiated =
        SSLClientSocket::NextProtoFromString(proto);
    ssl_socket_->set_protocol_negotiated(protocol_negotiated);
    // If we negotiated a SPDY version, it must have been present in
    // SSLConfig::next_protos.
    // TODO(mbelshe): Verify this.
    if (protocol_negotiated >= kProtoSPDYMinimumVersion &&
        protocol_negotiated <= kProtoSPDYMaximumVersion) {
      ssl_socket_->set_was_spdy_negotiated(true);
    }
  }
  if (params_->want_spdy_over_npn() && !ssl_socket_->was_spdy_negotiated())
    return ERR_NPN_NEGOTIATION_FAILED;
 

MattW

Well-known member
#9
That code is from the google trunk for Chrome, so it's showing roughly why the error is being presented to the end user. No idea why it's happening though.
 

p4guru

Well-known member
#10
Try getting end users to clear their browser caches and see if it happens again. Matt nice work finding that code, looks like the error occurs when the web server - Nginx announces to end user's browser that this server supports SPDY but for some reason the SSL handshake doesn't actually support SPDY.

How long have you set the ssl_session_timeout for ?
 

Floren

Well-known member
#12
Try getting end users to clear their browser caches and see if it happens again. Matt nice work finding that code, looks like the error occurs when the web server - Nginx announces to end user's browser that this server supports SPDY but for some reason the SSL handshake doesn't actually support SPDY.
IMO, clearing the cache won't help. It is clearly a server software related issue.
 

Floren

Well-known member
#14
I would start by verifying the OpenSSL, Nginx and PHP compilation, as from your posts you use sources not rpms. You have to understand that using bleeding edge software like you do require bleeding edge related dependencies. For example, I have several additional patches applied to OpenSSL compared to official repositories and also a ton of compile settings changed. Recently, I had to create a new Postfix 2.11.0 package because the current 2.6.6 version available in official repo, beside being EOL'ed in February 2013, was incompatible with my OpenSSL release.
 

Floren

Well-known member
#16
IMO, is not related to your certificate or Nginx settings. My client used a Starfield SSL certificate, the same I have installed on my site. Users on his site reported same problems you have and once I upgraded his servers with Axivo rpm's, all issues were gone.

Just curious, why do you use a specific ssl_stapling_responder URL?
 

RoldanLT

Well-known member
#17
#20
I don't know if this is relevant, but i was having the same "ERR_NPN_NEGOTIATION_FAILED" in chrome, and i came across this page:

https://code.google.com/p/chromium/issues/detail?id=288992 (same one @MattW listed above)

which relates to CDNs i guess, and then i remembered i forgot to remove "if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) { $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP']; }" from my config.php file (as discussed here: https://support.cloudflare.com/hc/e...o-I-restore-original-visitor-IP-with-XenForo-) . i was using cloudflare before switching to centimod.

i'm a total noob, so i don't know if this is the issue, but after removing it and clearing the cache, chrome seems to be loading my website fine now.