chrome.sockets.tcp API doesn't check for locally installed certificates
Reported by
kurtis.s...@hp.com,
Dec 13 2017
|
||||
Issue description
Chrome Version: 63
Chrome OS Version: 10032
Chrome OS Platform: Chromebook Pixel
Steps To Reproduce:
(1) Create self-signed certificate
(2) Install the cert on the chromebook and a server
(3) In a packaged app, create a chrome.sockets.tcp socket
(4) Connect the socket to the server
(5) Secure the socket
Expected Result: The socket is secured with TLS encryption. Data can be sent to the server.
Actual Result: net::ERR_CERT_AUTHORITY_INVALID
How frequently does this problem reproduce?
Always
What is the impact to the user, and is there a workaround? If so, what is
it?
No workaround. The connection cannot be created.
Please provide any additional information below. Attach a screen shot or
log if possible.
Connecting to the server from the browser works just fine, but it seems like the sockets api doesn't check installed certificates when securing the socket.
The sockets api should check against locally installed certificates when securing a socket. It would also be nice if the api allowed some way for the user to accept and/or ignore this error, like the browser does when connecting to an non-trusted server.
Here is some sample code:
var mySocket;
chrome.sockets.tcp.create(function(createInfo){
mySocket = createInfo.socketId;
chrome.sockets.tcp.setPaused(mySocket, true);
chrome.sockets.tcp.connect(mySocket, serveraddress, 443, function(result) {
chrome.sockets.tcp.secure(mySocket, function(result){
//chrome.runtime.lastError shows a net::ERR_CERT_AUTHORITY_INVALID exception here
chrome.sockets.tcp.setPaused(mySocket, false);
});
});
});
,
Dec 14 2017
Note: This was not about client certificates. This is about ChromeOS installed enterprise certificates and how they are propagated. The sockets API tries to use the URLRequestContext of the BrowserContext's StoragePartition, which should be getting its CertVerifier, which should be the PolicyCertVerifier. Pavol, Maksim: Sounds like y'all might be better placed with knowing how to test/confirm/triage?
,
Dec 14 2017
Was the certificate installed manually via chrome://settings/certificate, or it was pushed via the OpenNetworkConfiguration admin policy? Also, was it a server certificate or an authority certificate?
,
Dec 14 2017
Oh, it's also about packaged apps - which may be using a different profile, I'm not sure how they're instantiated - they may be using a different config and bypassing ONC
,
Dec 14 2017
Could you please explain how you install the certificate, and if you can connect to the server from a browser? Also, is this about "Chrome Apps" or is "packaged apps" something else? IIUC regular "Chrome Apps" should live in a StoragePartition tied to the main BrowserContext, with a Site URL returned by GetSiteForExtensionId[1]. This would mean that their URLRequestContext is created through calling CreateRequestContextForStoragePartition on the embedding Profile, which ends up in ProfileImplIOData::InitializeAppRequestContext, which should re-use the CertVerifier from the Profile's main request context. [1] https://cs.chromium.org/chromium/src/extensions/browser/extension_util.h?l=40&gs=kythe%253A%252F%252Fchromium%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fextensions%252Fbrowser%252Fextension_util.h%2523EgiVuPqC0m1T8F9TZYhm4BfgjfdMi4mpt8tKq62aEhY%25253D&gsn=GetSiteForExtensionId&ct=xref_usages
,
Dec 15 2017
The certificate was installed via chrome://settings/certificate It was not from a Certificate Authority. This is for a Chrome App. According to the linked cr 557087, this, or a simliar issue, was talked about but never worked on.
,
Dec 15 2017
Issue 557087 is about client certificates, but your original report stated it's about ERR_CERT_AUTHORITY_INVALID errors. Can you include a NetLog, as per https://dev.chromium.org/for-testers/providing-network-details
,
Dec 21 2017
I also have the same problem on Linux, only workaround is to use firefox or another browser. I have configured the proxy to serve unecrypted for local development, and some how the problem persists.
,
Jan 12 2018
@kurtis...: Any update on the netlog requested in c#7?
,
Jan 12 2018
@rdsmith Sorry, I haven't had a chance to capture logs. I'll update once I do.
,
Feb 3 2018
kurtis.schlepp@, were you able to capture the neg log requested in comment #7?
,
Feb 21 2018
Closing because of inactivity. Please reopen if you can provide the requested information. |
||||
►
Sign in to add a comment |
||||
Comment 1 by pauljensen@chromium.org
, Dec 14 2017Components: Internals>Network>SSL
Status: WontFix (was: Unconfirmed)