1. 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?

Discussion in 'Server Configuration and Hosting' started by RoldanLT, Mar 11, 2014.

  1. RoldanLT

    RoldanLT Well-Known Member

    Some of my user's reported this:


    Is this a ssl/https mis-configuration?
     
  2. Sheratan

    Sheratan Well-Known Member

    I can access your site. Have you try another browser? IE, perhaps? :D
     
  3. RoldanLT

    RoldanLT Well-Known Member

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

    Sheratan Well-Known Member

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

    MattW Well-Known Member

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

    Floren Well-Known Member

    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).
     
  7. MattW

    MattW Well-Known Member

    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;
     
    Floren likes this.
  8. RoldanLT

    RoldanLT Well-Known Member

    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 :(
     
  9. MattW

    MattW Well-Known Member

    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.
     
  10. p4guru

    p4guru Well-Known Member

    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 and MattW like this.
  11. RoldanLT

    RoldanLT Well-Known Member

    My current config has:
    ssl_session_timeout 10m ;

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

    Floren Well-Known Member

    IMO, clearing the cache won't help. It is clearly a server software related issue.
     
  13. RoldanLT

    RoldanLT Well-Known Member

    So any suggestion @Floren ? Thanks!
     
  14. Floren

    Floren Well-Known Member

    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.
     
    RoldanLT likes this.
  15. RoldanLT

    RoldanLT Well-Known Member

  16. Floren

    Floren Well-Known Member

    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?
     
  17. RoldanLT

    RoldanLT Well-Known Member

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

    Floren Well-Known Member

    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.
     
    RoldanLT and p4guru like this.
  19. RoldanLT

    RoldanLT Well-Known Member

    Yes, I already remove it yesterday :)
    Thanks !
     
  20. electrogypsy

    electrogypsy Active Member

    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.
     

Share This Page