How can I fix this problem?

[rdn]

Some of my user's reported this:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

Is this a ssl/https mis-configuration?

 

[Sheratan]

I can access your site. Have you try another browser? IE, perhaps?

 

[rdn]

I can access your site. Have you try another browser? IE, perhaps?

It's fine with me also, some of my user's reported the problem.
They capture that video also.

 

[Sheratan]

Maybe they are under some kind of VPN, or proxy? Or they have some program that running in 443 or 8080 port?

 

[MattW]

Can they ping your site? What are the results of a traceroute from their PC?

 

[Floren]

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]

https://code.google.com/p/chromium/issues/detail?id=288992

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

  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;

 

[rdn]

So this a SPDY issue?
So how can I fix it?
What adjustment is required on spdy?
I'm confused with the code you gave

 

[MattW]

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]

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 ?

 

[rdn]

My current config has:
ssl_session_timeout 10m ;

They already tried to clear their browser cache but the problem still occur again.

 

[Floren]

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.

 

[rdn]

So any suggestion @Floren ? Thanks!

 

[Floren]

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.

 

[rdn]

By the way, here's my domain config: http://pastebin.com/QxWjD3g8
Maybe something wrong with my config ?

 

[Floren]

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?

 

[rdn]

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?

This: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling_responder

 

[Floren]

It does not mean you have to use it. If you created your own OCSP certificate, you don't need the responder as the client browser will take care of that.

 

[rdn]

Yes, I already remove it yesterday
Thanks !

 

[electrogypsy]

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.