Issue description

UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Steps to reproduce the problem:
Use Chromedriver as a Selenium back-end.
What is the expected behavior?
What went wrong?
Currently there's no way to configure headless Chromium options that are exposed via the devtools API[1] from Selenium/Chromedriver -- or there are docs missing.
Certain security related options that used to be controlled via CLI switches in the UI version of Chromium (like --ignore-certificate-errors) are silently ignored and can only be set via devtools, although this is either currently impossible or not documented.
[1] https://chromedevtools.github.io/devtools-protocol/tot/Security/
Did this work before? N/A
Chrome version: <Copy from: 'about:version'> Channel: dev
OS Version:
Flash Version:

Is there any updates on this item? I have encountered this issue when attempting to execute Selenium integration tests as part of a CI build. Upgrading to Selenium WebDriver v3.7.1 appears to have exposed a new method on the ChromeOptions class (#setAcceptInsecureCerts(boolean acceptInsecureCerts)), but it doesn't appear to have any impact when running with chromedriver 2.33.0 and chrome 62.

'--disable-web-security', '--allow-running-insecure-content' support needed in HEADLESS mode.
I am using headless chrome via puppeteer API, I am launching chrome with following flags '--disable-web-security', '--allow-running-insecure-content'. When I use real chrome(headfull mode), it works perfect with some warnings in console(which is fine).
But when I enable headless mode, all my tests are failing. Please help.

Workaround suggestion:
Use ssh to set up a local port forwarding from the machine running Chrome to the target webserver. Then start Chrome with '--allow-insecure-localhost' and run the tests against the local port.

I'm working on a change for this. About 70% of the code was done. However I've been busy with black friday/cyber monday. I'll target sometime in December. But please don't let that stop anyone else from working on a CL, since this is far from my top priority.

+1 to this flag. We have a lot of different systems, some of which are not running on localhost, that use self-signed certificates. Without insecure flag, as phantomjs and chrome (non-headless), it will be difficult to migrate.

Turns out that the approach outlined in #18 doesn't work for target=_blank navigations, because it seems may not connect to the new window's DevTools target (and therefore send Security.enable) quickly enough.
I think we'll probably need a way to override certificate errors globally from the browser target.

I'm afraid this requires more work in chromedriver than I expected. Here's why:
To ensure that the acceptInsecureCerts mode is applied globally (for existing and new targets), we would need to override and handle certificateError events on the browser-target DevTools client, after bug 792468 is fixed.
However, ChromeDriver internally often blocks while polling a single target's DevTools client, e.g. waiting for a response to a command. Because certificateError events may occur on the browser DevTools client while ChromeDriver is blocked on another client, say during a navigation, it's possible that the other client gets stuck because the navigation depends on handling of the certificateError event on the browser client.
Thus, ChromeDriver first needs to implement multi-plexing over other devtools clients while waiting for command responses, so that the certificateError event can be handled concurrently on the browser client.
@johnchen, any idea if that's feasible?

ChromeDriver was designed with the assumption that the automation app works on one window at a time. There might be other windows or tabs around, but generally it only communicates with one window at a time. Events from the other tabs are queued by the network, and are not actively monitored by the code. It's certainly possible to change the design, but it's likely to be a big project.
How about this: the app needs to switch to a window in order to handle certificate errors in that window. Navigation in non-active windows might be blocked by certificate errors, but the next time app switches to that window, any pending certificate errors are handled, and the navigation continues. Would that be good enough for most people?

That would work for my scenario and I suppose it would cover the majority of use cases. The deficiency that you highlighted could probably be considered as a corner case for now. Basically this Cert scenario is killing everybody who just wants to use a non-local test server, which is a very big subset of Headless Chrome users and wannabes.
Kudos to you guys for all the thought you are putting into this. Thanks & good luck

That should work. The only exception I can see is, as johnchen said, having multiple windows. And even then, it would only be a problem if the two windows needed to communicate / rely on each other and the non-active window had a certificate error. That seems unlikely because if the two windows are interdependent they are probably on the same domain and so the certificate error would already have been accepted on the first window and therefore shouldn't come up on the second, right? Seems like a very rare edge case that could be gotten around by the person using the chromedriver.

#72: This doesn't work for navigations that happen before ChromeDriver connects to a new target as I mentioned in #67. That is, the certificate error event might not be sent to DevTools because it can happen *before* the Security domain and the override is enabled. I've got a WIP patch here with a test that illustrates this (testNavigateNewWindow in run_py_tests.py):
https://crrev.com/c/810790
One way around this would be to override and handle these errors globally on the browser target. An alternative might be to add a way to start new targets/windows in a "paused" state to DevTools, so that ChromeDriver (and alike) can perform setup operations before resuming their loading. That's a larger feature request though (see discussion in bug 792468 ).
#75: Certificate error overriding via DevTools doesn't remember past decisions AFAICT, so you'd see another error in the second window, even if it's the same domain.

The issue with sending certificate error events to the browser target is ChromeDriver would need to monitor the browser target while managing a navigation on a window. So far as I know this isn't easy to do, though I could be wrong.
I think the current design is way too complicated for a simple requirement. --ignore-certificate-errors would have been a much simpler solution, but it was mentioned earlier that this option is going away. Would it be possible to add a DevTools command that is equivalent to --ignore-certificate-errors? The new command could set a global flag, and then all future certificate errors are automatically handled on all windows without raising any event.

Switch --allow-insecure-localhost works as intended, but only for
localhost. Would it be possible to change what's in there for a broader
scope (any host)?
Em 8 de dez de 2017 2:55 PM, "johnc… via monorail" <
monorail+v2.3997543311@chromium.org> escreveu:

I would like to encourage the developers to focus on the primary use-case for this: running tests in some CI environment. I think having a solution that is global (all tabs, always) is perfectly fine, certainly for now. No existing functionality would be broken, and therefore no existing users would be impacted. Just get the primary use-case to work first.
Just my two bits. Thanks.

What I don't understand about this issue is why is this being fixed in ChromeDriver?
In normal chrome this works perfectly without any changes (not even configuration) to ChromeDriver. Why is this so much different in chrome headless? I was under the impression, that chrome headless is just chrome without the UI.

Headless chrome is a separate content embedder, and doesn't support --ignore-certificate-errors. We are inclined not to add support for this flag because we were told that there are plans to remove it from chromium altogether. Instead, both headless and desktop support a DevTools-controlled override that replaces the command line flag. Sadly, that override isn't currently compatible with ChromeDriver.
I think adding a simpler global DevTools-controlled override should be possible. I'll prepare a patch and will see what DevTools owners say.

You need to make sure following:
1) You have latest version of chromedriver - 2.35
2) You need 65+ version of Chrome. E.g. install Canary which is 66 version now. In your tests you need to point to the canary executable.
Here is example of working config:
ChromeOptions options = new ChromeOptions()
options.setBinary("C:\\Users\\Administrator\\AppData\\Local\\Google\\Chrome SxS\\Application\\chrome.exe")
options.addArguments("window-size=1920,1080")
options.addArguments("headless")
DesiredCapabilities caps = DesiredCapabilities.chrome()
caps.setCapability(ChromeOptions.CAPABILITY, options)
caps.setCapability("acceptInsecureCerts", true)
WebDriver driver = new ChromeDriver(caps)
Hope this helps,
Roman

Unfortunately this is not working for me.
I'm testing with Chrome dev channel (65.0.3325.31)
Without AcceptInsecureCerts, I get a nice certificate invalid error, no problem.
When I set the capability on, I don't see any error, just requests pending indefinitely.
I'm checking by using the remote debugger.
Any idea ? Thanks

Thank you for the reply.
If I try something like this I get and error like: "from unknown error: unrecognized chrome option: acceptInsecureCerts" :(
If I put it as argument. it will still not bypass SSL certs error.
Maybe I am not writing it well?

Hi,
Managed to resolve this.
As it turned out I had 2 versions on Chromium Browser installed 64 and 65.
I completely removed chromium-browser from Ubuntu, and then only installed 65 (after that 66), and it works great.
"acceptInsecureCerts: true" works perfectly.
Thank you for the help getting me unblocked !
Here is my setup if someone else works with Ruby + Capybara testing and has the same problem:
Capybara.register_driver :headless_chromium do |app|
capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
acceptInsecureCerts: true,
binary: '/usr/bin/chromium-browser',
chromeOptions: {
'args' => ['--headless', '--disable-web-security', '--incognito',
'--no-sandbox', '--disable-gpu', '--window-size=1920,1080']
})
Capybara::Selenium::Driver.new(
app,
browser: :chrome,
desired_capabilities: capabilities
)
end

Hi
Any Idea does this fix is available in chromium browser package 65.0.3325.181 of ubuntu 14.04 (trusty)?? For me It doesn't work for chromium browser opened in headless mode with chrome driver 37 setting acceptInsecureCerts.
Your quick help is much appreciated.
Thanks.