The way that this is expected to work for ChromeOS - or for any platform - is that the intermediate and root have been made available and installed on the system.

It is not expected that the extension can return the 'correct' chain.

Have you explored this configuration?

I should clarify: the onCertificatesRequested() callback today only supports returning leaf certificates. There is not a way with the certificateProvider API to provide notions such as 'trusted certificates' or 'supplementary certificates'. It was definitely intentional that the former was considered out of scope - we don't want simply attaching a device to equal installing a trusted root.

This is documented in https://developer.chrome.com/extensions/certificateProvider as part of the API documentation - namely, onCertificatesRequested.addListener's callback notes "The list must only contain certificates for which the extension can sign data using the associated private key." Obviously, this wouldn't be the case for your intermediates or root (I hope!)

Installing certificates ad-hoc is restricted, either for client certs using https://developer.chrome.com/extensions/enterprise_platformKeys#method-importCertificate or for intermediate and root certificates using an Open Network Configuration file, as documented in https://chromium.googlesource.com/chromium/src/+/master/components/onc/docs/onc_spec.md#certificates

It may be reasonable to provide additional APIs to support loading 'not affirmatively trusted' certificates from smart cards as well through this API (e.g. to assist with chain building), although the API can't make any guarantees that those certificates are removed/unloaded from all caches. Tagging this as a Feature request for that team.

Hi Ryan,

I'd missed that note in the documentation that the callback should only contain leaf certificates, but had figured that much out in the mean time :) thanks for pointing it out, at any rate.

(wearing my "eID contractor hat")
FYI: for performance reasons, the Belgian Federal Authentication Service (FAS) is not going to be sending the intermediate certificates in the DN request, so that means that until an extension is able to provide additional certificates to ChromeOS to assist in chain building for client certificates, people will not be able to use ChromeOS devices to log on to the relevant websites to interact with the government (e.g., to do their tax declaration).

Thanks for considering this feature.

I'm not sure why you say it will not be possible - as noted, installing the correct intermediate on the device resolves this issue.

As I understand it (but do correct me if I'm wrong), the methods you point to cannot be used from an extension, but are for other situations. The first is for enterprise situations (which does not apply to us, we don't own the devices that I'd be writing this extension for), the second is for network administrators (which also doesn't apply to us, we don't know where this will be ran).

So that leaves manually installing the intermediate certificate. While that is an option, it would have to be done for nearly every certificate (by chance two people in the same household might end up being under the same CA, but that is rather unlikely). Also, people would have to get their certificate somehow, and would need to know how to do it.

We could create a page that pops up at extension installation time, I suppose, which allows a user to download the intermediate certificate and which guides them through installing it correctly into ChromeOS, but that would then need to be repeated for every card that people would want to use; they would need to remember that there is this manual installation process, which I suspect most people will not, so this is a usability nightmare and therefore a support nightmare.

If weighing that option against not supporting ChromeOS at all, I think the latter option wins for us.