We don't support GOST. If nginx is responding with GOST on our ClientHello then that's a server bug.

Could you provide a net-internals dump with byte logging, per these instructions? Alternatively, is there a publicly accessible URL we can try? Thanks!
https://dev.chromium.org/for-testers/providing-network-details

mironnik@, could you provide the info requested in comment #1?

Unfortunately there is no publicly accessible URL.
Dump attached.
Why it works on other platforms?

Deleted: chrome-net-export-log.json 55.4 KB

chrome-net-export-log.json 55.4 KB View Download

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Have you tested the website against Safari? We're getting SSL_SERVER_CERT_BAD_FORMAT, which means that the certificate is invalid when trying to convert it to the OS-specific form, so this is either an issue with the OS certificate implementation or in how we transform it.

Can you provide a byte-level capture (in a fresh session) that includes the certificate? 

svaldez: On Mac it means the new x509_certificate_bytes.cc code doesn't like it. That's using the new parser. +mattm.

But yeah, we'll want a byte-level capture to show the certificate.

Oh, instead of a byte-level capture which tends to log a lot of things, could you capture a log from Chrome Canary? That includes slightly better logging for this case? Thanks!

https://www.google.com/chrome/browser/canary.html

Sounds like  issue 715969 , however based on the version numbers I don't think it can be (the log is from Chrome 58, whereas 715969 affects M59).

Oh! I totally missed that. Ignore everything I said. :-)

Dump attached from Chrome Canary.
Safari and FireFox work correctly. 

Deleted: chrome-net-export-log-canary.json 118 KB

chrome-net-export-log-canary.json 118 KB View Download

dump with raw bytes

Deleted: chrome-net-export-log-canary-raw.json 163 KB

chrome-net-export-log-canary-raw.json 163 KB View Download

Thanks! The issue is that your server is sending GOST certificates when it shouldn't. Specifically, it's sending:

1. leaf certificate, RSA
2. intermediate certificate, GOST
3. intermediate certificate, GOST, signer of (3)
4. intermediate certificate, RSA, signer of (1)
5. intermediate certificate, RSA, signer of (4)

(1), (4), and (5) are correct. You should not be sending (2) and (3) when using RSA. I'm guessing the browsers where it does work are just ignoring certificates that fail to parse. In addition to causing problems here, this is a waste of bandwidth at the start of the handshake. Those GOST certs are pretty bug.

Are you using OpenSSL 1.0.1? OpenSSL 1.0.1 has a limitation where it can't send different chains for different leaves. Glancing at the nginx code, it would indeed take all the chains and concatenate them. If you update to OpenSSL 1.0.2, this should fix it. Alternatively, don't configure the GOST certificates.

Ultimately, the server is at fault here, so it probably should be a WontFix. But I dunno how we behave on all platforms and whether cert folks want to tweak things.

I suspect what's going on is that SecCertificateRef parses out either the key or signature algorithm (or both) and so refuses to parse certs (2) and (3). Based on how Canary behaves, x509_certificate_bytes.cc is fine with this. In Canary, we don't fail until I presume here:
https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc_mac.cc?rcl=2fa356c2cb48d3383024a166cad38db369b99312&l=742

If it works in Safari, I'm guessing they're just silently dropping unparseable intermediates. On other platforms, it would also depend on whether they eagerly parse the key or signature algorithm.

It works in Safari and Firefox on Mac. Also it works in Chrome on Linux and Windows.

Update to OpenSSL 1.0.2 did not help.

What is your nginx config?

SSL section:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers GOST2001-GOST89-GOST89:kEECDH+AESGCM+AES128:kEECDH+AESGCM+AES256:kEECDH+AES128:kEECDH+AES256:kRSA+AESGCM+AES128:kRSA+AES128:kRSA+AES256:!kRSA+3DES:!RC4:!aNULL:
!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!DSS:!EXP:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DES:!SSLv2;
ssl_dhparam /etc/nginx/conf.d/ssl/dhparams.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/conf.d/ssl/gd_bundle-g2.crt;
resolver 8.8.8.8 8.8.4.4;
ssl_buffer_size 8k;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
add_header Strict-Transport-Security 'max-age=15552000';
ssl_certificate /etc/nginx/conf.d/ssl/GOST_bundle.crt;
ssl_certificate_key /etc/nginx/conf.d/ssl/GOST_bundle.crt;
ssl_certificate /etc/nginx/conf.d/ssl/RSA.crt;
ssl_certificate_key /etc/nginx/conf.d/ssl/RSA.key;
ssl_prefer_server_ciphers on;

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate

I rebuilded nginx again and... BINGO! It works.

Oh, yes, you also need nginx to be aware that you have OpenSSL 1.0.2 so it uses the new APIs.

Certificate folks: shall we close this or do you think it is worth tweaking things to do whatever Safari is doing? I'm guessing they're silently dropping unparsable intermediates.

re Comment 17: That's a good question. I'm inclined to think we should skip them, as long as we parse the server certificate, even if it arguably that can cause ecosystem issues (Postel's Law strikes again)... 

My personal inclination is that skipping if it's total garbage would be unfortunate, but skipping if we just don't recognize the SPKI or signature OID is probably sensible, given we path-build and freely ignore server-sent certificates anyway. Given we don't have this behavior on other platforms, that's probably what they're doing. macOS is probably just weird in eagerly parsing the key.

Conveniently, we get this behavior for free now by just doing the parse => skip logic in cert_verify_proc_mac.cc because net::X509Certificate is now using x509_certificate_bytes.cc.

re #19: May be more clear to say we *could* get the behavior for free. (Currently the code still does fail immediately if any of the intermediates couldn't be converted to a SecCertificate.)

I did a few other tests. Android and NSS will ignore GOST intermediates already.

Android does hard-fail if any of the intermediates are badly malformed, yet passed X509CertificateBytes parsing. (note to self: looks like the conversion is in
net/android/java/src/org/chromium/net/X509Util.java)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b

commit dcb4fce5ed55d1a7079277ec25e9d896d63ac48b
Author: Matt Mueller <mattm@chromium.org>
Date: Thu Sep 07 21:27:43 2017

Ignore invalid server supplied intermediates during certificate verification.

Bug:  713147 
Change-Id: Iecfb8802717e749f4be673914d87bd3049c40e57
Reviewed-on: https://chromium-review.googlesource.com/651138
Commit-Queue: Matt Mueller <mattm@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#500388}
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/android/java/src/org/chromium/net/X509Util.java
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/cert_verify_proc_ios.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/cert_verify_proc_mac.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/cert_verify_proc_nss.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/cert_verify_proc_unittest.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/cert_verify_proc_win.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/x509_util_ios_and_mac.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/x509_util_ios_and_mac.h
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/x509_util_ios_and_mac_unittest.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/x509_util_nss.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/x509_util_nss.h
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/x509_util_nss_unittest.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/x509_util_win.cc
[modify] https://crrev.com/dcb4fce5ed55d1a7079277ec25e9d896d63ac48b/net/cert/x509_util_win.h