Hi grace,
could you help triage this issue ?

Kirtika could you please take a look or pass it along to the right folks?

+pmarko as this seems pretty severe. Can you please check and see whether the latest changes have regressed this code path?

62 -> 63 changes. 
https://crosland.corp.google.com/log/9901.77.0..10032.39.0

shill is not the culprit, so this is either Chrome or the wpa-supplicant uprev patches, if it Chrome OS. 
+ejcaruso@ FYI.


 

M62 stable had the uprev and extra patches already so I think that has a comparatively lower probability of causing this issue.

I'm not aware of changes which I would think could have caused this.

Is it possible to manually "Import and Bind" a certificate? I have generated a testing client certificate "test_client_cert.p12" (password is 1234) and attached it.

Kirtika is trying to see if we can repro problems with the cert enrollment process on the same version.

+Katherine/Jing: Have you observed not being able to enroll certs on M-63 beta lately?

Anyway, it seems that the extension in question (ldlfakmjimohnhnpgnjmjkdnaiegiebg) calls 
chrome.enterprise.platformKeys.importCertificate(token_id, cert_data, callback) as expected and displays the "success" popup message when |callback| is called. We can't see if |callback| was passed an error because the extension does not react on that (to be fair, our docs don't specify that the callback could be passed an error [1]).

[1] https://developer.chrome.com/extensions/enterprise_platformKeys#method-importCertificate

Deleted: test_client_cert.p12 2.6 KB

test_client_cert.p12 2.6 KB Download

M63 goes stable Dec 5th. Do you think we can land a fix this week?

Re Comment #8: Unfortunately, we're still in the stage of trying to find out what went wrong here. We're trying to reproduce locally at the moment and if that fails, I'd ask marcore if he could test with our platformKeys test extension which should give more diagnostics information.

BTW I checked if my CL https://chromium-review.googlesource.com/c/chromium/src/+/768383 which touches some cert handling code could be the culprit, but it can't, because:
- it landed in >= 63.0.3239.51, while the issue is being observed in 63.0.3239.50
- it doesn't touch anything that would (directly) change what is displayed in certificate manager in settings (certificate manager doesn't go through CertLoader, it queries the NSSDatabase directly).
- it doesn't touch anything that would (directly) change how platformKeys API behaves - the API goes directly to NSSDatabase.

Update:
I've tried to reproduce this with our platformKeys test extension on
- 63.0.3239.50 (test build) on lulu (Dell Chromebook 7310)
- 63.0.3239.50 (test build) on caroline

Both worked as expected, I was able to generate a keypair, export a CSR, import the resulting certificate. It appeared in the Certificate Manager and in wifi network selection.
I've tried to use the parameters I think have been used by the extension in the report (SHA-1, key length 2048).

+emaxx for more ideas.

@marcore:
Could you please ask the customer if they know if only one user is affected or several user? Similarly, is only one machine affected or several machines?

Also, could you please ask them if they would be so kind to try to help us gather more diagnostic data with our test extension? The process would be as follows:
(1) Force-install the 'PlatformKeys Test Extension' test extension (hoppbgdeajkagempifacalpdapphfoai) through policy
    Chrome WebStore link: https://chrome.google.com/webstore/detail/platformkeys-test-extensi/hoppbgdeajkagempifacalpdapphfoai
(2) In a user session, open a browser and go to chrome-extension://hoppbgdeajkagempifacalpdapphfoai/main.html
(3) What does the "Get user token:" text box say?
(4) Please scroll down to the "List Certificates" button and press it.
    What does the "Certificates:" field to the right of it say?
(5) Please scroll back up and change "Modulus length in bits:" to 2048
(5) Press "Generate Key Pair"
(6) Change "Subject RDN": replace "client5" with "extension_test_client"
(7) Press "Create Request"
(8) Could you provide us with the contents of the "PKCS#10 Certification Request" field?

Thanks.

In the meantime, I'll try to see if I can get the Cisco Network Setup Assistant extension running.

BTW, I've seen that there was an ecryptfs->ext4 migration in the logs, so I've tried to create an ecryptfs profile, import one cert into it, then migrate to ext4, and import another cert. This worked fine too.

Also confirmed that TPM version is the same on my test lulu device and in the logs (..00420).

Hello, 

I'm Emmanuel CAMPREDON from the customer which is facing the issue.

Please find below the result of my tests : 

Could you please ask the customer if they know if only one user is affected or several user? Similarly, is only one machine affected or several machines?

It impact any user, on any chromebook model (tested HP, DELL & Samsung)


(1) Force-install the 'PlatformKeys Test Extension' test extension (hoppbgdeajkagempifacalpdapphfoai) through policy
    Chrome WebStore link: https://chrome.google.com/webstore/detail/platformkeys-test-extensi/hoppbgdeajkagempifacalpdapphfoai 
DONE

(2) In a user session, open a browser and go to chrome-extension://hoppbgdeajkagempifacalpdapphfoai/main.html
DONE

(3) What does the "Get user token:" text box say? 
"Error: no 'chrome.enterprise.platformKeys' API"

(4) Please scroll down to the "List Certificates" button and press it. What does the "Certificates:" field to the right of it say?
Nothing. Status= Listing certificates ... does nothing

(5) Please scroll back up and change "Modulus length in bits:" to 2048
DONE

(5) Press "Generate Key Pair"
DONE Does nothing status = Generated Key: Generating...

(6) Change "Subject RDN": replace "client5" with "extension_test_client"
DONE

(7) Press "Create Request"
Done. Does nothing status = No key generated yet

(8) Could you provide us with the contents of the "PKCS#10 Certification Request" field?
Blank

Deleted: Screenshot 2017-11-29 at 2.52.10 PM.png 427 KB

	Screenshot 2017-11-29 at 2.52.10 PM.png 427 KB View Download

Deleted: Screenshot 2017-11-29 at 2.52.40 PM.png 66.1 KB

	Screenshot 2017-11-29 at 2.52.40 PM.png 66.1 KB View Download

emmanuel.campredon@, thanks for the quick feedback!

As we're still unable to reproduce the issue on our side, we are kindly asking you to provide us with more information:

1. Could you please attach the contents of the chrome://policy and chrome://extensions pages (after doing steps from comment 12)?
Because the error "Can't access the API" from comment 14 is rather unexpected - a force-installed extension should normally have this granted.

2. Please collect the logs from the Cisco Network Setup Assistant extension after doing the repro steps.
For collecting the extension's logs, go to chrome://extensions, tick "Developer mode", scroll down to that extension, click on "background page", go to the "Console" tab and save all data from there.

Hi again,
Please find attached the files you requested.

Hope it will help you.

Deleted: Chrome Extensions.pdf 196 KB

Chrome Extensions.pdf 196 KB Download

Deleted: policies.json 14.6 KB

policies.json 14.6 KB View Download

Deleted: 88-B1-11-D4-B0-7A Not working HP G1 .log 3.0 KB

88-B1-11-D4-B0-7A Not working HP G1 .log 3.0 KB View Download

Thanks! So these logs show:

* The fatal error is reported by the Cisco extension here:
  "enterprise.platformKeys.importCertificate: Certificate is not a valid X.509 certificate."
We need to investigate more whether there's a bug in Chrome that could cause this. (I'm recalling I was receiving similar failures as flaky errors when was manually testing the API some day, but not sure whether it's related. This time it's definitely not a flakiness.)

* There's also an earlier error in the Cisco extension's logs:
  "Error in response to tabs.query: TypeError: Cannot read property 'id' of undefined"
We don't know, however, whether it's an indication of any real error.

* The PlatformKeys Test Extension, according to the snapshot of the chrome://extensions page, was NOT force-installed, which explains why it didn't work.
But, anyway, we have now some details from the Cisco extension, enabling us to start the investigation.

Thanks for providing us the details!

BTW, would it be possible to get the actual certificate from the enrollment server? This way we could test if it passes the input validation performed on Chrome OS certificate import.

+mattm@

Matt, IIUC use_byte_certs was enabled for Chrome OS in M-63.
By any chance, have we encountered certificates which could be parsed before but not with the new version (e.g. because it does not conform to the RFC but the old code didn't care)?

Background: It seems that our enterprise.platformKeys API started rejecting certs imported from the "Cisco Network Setup Assistant" / the CA used by it in this deployment in M-63. While we're still investigating if something broke in the API logic, and while we don't have an example cert which is being rejected, it *might* help to know if there are known cases of e.g. certificate format validation getting more strict.

Thanks.

There are some cases where the new code is stricter, yeah. 

For instance: a certificate with extensions but not marked as v3.

Another case was a printableString containing invalid characters. We added a hack for such client certificates in  issue 770323 , though looking back at that CL I missed turning it on for the chromeos extension api. (I can make a CL to correct that.)

There are various other things that could cause it to be rejected as well, to be sure we'd need to see an example cert.

emmanuel.campredon@: Could you please extract and attach an example certificate from the working device (on M62)?
Exact steps: go to chrome://settings/certificates, find the certificate, click "..."=>"View", go to the "Details" tab, click "Export", select "Base64-encoded ASCII, certificate chain" and save the file.

Re Comment #21: This is sounds much easier to execute than trying to extract the cert from the enrollment server like I suggested in Comment #18, thanks Maksim :)

Re Comment #20: I *think* it may make sense to enable the hack you mention for the API independently of what's going on in this particular case, if we decided to live with invalid characters in printableString going forward (instead of e.g. warning, collecting metrics, trying to extinguish such certs). I assume users would only notice this when re-enrolling certs, so Chrome OS system updates could work for them without any issues, but they'd notice issues the first time they're importing a cert on one of the new versions.

Anyway, I hope we'll get an example cert today so we can see what's wrong there.

please find attached one example of a certificate successfully installed on Chrome62.

Deleted: User TPM Token 1ad7d7d279f3e91c_emmanuel.campredon@solvay.pem 1.9 KB

User TPM Token 1ad7d7d279f3e91c_emmanuel.campredon@solvay.pem 1.9 KB Download

Re Comment #23:
Thank you for providing us with the example certificate!

@Team:
I've run this through a "X509Certificate::CreateCertificateListFromBytes" unittest, and it fails validation in [1].

Specifically, we end up reading in the subject CommonName in X509NameAttribute::ValueAsStringWithUnsafeOptions with printable_string_handling == PrintableStringHandling::kDefault, ValueAsString jumps into the der::kPrintableString case, and then fails on the @ character in [2].

Subject: CN=emmanuel.campredon@solvay.com, OU=Chromebook, O=Solvay, L=, ST=, C=

When I set options.printable_string_is_utf8 = true; (options is a X509Certificate::UnsafeCreateOptions), the certificate parses fine.

So I think we should enable the "hack" for this API.
Matt, would you mind making a CL for that?

[1] https://cs.chromium.org/chromium/src/net/cert/x509_certificate.cc?rcl=08990b7b2e864e6151ee9b5a70ba5cc88e755c86&l=907
[2] https://cs.chromium.org/chromium/src/net/cert/internal/parse_name.cc?rcl=9f22dc403403a8eb37d011f2fc64dd53d4c023d1&l=224

FTR the input paths where certs come in in the API are here:
https://cs.chromium.org/search/?q=file:platform_keys+CreateFromBytes%5C(&sq=package:chromium&type=cs

To be consistent, we should enable the hack for all 4 of these entry points.

Hello Chromium support team,

For information, customer SOLVAY also opened a ticket at CISCO:
SR 683505334 : Chrome OS 63 certificate provisioning
The main support contact at CISCO is Zaid Al-Kurdi (zalkurdi) <zalkurdi@cisco.com>

Sure, I'll make a CL.
Seems like the one in chrome/browser/extensions/api/certificate_provider/certificate_provider_api.cc is also relevant?

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

commit 90c1b36a76efb761f0f40c168f9c643826cf5702
Author: Matt Mueller <mattm@chromium.org>
Date: Fri Dec 01 02:08:56 2017

Use X509Certificate printable_string_is_utf8 hack for ChromeOS client cert extension apis

Bug:  788655 
Change-Id: Ib43359d84663d72719853c63d910ae2d2d03eabb
Reviewed-on: https://chromium-review.googlesource.com/801995
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Commit-Queue: Matt Mueller <mattm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520790}
[modify] https://crrev.com/90c1b36a76efb761f0f40c168f9c643826cf5702/chrome/browser/extensions/api/certificate_provider/certificate_provider_api.cc
[modify] https://crrev.com/90c1b36a76efb761f0f40c168f9c643826cf5702/chrome/browser/extensions/api/enterprise_platform_keys/enterprise_platform_keys_api.cc
[modify] https://crrev.com/90c1b36a76efb761f0f40c168f9c643826cf5702/chrome/browser/extensions/api/platform_keys/platform_keys_api.cc
[modify] https://crrev.com/90c1b36a76efb761f0f40c168f9c643826cf5702/net/cert/x509_certificate.cc
[modify] https://crrev.com/90c1b36a76efb761f0f40c168f9c643826cf5702/net/cert/x509_certificate.h

Re Comment #27 and Comment #28:
Thanks Matt! Yes, I missed the certificate_provider_api.cc.

I'll verify that the API import code the passes the first steps with the Certificate from Comment #23 and only fails at trying to confirm that the private key is on the same slot today.
Then I'll ask for merge approval to M-63.

Tested manually on trunk and confirmed that the certificate from comment 23 now successfully passes through the import API, including the parsing code, down to the slot check.

Requesting merge to M63.

This bug requires manual review: We are only 3 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

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

Hello team, 

Following my comment #26 we've receive info below from CISCO support team 
--at least the correction from Google Chrome will be temporary fixing the issues, and then we should have a perennial solution with CISCO ISE. 

New information received from CISCO support team:
The bug ID at CISCO is CSCvg97635: NSA using invalid character/encoding for CN breaks Chromebook onboarding
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvg97635/?reffering_site=dumpcr
 
Once it is publicly available, feel free to subscribe to it to receive constant updates regarding the resolution. At the moment there is no ETA for the fix but this is assigned as a sev 2 bug so it should be worked on with a high priority.

This bug requires manual review: We are only 0 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

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

Adding RBS for M64 for long term fix

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

commit a681b38160800244af914d895934f232039d75ba
Author: Pavol Marko <pmarko@chromium.org>
Date: Mon Dec 04 20:05:50 2017

[Merge to M63] Use X509Certificate printable_string_is_utf8 hack for ChromeOS client cert extension apis

TBR=mattm@chromium.org

(cherry picked from commit 90c1b36a76efb761f0f40c168f9c643826cf5702)

Bug:  788655 
Change-Id: Ib43359d84663d72719853c63d910ae2d2d03eabb
Reviewed-on: https://chromium-review.googlesource.com/801995
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Commit-Queue: Matt Mueller <mattm@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#520790}
Reviewed-on: https://chromium-review.googlesource.com/806226
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#636}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/a681b38160800244af914d895934f232039d75ba/chrome/browser/extensions/api/certificate_provider/certificate_provider_api.cc
[modify] https://crrev.com/a681b38160800244af914d895934f232039d75ba/chrome/browser/extensions/api/enterprise_platform_keys/enterprise_platform_keys_api.cc
[modify] https://crrev.com/a681b38160800244af914d895934f232039d75ba/chrome/browser/extensions/api/platform_keys/platform_keys_api.cc
[modify] https://crrev.com/a681b38160800244af914d895934f232039d75ba/net/cert/x509_certificate.cc
[modify] https://crrev.com/a681b38160800244af914d895934f232039d75ba/net/cert/x509_certificate.h

Current status: The merge has reached 63.0.3239.82 which is not being served on the Beta channel yet. Not sure if there is going to be another Beta or if this goes directly to stable.

Just checked that 63.0.3239.85 is now being served in Beta channel, so this workaround should be active there.

emmanuel.campredon@, would you mind checking if you can now import the certificates using the extension?

Thanks!

Hello,

We did a test today and I confirm that now it's possible to install the certificate from the CISCO ISE console with the version 63.0.3239.85.

The only issue remaining is that now the connection to our Wifi is not fully automatic. The user is prompted with this windows (see attachment). The user just need to click on "Connect" and the connection is working well. This behavior was not there with OS v 62, the connection was fully transparent for the user. Can you help on that ?

Deleted: ChromeOS 63 connection to Solvay Wifi not automatic anymore.webm 7.5 MB

	ChromeOS 63 connection to Solvay Wifi not automatic anymore.webm 7.5 MB View Download

emmanuel.campredon@,

Thanks for the feedback! We're trying to reproduce this issue.
For clarification: Does this happen once after the certificate has been imported through the extension (and automatically connects on following sign-ins), or do you have to do this after each subsequent sign-in too?

@Team:
The first finding is that our pattern-based cert resolving logic re-parses the certificate, which fails again for these invalid certificates.
Specifcally,
the net::x509_util::CreateX509CertificateFromCERTCertificate call in MatchCertWithPattern::operator() [1] fails.

This explains the behavior of:
- not auto-connecting
- the "User Certificate" box being empty in the video in the wifi config dialog.

However, it does not explain why it's possible to connect when pressing "Connect" manually.
(while this runs into a different, synchronous cert resolving procedure[2], it should (and does in unit tests) also fail on the same condition).

Anyway, I'll upload a CL to enable the workaround for this place, and try to see if I can spot any other places where we re-parse the client certificates.

[1] https://cs.chromium.org/chromium/src/chromeos/network/client_cert_resolver.cc?l=124&gs=kythe%253A%252F%252Fchromium%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fchromeos%252Fnetwork%252Fclient_cert_resolver.cc%2523JS2R142Xre9EPH2BavBK%25252B1CjYUTlRDSDJHiTO1Vyh58%25253D&gsn=operator()&ct=xref_usages
[2] https://cs.chromium.org/chromium/src/chromeos/network/client_cert_resolver.cc?l=361&gs=kythe%253A%252F%252Fchromium%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fchromeos%252Fnetwork%252Fclient_cert_resolver.cc%2523yoYq6TM56FvIJQxYw5QbGnoA9N0cZANgr06nN5ziRlM%25253D&gsn=ResolveCertificatePatternSync&ct=xref_usages

Second finding:
Being able to connect manually probably comes from an unintended consequence of  https://codereview.chromium.org/2887993003.
If the certificate selection is managed, but the cert could not be resolved, we display an empty string in the "User Certificate" selection box (which can be observed here).
If the user has >0 certificates, this can be interpreted by another part of the wifi config dialog[3] as a valid cert selection (index 0), effectively selecting the first of the user's certificates.
I will fix this in a separate CL.

[3] WifiConfigView::SetEapClientCertProperties

Thanks you for the investigation.

Just to share with you, we tried to generate a certificate without the email address of the user inside but his samaccountname instead and it works as expected. So it confirms what you found out.

Thanks for confirming, that's very helpful!
BTW, does this mean that the whole issue is resolved for you on the certificate issuing side of things?

CL up:
https://chromium-review.googlesource.com/c/chromium/src/+/823974 

Seems like this bug lost the M-63 label at some point and therefore fell off the radar even though the second fix hasn't landed yet...

gkihumba@, kathrelkeld@: Is there any chance the release can be delayed for the fix of this issue?
Otherwise it will be needed to announce with this release that there's a known regression with regard to client certificates with incorrect string fields, and they will need to update their deployments in order to workaround that. (The issue is similar to  issue 770323 , but now with cert enrollment extensions and with EAP-TLS networks.)

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

commit 6ce72d064e6dea3ea958c1789df877735f187d62
Author: Pavol Marko <pmarko@chromium.org>
Date: Fri Dec 15 00:34:24 2017

Use X509Certificate printable_string_is_utf8 hack in more ChromeOS client cert code

Enable the X509Certificate printable_string_is_utf8 hack for:
- ClientCertResolver: Parses client certificates to match Issuer/Subject
  patterns
- enterprise.platformKeys.getCertificates API: Parses client
  certificates to get DER representation.

BUG= 788655 
TEST=chromeos_unittests --gtest_filter=ClientCertResolverTest.*

Change-Id: Iea02c525ed91017ccd1957da2ea0e28597c1bd9f
Reviewed-on: https://chromium-review.googlesource.com/823974
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Matt Mueller <mattm@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524262}
[modify] https://crrev.com/6ce72d064e6dea3ea958c1789df877735f187d62/chrome/browser/chromeos/platform_keys/platform_keys_nss.cc
[modify] https://crrev.com/6ce72d064e6dea3ea958c1789df877735f187d62/chromeos/network/client_cert_resolver.cc
[modify] https://crrev.com/6ce72d064e6dea3ea958c1789df877735f187d62/chromeos/network/client_cert_resolver_unittest.cc

Requesting merge of second fix (from comment 49) into M-63.

Also requesting the merge of both fixes (from comment 28 and comment 49) into M-64.

Approving merge to M64 Chrome OS.

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

commit 3f4eafc88fb8c98721fc38c32154db330ee55183
Author: Pavol Marko <pmarko@chromium.org>
Date: Fri Dec 15 21:41:44 2017

[Merge to M64] Use X509Certificate printable_string_is_utf8 hack in more ChromeOS client cert code

Enable the X509Certificate printable_string_is_utf8 hack for:
- ClientCertResolver: Parses client certificates to match Issuer/Subject
  patterns
- enterprise.platformKeys.getCertificates API: Parses client
  certificates to get DER representation.

TBR=stevenjb@chromium.org, mattm@chromium.org

BUG= 788655 
TEST=chromeos_unittests --gtest_filter=ClientCertResolverTest.*

Change-Id: Iea02c525ed91017ccd1957da2ea0e28597c1bd9f
Reviewed-on: https://chromium-review.googlesource.com/823974
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Matt Mueller <mattm@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#524262}(cherry picked from commit 6ce72d064e6dea3ea958c1789df877735f187d62)
Reviewed-on: https://chromium-review.googlesource.com/830866
Cr-Commit-Position: refs/branch-heads/3282@{#244}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/3f4eafc88fb8c98721fc38c32154db330ee55183/chrome/browser/chromeos/platform_keys/platform_keys_nss.cc
[modify] https://crrev.com/3f4eafc88fb8c98721fc38c32154db330ee55183/chromeos/network/client_cert_resolver.cc
[modify] https://crrev.com/3f4eafc88fb8c98721fc38c32154db330ee55183/chromeos/network/client_cert_resolver_unittest.cc

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

commit 4d0a7340635065c382cda89a2363dcfab462f7e8
Author: Pavol Marko <pmarko@chromium.org>
Date: Sun Dec 17 14:15:31 2017

[Merge to M63] Use X509Certificate printable_string_is_utf8 hack in more ChromeOS client cert code

Enable the X509Certificate printable_string_is_utf8 hack for:
- ClientCertResolver: Parses client certificates to match Issuer/Subject
  patterns
- enterprise.platformKeys.getCertificates API: Parses client
  certificates to get DER representation.

TBR=stevenjb@chromium.org, mattm@chromium.org

BUG= 788655 
TEST=chromeos_unittests --gtest_filter=ClientCertResolverTest.*

Change-Id: Iea02c525ed91017ccd1957da2ea0e28597c1bd9f
Reviewed-on: https://chromium-review.googlesource.com/823974
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Matt Mueller <mattm@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Cr-Original-Original-Commit-Position: refs/heads/master@{#524262}(cherry picked from commit 6ce72d064e6dea3ea958c1789df877735f187d62)
Reviewed-on: https://chromium-review.googlesource.com/830866
Cr-Original-Commit-Position: refs/branch-heads/3282@{#244}
Cr-Original-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}(cherry picked from commit 3f4eafc88fb8c98721fc38c32154db330ee55183)
Reviewed-on: https://chromium-review.googlesource.com/831586
Cr-Commit-Position: refs/branch-heads/3239@{#687}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/4d0a7340635065c382cda89a2363dcfab462f7e8/chrome/browser/chromeos/platform_keys/platform_keys_nss.cc
[modify] https://crrev.com/4d0a7340635065c382cda89a2363dcfab462f7e8/chromeos/network/client_cert_resolver.cc
[modify] https://crrev.com/4d0a7340635065c382cda89a2363dcfab462f7e8/chromeos/network/client_cert_resolver_unittest.cc

Thanks for doing the merging Maksim!
The Merge from Comment #54 landed in 63.0.3239.115.

M63 and M64 and ToT should be fine now.

Removing Merge-Approved-63 label again as this has been merged into 63 already.

Closing this as Verified. Re-open if you continue to see this issue.