Thank for reporting this!

The strange part is that the extension already hangs on getting the system/user tokens, which it starts doing when the extension is started.
I've seen this once on my machine but could not reproduce it later, so a few more questions?
- This is an affiliated user session, right?
- Does this still happen after reboot?
- If yes: Does it help if you wait ~30 seconds between sign-in and opening the extension?

Technical details for reference:
I'm not sure yet what could be wrong here. Probably the enterprise.platformKeys.getTokens function hangs on retrieving the user's NSS Database (GetCertDatabaseOnIOThread).
This would mean that GetPrivateSlotForChromeOSUser never finishes, which would in turn mean that InitializeTPMTokenAndSystemSlot is either not called or fails for some reason.

The log contains the line
"[1602:1748:0515/183957.014010:ERROR:nss_util.cc(475)] TPM slot 0 not found."
so what could happen is that:
- We're trying to initialize the TPM on the sign-in screen now for access to device-wide system token certs
- When the device is not owned yet, this fails and there is no TPM system slot 0 (speculation)
- In that state we can't retrieve the user's TPM token anymore (speculation) so the API fails
A reboot after enrolling the device should act as a workaround if that's the case. A permanent fix would be trying to load the TPM on the sing-in screen only if the device is enrolled.

I was able to reproduce it. What's worse, it actually crashes when opening the extension after reboot.
I must have provisioned the system certificate with a previous chrome binary in my testing.
Investigating now and trying to fix ASAP. Sorry for the delay.

I believe this has been caused by an unrelated change which also went into 9548.0.0. It seems that one of the following changes could have broken something in Chaps:
https://chromium-review.googlesource.com/c/503551/
https://chromium-review.googlesource.com/c/500667/

(Changes in 9548.0.0: https://crosland.corp.google.com/log/9547.0.0..9548.0.0)

What I found out:
- When I patch my chrome binary over 9547.0.0, system certificate enrollment with the given extension still works fine, so I don't think the chrome binary is the problem.
- Listing slots with
pkcs11-tool --module /usr/lib64/libchaps.so --list-slots
as root on the chromebook works fine in 9547.0.0, but returns errors on 9548.0.0.
- The crash happens in libnss3, sadly I didn't manage to get a crash report (not sure why).

@ejcaruso:
Could it be that one of the following changes broke something with how chaps works on chromeos devices?

https://chromium-review.googlesource.com/c/503551/
https://chromium-review.googlesource.com/c/500667/

The symptoms I'm seeing:
- When I ssh into the device as root (or use the console), I used to be able to list tokens using pcks11-tool. The output I usually got looked like:
localhost ~ # pkcs11-tool --module /usr/lib64/libchaps.so --list-slots
Available slots:
Slot 0 (0x0): TPM Slot
  token label:   System TPM Token
  token manuf:   Chromium OS
  token model:   
  token flags:   rng, PIN initialized, PIN pad present, token initialized
  serial num  :  Not Available

With 9548.0.0 (where those changes landed), I get something mentioning CKR_GENERAL_ERROR instead.

Listing tokens from chrome seems to crash in libnss3 sometimes. Unfortunately, I wasn't able to get a crash dump or stack trace. I will try to reproduce again tomorrow and see if I can generate a stack trace.

CL:506385 up. Sorry about that, folks!

Not able to connect to Google-A due to this.

Chrome is crashing, when adding certificates using "Import and bind" button in certificate manager. Is this related? or else will open a separate issue. 

Tested on Samus R60 9557.0.0 Logs attached. 

@ Aashutosh Not sure if this is same issue for crashing when adding any certificates using "Import and bind" button in certificate manager.

It could be separate issue.

@ejcaruso : Do you have any details on this?

I do think it's the same issue - we see crashes in libnss3 invoked through:
- Manual certificate import
- Certificate import from ONC user policy
- The getTokens API
I expect these issues to have the same root cause and to be resolved when the commit queue picks up and commits the change mentioned in Comment #6.

Thanks for your patience!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/32bba00e97069389d8e7e2323cc4a8bb2657244c

commit 32bba00e97069389d8e7e2323cc4a8bb2657244c
Author: Eric Caruso <ejcaruso@chromium.org>
Date: Wed May 17 21:42:13 2017

chaps: clear vectors before serializing protos

Not sure where the D-Bus vectors come from, but they must have
had some uninitialized data in them that was preventing us from
deserializing the protos correctly on the other side and the
unit tests failed to catch it.

BUG= chromium:722677 
TEST=pkcs11-tool --module libchaps.so --list-tokens and
  pkcs11-tool --module libchaps.so --list-mechanisms both work
  and give expected output

Change-Id: Ia92b2000e7538924d6aa6fdb0230b462dfa3ead1
Reviewed-on: https://chromium-review.googlesource.com/506385
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Commit-Queue: Eric Caruso <ejcaruso@chromium.org>
Tested-by: Eric Caruso <ejcaruso@chromium.org>

[modify] https://crrev.com/32bba00e97069389d8e7e2323cc4a8bb2657244c/chaps/chaps_adaptor.cc

I have just tested build 9562.0.0 and I can confirm that the chrome.enterprise.platformKeys API usecase works fine for me again.

(I haven't tested certificate import through chrome://certificate-manager/ or ONC policy certificate import but I assume the root cause was the same so it should work again.)

 Issue 724214  has been merged into this issue.

When can this new build be pushed to Asus C302CA for our testing?

As verified in M60.0.3101.0: 9562.0.0 dev snappy, the issues with chrome.enterprise.platformKeys API have been fixed and the API is now working fine.  I could generate the keys via the methods mentioned in #0 and did not encounter any error.

Could connect to Google-A network now in M60/Peppy Device.

M	ChromeOS	Chrome	ARC	Type	Channel
60	9563.0.0	60.0.3102.0	(multiple)	release	dev

Issue 724370 has been merged into this issue.

Are there any workarounds for this bug?

Issue 724470 has been merged into this issue.

Re Comment #20:
Not that I know of, sorry, short of waiting for the next dev channel update or manually flashing to a newer version.

Issue 724952 has been merged into this issue.

 Issue 725343  has been merged into this issue.

 Issue 725547  has been merged into this issue.