Certificate error with missing intermediate certs on Sierra |
|||||||||||||||||||
Issue descriptionVersion: 55.0.2855.0 OS: macOS 10.12 Sierra GM What steps will reproduce the problem? (1) Visit an HTTPS website with a missing intermediate cert. What is the expected output? Success. What do you see instead? “Your connection is not private” page. This was first observed at https://www.fluentcity.com/, and I attached screenshots of the certificate view from 10.12 (bad) and 10.11 (good). SSL Labs gives this site an “A”, with only an inline “Extra download” message about the missing intermediate.
,
Sep 9 2016
Also note: Such sites won't work on Android or within Firefox due to the missing intermediate.
,
Sep 9 2016
1) Attached. 2) The website loads with no warnings, and the full chain is shown (it looks exactly like the "good" screenshot in the bug) 3) I have one, but I'm in NYC. You're welcome to ping me to test things, or I can look for someone in MTV who can provide one. Comment #2: Noted.
,
Sep 9 2016
Actually, Firefox seems to be fine (on 10.11 and 10.12).
,
Sep 9 2016
Firefox being fine depends on what other sites you visited/loaded since startup :) Matt, would you be able to work with sdy@ to hack together a CL with extended logging in cert_verify_proc_mac to see if we're unnecessarily trimming certs? That'd be the low-hanging bar. The harder bar is I suspect we can no longer debug Safari on 10.12 to see what it's calling SecTrustEvaluate with, to see if they're explicitly forcing on AIA checks (I'd be surprised).
,
Sep 9 2016
I think 10.12 debugging is possible if you disable system integrity protection.
,
Sep 9 2016
> Firefox being fine depends on what other sites you visited/loaded since startup :) Maybe — it works even if I relaunch Firefox with just that one tab loading at startup. Re. debugging, we can even do a screen share over Hangouts, or I might be able to set up Chrome Remote Desktop access if that would help.
,
Sep 10 2016
Made a quick logging hack cl here: https://codereview.chromium.org/2323283005/ Output on 10.11 looks like: [0909/171138:INFO:cert_verify_proc_mac.cc(555)] CertVerifyProcMac::VerifyInternal starting for www.fluentcity.com [0909/171138:INFO:cert_verify_proc_mac.cc(631)] Trying chain of 2 certs: [0909/171138:INFO:cert_verify_proc_mac.cc(523)] *.fluentcity.com [0909/171138:INFO:cert_verify_proc_mac.cc(523)] COMODO RSA Domain Validation Secure Server CA [0909/171138:INFO:cert_verify_proc_mac.cc(636)] rv = 0 [0909/171138:INFO:cert_verify_proc_mac.cc(656)] verified chain: [0909/171138:INFO:cert_verify_proc_mac.cc(523)] *.fluentcity.com [0909/171138:INFO:cert_verify_proc_mac.cc(523)] COMODO RSA Domain Validation Secure Server CA [0909/171138:INFO:cert_verify_proc_mac.cc(523)] COMODO RSA Certification Authority [0909/171138:INFO:cert_verify_proc_mac.cc(523)] AddTrust External CA Root [0909/171138:INFO:cert_verify_proc_mac.cc(659)] untrusted = 0 weak_chain = 0 [0909/171138:INFO:cert_verify_proc_mac.cc(687)] found a trusted, non-weak chain
,
Sep 10 2016
You can test it without rebuilding the whole browser by patching that CL into a client and running: ninja -C out/default cert_verify_tool && ./out/default/cert_verify_tool ~/fluentcity.chain.pem --hostname=www.fluentcity.com (fluentcity.chain.pem is the certs copied out of the netlog posted above. I'll attach it here for convenience.)
,
Sep 11 2016
Thanks for waiting! Here's the output from 10.12: [0910/232532:INFO:cert_verify_proc_mac.cc(556)] CertVerifyProcMac::VerifyInternal starting for www.fluentcity.com [0910/232532:INFO:cert_verify_proc_mac.cc(632)] Trying chain of 2 certs: [0910/232532:INFO:cert_verify_proc_mac.cc(524)] *.fluentcity.com [0910/232532:INFO:cert_verify_proc_mac.cc(524)] COMODO RSA Domain Validation Secure Server CA [0910/232532:INFO:cert_verify_proc_mac.cc(637)] rv = 0 [0910/232532:INFO:cert_verify_proc_mac.cc(657)] verified chain: [0910/232532:INFO:cert_verify_proc_mac.cc(524)] *.fluentcity.com [0910/232532:INFO:cert_verify_proc_mac.cc(524)] COMODO RSA Domain Validation Secure Server CA [0910/232532:INFO:cert_verify_proc_mac.cc(660)] untrusted = 1 weak_chain = 0 [0910/232532:INFO:cert_verify_proc_mac.cc(632)] Trying chain of 1 certs: [0910/232532:INFO:cert_verify_proc_mac.cc(524)] *.fluentcity.com [0910/232532:INFO:cert_verify_proc_mac.cc(637)] rv = 0 [0910/232532:INFO:cert_verify_proc_mac.cc(657)] verified chain: [0910/232532:INFO:cert_verify_proc_mac.cc(524)] *.fluentcity.com [0910/232532:INFO:cert_verify_proc_mac.cc(660)] untrusted = 1 weak_chain = 0
,
Sep 22 2016
Did some testing on Sierra. If I remove the x509_util::CreateRevocationPolicies call or make the "tp_crl_options.CrlFlags = CSSM_TP_ACTION_FETCH_CRL_FROM_NET" line unconditional, AIA fetching appears to work again.
,
Sep 22 2016
Ugh. Thanks for investigating Matt. I wonder if they renamed that flag in 10.12 to go with repurposing it. That at least explains why Safari doesn't hit this path (nor Security Tool) - because they don't touch this particular structure. That also makes sense, in that AIA fetches in securityd go through the "CRL or cert" fetch path, and perhaps they consolidated on that flag. Option 1) We could stop setting that flag on all OS X platforms, which may cause a performance regression (due to CRL fetches for EV certs), but should otherwise avoid any issues Option 2) We could stop setting that flag only for OS X 10.12 While I have a slight preference for Option 2, in terms of "being surgical", I'm curious if you have any thoughts or feelings on Option 1.
,
Sep 22 2016
Option 2 seems reasonable to me. I can work on a CL for that. Pros I thought of for option 1: * If the Mac update rate was high enough, special casing older versions might not be worthwhile. But historically the rate doesn't appear to be quite that high. * Getting wider testing of any effects of setting the flag.. but since the behavior varies between OS versions, that isn't necessarily helpful anyway.
,
Sep 22 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/97a93ce4d2bbf3808e16c612c1ece99f1c3406ef commit 97a93ce4d2bbf3808e16c612c1ece99f1c3406ef Author: mattm <mattm@chromium.org> Date: Thu Sep 22 22:38:22 2016 Hack for AIA fetching on Mac Sierra: On >=10.12, always do FETCH_CRL_FROM_NET if adding a crl policy. BUG= 645629 Review-Url: https://codereview.chromium.org/2368453002 Cr-Commit-Position: refs/heads/master@{#420482} [modify] https://crrev.com/97a93ce4d2bbf3808e16c612c1ece99f1c3406ef/net/cert/x509_util_mac.cc
,
Sep 23 2016
Verified on Canary 55.0.2869.0 on Sierra. Note that the site in the initial report has updated to serve the full chain, so it can no longer be used to test the problem. I used https://incomplete-chain.badssl.com/ instead. Will request merge once it has a little more time to bake.
,
Sep 26 2016
I confirm this issue is fixed in Canary, thanks Ryan for pointing me to this ticket. I had the same issue with https://crt.sh/ I upgraded to Sierra, and 53.0.2785.116 returned NET::ERR_CERT_AUTHORITY_INVALID With 55.0.2872.0 canary it works correctly. Canary also fixes another interesting issue that I assume it may be connected with this issue (but not sure how): - Go to http://www.fastweb.it/ - Click on "Area Clienti" > "Famiglia" - You are sent to "http://fastweb.it/obrar.cgi?..." and Chrome returns you a "ERR_CONNECTION_RESET" error and can't load the page. In canary, instead, I am correctly able to access the page. I originally thought it was a resolution issue, but fastweb.it resolves fine. I just wanted to mention it in case you want to investigate also this second issue.
,
Sep 26 2016
This fix appears to need a merge to latest stable. I can reproduce this failure on 53.0.2785.116 on 10.12.1. Reopening and -> mattm@
,
Sep 26 2016
Requesting merges. CL has been on canary since Friday, haven't seen any issues.
,
Sep 26 2016
[Automated comment] Request affecting a post-stable build (M53), manual review required.
,
Sep 26 2016
Your change meets the bar and is auto-approved for M54 (branch: 2840)
,
Sep 26 2016
[Automated comment] Request affecting a post-stable build (M53), manual review required.
,
Sep 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/229aed5b182860fad333aa574bf49e6434702b89 commit 229aed5b182860fad333aa574bf49e6434702b89 Author: Matt Mueller <mattm@chromium.org> Date: Mon Sep 26 20:41:56 2016 Hack for AIA fetching on Mac Sierra: On >=10.12, always do FETCH_CRL_FROM_NET if adding a crl policy. BUG= 645629 Review-Url: https://codereview.chromium.org/2368453002 Cr-Commit-Position: refs/heads/master@{#420482} (cherry picked from commit 97a93ce4d2bbf3808e16c612c1ece99f1c3406ef) Review URL: https://codereview.chromium.org/2370983002 . Cr-Commit-Position: refs/branch-heads/2840@{#535} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/229aed5b182860fad333aa574bf49e6434702b89/net/cert/x509_util_mac.cc
,
Sep 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/07867a41827a6e9bc4ffa65e666882e3928b20bb commit 07867a41827a6e9bc4ffa65e666882e3928b20bb Author: mattm <mattm@chromium.org> Date: Mon Sep 26 22:00:53 2016 Revert of Hack for AIA fetching on Mac Sierra: On >=10.12, always do FETCH_CRL_FROM_NET if adding a crl polic… (patchset #1 id:1 of https://codereview.chromium.org/2370983002/ ) Reason for revert: Broke build due to calling function renamed on trunk. BUG=650407, 645629 Original issue's description: > Hack for AIA fetching on Mac Sierra: On >=10.12, always do FETCH_CRL_FROM_NET if adding a crl policy. > > BUG= 645629 > > Review-Url: https://codereview.chromium.org/2368453002 > Cr-Commit-Position: refs/heads/master@{#420482} > (cherry picked from commit 97a93ce4d2bbf3808e16c612c1ece99f1c3406ef) > > Committed: https://chromium.googlesource.com/chromium/src/+/229aed5b182860fad333aa574bf49e6434702b89 TBR= # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= 645629 Review-Url: https://codereview.chromium.org/2373653003 Cr-Commit-Position: refs/branch-heads/2840@{#536} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/07867a41827a6e9bc4ffa65e666882e3928b20bb/net/cert/x509_util_mac.cc
,
Sep 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a033fd9f6a5c05209d57e3a1f0644360e21cd66c commit a033fd9f6a5c05209d57e3a1f0644360e21cd66c Author: Matt Mueller <mattm@chromium.org> Date: Mon Sep 26 23:54:57 2016 Hack for AIA fetching on Mac Sierra: On >=10.12, always do FETCH_CRL_FROM_NET if adding a crl policy. BUG= 645629 Review-Url: https://codereview.chromium.org/2368453002 Cr-Commit-Position: refs/heads/master@{#420482} (cherry picked from commit 97a93ce4d2bbf3808e16c612c1ece99f1c3406ef) (with compile fix for renamed IsAtLeastOS10_12 function) Review URL: https://codereview.chromium.org/2371033002 . Cr-Commit-Position: refs/branch-heads/2840@{#540} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/a033fd9f6a5c05209d57e3a1f0644360e21cd66c/net/cert/x509_util_mac.cc
,
Sep 27 2016
Impact: around 2.30% of SSL connections with Stable on macOS 10.12 fail with CERT_AUTHORITY_INVALID, vs 0.53% with Stable on macOS 10.11. Since these errors are a function of the site's configuration, there is no practical workaround other than bypassing the SSL interstitial. SSL connections on macOS 10.12 make up roughly 5% of all macOS SSL connections for us. Patch risk: mattm@ can chime in about this better than I can.
,
Sep 27 2016
Validated this change: When navigating to https://incomplete-chain.badssl.com, current stable (53.0.2785.116) fails with ERR_CERT_AUTHORITY_INVALID, and current canary (55.0.2873.0) connects successfully.
,
Sep 27 2016
Wouldn't expect much risk since this is a flag we would already enable in certain circumstances. The only thing I might expect is perhaps some latency increase in certificate verification due to the flag probably enabling CRL fetching in addition to AIA (but note that some of the increase will be inherent in re-enabling AIA fetching, so you'd need to compare to other OS versions, not to pre-patch numbers on Sierra.) I looked on UMA but comparing numbers this way isn't really helpful (each OS version has faster numbers than the last, as you might expect if users with newer machines are more likely to upgrade to the latest OS). The numbers on Sierra canary post-patch are a little slower than they were pre-patch, but still faster than on El Capitan and earlier versions (and again, the increase may just be due to re-enabling AIA fetching).
,
Sep 27 2016
We decided NOT to take this merge in for M53 respin this week.
,
Sep 28 2016
Tested the issue on Mac OS X 10.12 Sierra using the URLs provided in Comment# 15 & 16 and is working as intended. Tested Versions -- Chrome Beta# 54.0.2840.41 and Chrome Canary# 55.0.2874.0. Hence adding TE-Verified Labels. Thank You.
,
Oct 1 2016
Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable? If a fix is in active development, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 1 2016
,
Oct 12 2016
,
Oct 23 2016
Try this, it may help you to fix the problem. https://usefulpcguide.com/16666/your-connection-is-not-private/
,
Oct 23 2016
In general, you should not follow the advice on that page, other than checking your clock and antivirus. Some of the suggestions - such as changing the shortcut - will actively make Chrome insecure and prevent any guarantees of the privacy of your information.
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/229aed5b182860fad333aa574bf49e6434702b89 commit 229aed5b182860fad333aa574bf49e6434702b89 Author: Matt Mueller <mattm@chromium.org> Date: Mon Sep 26 20:41:56 2016 Hack for AIA fetching on Mac Sierra: On >=10.12, always do FETCH_CRL_FROM_NET if adding a crl policy. BUG= 645629 Review-Url: https://codereview.chromium.org/2368453002 Cr-Commit-Position: refs/heads/master@{#420482} (cherry picked from commit 97a93ce4d2bbf3808e16c612c1ece99f1c3406ef) Review URL: https://codereview.chromium.org/2370983002 . Cr-Commit-Position: refs/branch-heads/2840@{#535} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/229aed5b182860fad333aa574bf49e6434702b89/net/cert/x509_util_mac.cc
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/07867a41827a6e9bc4ffa65e666882e3928b20bb commit 07867a41827a6e9bc4ffa65e666882e3928b20bb Author: mattm <mattm@chromium.org> Date: Mon Sep 26 22:00:53 2016 Revert of Hack for AIA fetching on Mac Sierra: On >=10.12, always do FETCH_CRL_FROM_NET if adding a crl polic… (patchset #1 id:1 of https://codereview.chromium.org/2370983002/ ) Reason for revert: Broke build due to calling function renamed on trunk. BUG=650407, 645629 Original issue's description: > Hack for AIA fetching on Mac Sierra: On >=10.12, always do FETCH_CRL_FROM_NET if adding a crl policy. > > BUG= 645629 > > Review-Url: https://codereview.chromium.org/2368453002 > Cr-Commit-Position: refs/heads/master@{#420482} > (cherry picked from commit 97a93ce4d2bbf3808e16c612c1ece99f1c3406ef) > > Committed: https://chromium.googlesource.com/chromium/src/+/229aed5b182860fad333aa574bf49e6434702b89 TBR= # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= 645629 Review-Url: https://codereview.chromium.org/2373653003 Cr-Commit-Position: refs/branch-heads/2840@{#536} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/07867a41827a6e9bc4ffa65e666882e3928b20bb/net/cert/x509_util_mac.cc
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a033fd9f6a5c05209d57e3a1f0644360e21cd66c commit a033fd9f6a5c05209d57e3a1f0644360e21cd66c Author: Matt Mueller <mattm@chromium.org> Date: Mon Sep 26 23:54:57 2016 Hack for AIA fetching on Mac Sierra: On >=10.12, always do FETCH_CRL_FROM_NET if adding a crl policy. BUG= 645629 Review-Url: https://codereview.chromium.org/2368453002 Cr-Commit-Position: refs/heads/master@{#420482} (cherry picked from commit 97a93ce4d2bbf3808e16c612c1ece99f1c3406ef) (with compile fix for renamed IsAtLeastOS10_12 function) Review URL: https://codereview.chromium.org/2371033002 . Cr-Commit-Position: refs/branch-heads/2840@{#540} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/a033fd9f6a5c05209d57e3a1f0644360e21cd66c/net/cert/x509_util_mac.cc
,
Nov 29 2016
|
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by rsleevi@chromium.org
, Sep 9 2016Components: -Internals>Network>SSL Internals>Network>Certificate
Labels: Needs-Feedback