New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 96 users

Issue metadata

Status: Fixed
Closed: Dec 2017
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature

Blocked on:
issue 792468

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 721739: Provide ability to handle certificate errors in Chromedriver/Selenium for headless

Reported by, May 12 2017

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.


Did this work before? N/A 

Chrome version: <Copy from: 'about:version'>  Channel: dev
OS Version: 
Flash Version:
Showing comments 27 - 126 of 126 Older

Comment 27 by, Aug 15 2017

Tested Chrome 62 with chromedriver and it does not work. Waiting for next release.

Comment 28 by, Aug 17 2017

The latest google-chrome-unstable v62 with `--allow-insecure-localhost` under Ubuntu 17.04 works for me.

I'm using nodejs with selenium:

const options = {
  args: [
    '--allow-insecure-localhost', //
    '--headless', //
    // '--remote-debugging-port=9222',  // will conflict with webdriver
  ],  //  issue #26  for run inside docker
  binary: '/opt/google/chrome-unstable/chrome',
const customChrome = Capabilities
                     .set('chromeOptions', options)

Comment 29 by, Aug 24 2017

For #23, any news for supporting "acceptInsecureCerts"?  Thanks!

Comment 30 by, Aug 28 2017

+1 on "acceptInsecureCerts", that would be perfect. Thanks!

Comment 31 by, Sep 1 2017

another +1 on "acceptInsecureCerts"

Comment 32 by, Sep 5 2017

any news regarding "acceptInsecureCerts" ?

Comment 33 by, Sep 5 2017

It will likely be a few more weeks before I can work on this. In the meantime, if anyone else have time available please feel free to grab this.

Comment 34 by, Sep 22 2017

Hi Team,

When can we expect new version which will cover this issue?

Comment 35 by, Sep 26 2017

+1 on "acceptInsecureCerts", any news for supporting this?  Thanks!

Comment 36 by, Sep 27 2017

+1 on "acceptInsecureCerts" This option is in high need for implementation. Thanks!

Comment 37 by, Sep 28 2017

+1 on "acceptInsecureCerts" This option is in high need.

Comment 38 by, Sep 28 2017

Selenium 3.6.0 was released a few days ago, and they (silently) dropped support for PhantomJS. This fix cannot come soon enough, please!

Comment 39 by, Oct 2 2017

+1 on "acceptInsecureCerts"  This option is in high need.

Comment 40 by, Oct 3 2017

when this issue will be closed..

Comment 41 by, Oct 9 2017

Same issue here, cannot test an internal webapps with a self signed certificate. Looking forward for "acceptInsecureCerts"...

Comment 42 by, Oct 10 2017

Really annoying that this feature is not available. +1 for acceptInsecureCerts

Comment 43 by, Oct 20 2017

+1 on "acceptInsecureCerts". Really need this.

Comment 44 by, Oct 22 2017

Anyone tried with chrome 62 version in Windows.
Is it working..
Please let me know.

Comment 45 by, Oct 24 2017

+1 for "acceptInsecureCerts".  Critical for headless selenium with self-signed certs. Killer use case for chrome headless.

Comment 46 by, Nov 8 2017

+1 for "acceptInsecureCerts" from me as well.

Comment 47 by, Nov 13 2017

+1 here too - this is absolutely vital for chrome headless to fully replace PhantomJS for me.

Comment 48 by, Nov 13 2017

Tested on Windows 7 with Chrome 62 and Chromedriver 2.33, works with the flag --allow-insecure-localhost

Comment 49 by, Nov 13 2017

@nick I believe this only applies to localhost. Does not help if the headless browser is on a different machine. I'm not on windows so please correct if I am wrong...

Comment 50 by, Nov 14 2017

I tried today with chrome driver 2.33 and chrome 62.
Still it is not working..

Comment 51 by, Nov 15 2017

Yes, sorry this will only work on localhost.

Comment 52 by, Nov 21 2017

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.

Comment 53 Deleted

Comment 54 by, Nov 23 2017

 Issue 786851  has been merged into this issue.

Comment 55 by, Nov 23 2017

 Issue 786851  is happen in Windows 7.
So the solution should include OS = Windows.


Comment 56 by, Nov 26 2017

'--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.

Comment 57 by, Nov 28 2017

Is there any update on this issue or estimate as to if/when it will be addressed?  Is there any suggestion as to a workaround that may be used in a headless CI environment?

Comment 58 by, Nov 29 2017

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.

Comment 59 by, Nov 29 2017

might aswell continue using xvfb than using that workaround. We need headless to support insecure hosts, otherwise there is no point in switching to headless.

Comment 60 by, Nov 29 2017

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.

Comment 61 by, Dec 4 2017

+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.

Comment 62 by, Dec 4 2017

+1 please implement an acceptInsecureCerts flag asap.

Comment 63 by, Dec 5 2017

+1 for this, without this we can't use this feature

Comment 64 Deleted

Comment 65 by, Dec 6 2017

+1 please implement acceptInsecureCerts flag.

Comment 66 by, Dec 6 2017

Status: Started (was: Available)
I'll take a stab at adding support for the acceptInsecureCerts capability to ChromeDriver.

Comment 67 by, Dec 6 2017

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.

Comment 68 by, Dec 6 2017

Blockedon: 792468

Comment 69 by, Dec 7 2017

+1, please implement an acceptInsecureCerts flag

Comment 70 by, Dec 7 2017

+1 please implement acceptInsecureCerts flag.

Comment 71 by, Dec 7 2017

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?

Comment 72 by, Dec 7 2017

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?

Comment 73 by, Dec 7 2017

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

Comment 74 by, Dec 8 2017

That works for me!

Comment 75 by, Dec 8 2017

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.

Comment 76 by, Dec 8 2017

#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

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.

Comment 77 by, Dec 8 2017

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.

Comment 78 by, Dec 8 2017

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" <> escreveu:

Comment 79 by, Dec 8 2017

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.

Comment 80 by, Dec 11 2017

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.

Comment 81 by, Dec 11 2017

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.

Comment 82 by, Dec 11 2017

DevTools patch is out on for those following along.

Comment 83 by, Dec 12 2017

Looking forward to being able to see this work.  Eric, it looks like we should be using CertificateErrorOverrideMode=ignore-all if we want to turn the cert errors off?

Comment 84 by, Dec 12 2017

#83: Correct, a ChromeDriver patch that hooks it up to acceptInsecureCerts is out on

Comment 85 by, Dec 12 2017

May i know when this patch is available for everyone? Thanks Prathima

Comment 86 by, Dec 18 2017

Please tell me, how this will work with puppeteer?

Comment 88 by, Dec 20 2017

Project Member
The following revision refers to this bug:

commit 790e30ff7ade211a00e051792d687330f90de789
Author: Eric Seckler <>
Date: Wed Dec 20 11:08:26 2017

devtools: Add setIgnoreCertificateErrors, also on browser target.

All known clients use certificate error overrides to ignore all
certificates, so we're planning to replace it with a simpler
"ignore all cert errors" mode instead. This patch deprecates the old
override command in favor of a new setIgnoreCertificateErrors command.

It also exposes the Security domain on the browser target to
facilitate applying this override globally for the whole browser.

Bug:  721739 ,  792468 
Change-Id: I89bd929247877f43abac7c31a420d0756a8fdf89
Commit-Queue: Eric Seckler <>
Reviewed-by: Dmitry Gozman <>
Cr-Commit-Position: refs/heads/master@{#525304}

Comment 90 by, Dec 20 2017

#89: In that case, please raise a bug with puppeteer. There seems to be one issue referencing ignoreHTTPSErrors:

Comment 91 by, Dec 20 2017

Project Member
The following revision refers to this bug:

commit 816f01bc8b6a76716b4bd80394d4c4f737211bbc
Author: Eric Seckler <>
Date: Wed Dec 20 13:27:57 2017

[ChromeDriver] Add acceptInsecureCerts capability for headless.

Implemented using a new DevTools method to override certificate
error handling browser-wide. This allows ignoring certificate
errors in headless mode, too.

Bug:  721739 
Change-Id: I99d1962147ae638ef83dad5cad6fe1311e7c98b1
Commit-Queue: Eric Seckler <>
Reviewed-by: John Chen <>
Cr-Commit-Position: refs/heads/master@{#525318}

Comment 92 by, Dec 20 2017

Status: Fixed (was: Started)
The commit in #91 adds support for acceptInsecureCerts [1] to ChromeDriver, starting from Chrome M65.


Comment 93 by, Dec 21 2017

Labels: ChromeDriver-2.35

Comment 94 by, Dec 22 2017

Hi ,i am also unable to open intranet site in headless mode .I m using ChromeDriver 2.33 and chrome 62. Selenium 3.4.5.
Could you please let me know from where I can get above fix chromedriver 2.35 ?

Comment 95 by, Dec 22 2017

Chrome 65, as well as chromedriver 2.35, is not yet released. We need to wait while it will be released. Or as an option, you can build chromium 65 and chromedriver 2.35 from sources

Comment 96 by, Jan 11 2018

chromedriver 2.35 now released. Reading through the thread it should just be a case of adding a capability option of:

acceptInsecureCerts, true

Unless I am mistaken?

Comment 97 by, Jan 11 2018

#96: Correct, provided you run against a recent M65 build. If that doesn't work for you, please file another bug against ChromeDriver.

Comment 98 by, Jan 16 2018

How do you do this in python when using headless mode for chromedriver?
chrome_options = Options()

Comment 99 by, Jan 18 2018

acceptInsecureCerts, true is working for Mac Chrome but not working for Windows Chrome. Is this a bug or I am missing some thing.

Comment 100 by, Jan 24 2018

I can't make acceptInsecureCerts work, this is my configuration configuration: 
const options = new ChromeOptions();
            var str = size.replace("x",",");

Can someone share there config please ?

Comment 101 Deleted

Comment 102 by, Jan 24 2018

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")

        DesiredCapabilities caps =
        caps.setCapability(ChromeOptions.CAPABILITY, options)
        caps.setCapability("acceptInsecureCerts", true)
        WebDriver driver = new ChromeDriver(caps)

Hope this helps,

Comment 103 by, Jan 25 2018

Works like a charm!

Thanks Roman, you are my God!


Comment 104 by, Jan 26 2018

Does the accept acceptInsecureCerts flag include net::ERR_CERT_AUTHORITY_INVALID errors?

Comment 105 by, Jan 29 2018

How acceptInsecureCerts call should look like with Python?

Comment 106 by, Jan 30 2018

I finally made python script work headless with unsecure ssl on Linux 

Google Chrome: google-chrome-unstable-65.0.3325.31-1.x86_64
Web Driver: 2.35.528139
Selenium: 3.8.1
Python: 2.7.13
OS: SUSE Linux Enterprise Server 12 SP2  (x86_64)

from selenium import webdriver
from import Options
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities

options = webdriver.ChromeOptions()
options.binary_location = '/usr/bin/google-chrome-unstable'

capabilities = DesiredCapabilities.CHROME.copy()
capabilities['acceptSslCerts'] = True
capabilities['acceptInsecureCerts'] = True
driver = webdriver.Chrome(chrome_options=options, desired_capabilities=capabilities)

Comment 107 by, Jan 31 2018

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

Comment 108 by, Jan 31 2018

Also, just realized, this is only happening when I'm using the proxy-server option. Without it it's working fine !

Comment 109 by, Feb 23 2018

Still not working with --headless for me, Chrome 66 & chromedriver 2.35.
Only works without it.

Comment 110 by, Mar 1 2018

I still did not manage to make this work.
I am currently on Chromium 65.0.3298.3 for Ubuntu 16.04, ChromeDriver 2.35.528139.
Trying to make this work in Ruby:

Capybara.register_driver :headless_chromium do |app|
      capabilities =
        acceptInsecureCerts: true,
        chromeOptions: {
          'binary' => '/usr/bin/chromium-browser',
          'args' => ['--headless', '--disable-web-security', '--incognito',
                     '--no-sandbox', '--disable-gpu', '--window-size=1920,1080']
        browser: :chrome,
        desired_capabilities: capabilities

Anyone? Any ideas what I am doing wrong?

Comment 111 by, Mar 1 2018

Move acceptInsecureCerts: true into the chromeOptions object.

Comment 112 by, Mar 1 2018

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?

Comment 113 by, Mar 1 2018

Nope, getting the same thing.

Comment 114 by, Mar 1 2018

Are you sure that

/usr/bin/chromium-browser -version

is 65.0.3298.3? is version 64.0.3282.167-0ubuntu0.16.04.1

Comment 115 Deleted

Comment 116 by, Mar 1 2018

Yes, doing /usr/bin/chromium-browser -version, echoes Chromium 65.0.3298.3 Ubuntu 16.04
Also, I used these commands on installing the Beta version:

Comment 117 by, Mar 2 2018


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 =
        acceptInsecureCerts: true,
        binary: '/usr/bin/chromium-browser',
        chromeOptions: {
          'args' => ['--headless', '--disable-web-security', '--incognito',
                     '--no-sandbox', '--disable-gpu', '--window-size=1920,1080']
        browser: :chrome,
        desired_capabilities: capabilities

Comment 118 Deleted

Comment 119 Deleted

Comment 120 by, May 24 2018

now we can use mitmproxy and chrome headless
from selenium import webdriver
from pyvirtualdisplay import Display
from import Options
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities

CHROME_DRIVER_PATH = r'/usr/bin/chromedriver' 
PROXY = ""
options = webdriver.ChromeOptions()

desired_capabilities = options.to_capabilities()
desired_capabilities['acceptSslCerts'] = True
desired_capabilities['acceptInsecureCerts'] = True
desired_capabilities['proxy'] = {
    "httpProxy": PROXY,
    "ftpProxy": PROXY,
    "sslProxy": PROXY,
    "noProxy": None,
    "proxyType": "MANUAL",
    "class": "org.openqa.selenium.Proxy",
    "autodetect": False,
driver = webdriver.Chrome(
    desired_capabilities = desired_capabilities,

for i in range(1):
    contant = driver.page_source

mitmdump -p 8080

Comment 121 by, Jun 19 2018

#120 worked for me.

The options and desired_capabilities worked. I left out the proxy arg for desired_capabilities.

Comment 122 by, Sep 17

   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.


Comment 123 by, Nov 1

Worked fine for me:

def chrome_options(chrome_options, pytestconfig):
    if pytestconfig.getoption('headless'):
        chrome_options.set_capability("acceptInsecureCerts", True)

    return chrome_options

Session info: headless chrome=70.0.3538.77
Driver info: chromedriver=2.35.528139
platform: Linux 4.15.0-38-generic x86_64

Comment 124 by, Nov 20

#120 worked for me too with browsermobproxy

session info: headless chrome Version 70.0.3538.102
Driver info: chromedriver=2.43
platform: Linux 18.04

Comment 125 by, Jan 24

Components: Test>WebDriver

Comment 126 by, Jan 24

Components: -Tests>WebDriver
Showing comments 27 - 126 of 126 Older

Sign in to add a comment