New issue
Advanced search Search tips
Starred by 28 users

Issue metadata

Status: Fixed
Closed: Apr 2018
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Sign in to add a comment

Issue 757181: Headless/DevTools doesn't handle net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED error

Reported by, Aug 19 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.39 Safari/537.36

Steps to reproduce the problem:
1. /opt/google/chrome-beta/chrome --headless --dump-dom

What is the expected behavior?
Chrome fetches the page's content.

What went wrong?
Page content not downloaded/dumped with headless mode, while chrome works as expected without headless mode.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 61.0.3163.39  Channel: beta
OS Version: Gentoo Linux
Flash Version: 

/opt/google/chrome-beta/chrome --headless --dump-dom  -enable-logging --v=1

[0819/] ZygoteMain: initializing 0 fork delegates
[0819/] Available number of cores: 8
[0819/] All gsettings tests OK. Will get proxy config from gsettings.
[0819/] Obtained proxy settings from GSETTINGS
[0819/] Could not get the download directory.
[0819/] Activated seccomp-bpf sandbox for process type: renderer.
[0819/] Activated seccomp-bpf sandbox for process type: gpu-process.
[0819/] After loading Root Certs, loaded==false: NSS error code: -8018
[0819/] Adding CT log: Google 'Aviator' log
[0819/] Adding CT log: Google 'Icarus' log
[0819/] Adding CT log: Google 'Pilot' log
[0819/] Adding CT log: Google 'Rocketeer' log
[0819/] Adding CT log: Google 'Skydiver' log
[0819/] Adding CT log: DigiCert Log Server
[0819/] Adding CT log: DigiCert Log Server 2
[0819/] Adding CT log: Symantec log
[0819/] Adding CT log: Symantec 'Vega' log
[0819/] Adding CT log: Symantec 'Sirius' log
[0819/] Adding CT log: WoSign log
[0819/] Adding CT log: Venafi Gen2 CT log
[0819/] Adding CT log: CNNIC CT log
[0819/] Adding CT log: StartCom log
[0819/] Adding CT log: Comodo 'Sabre' CT log
[0819/] Adding CT log: Comodo 'Mammoth' CT log
[0819/] Adding CT log: Izenpe log
[0819/] Adding CT log: Venafi log
[0819/] Adding CT log: Certly.IO log
[0819/] PAC support disabled because there is no system implementation
[0819/] GL_OES_packed_depth_stencil supported.
[0819/] GL_OES_packed_depth_stencil supported.
[0819/] GL_OES_packed_depth_stencil supported.
[0819/] GL_OES_packed_depth_stencil supported.
[0819/] GL_OES_packed_depth_stencil supported.
[0819/] Failed Provisional Load:, error_code: -110, error_description: , showing_repost_interstitial: 0, frame_id: 2
[0819/] ~SettingGetterImplGSettings: releasing gsettings client
[0819/] SandboxIPCHandler stopping.

Does the error code -110 refer to ? Why is it working without headless mode?

Comment 1 by, Aug 19 2017

Could it be that chrome has issues with servers sending a "certificate request" during the ssl handshake when running in headless mode?

Comment 2 by, Aug 21 2017

Components: Internals>Headless
Thanks for the report!

Could you verify if this work for Canary? We've recently fixed an issue with NSS initialization

Comment 3 by, Aug 21 2017

I have built chromium from source yesterday, same result. I guess that's recent enough?

Comment 4 by, Aug 21 2017

"good": no --headless
"bad" : --headless
180 KB View Download
226 KB View Download

Comment 5 by, Aug 21 2017

Thanks for checking. 

I cannot reproduce on my build, both canary and stable work as expected. 

I think your guess is right, maybe there's an issue with the SSL certificate and your network and this is handled differently on non-headless (by default non-headless will ignore some errors), but I don't know how to reproduce it. 

You could try and use devtools to handle the certificate error, and see if ignoring it works:

Comment 6 by, Aug 21 2017

Thanks for the advice! Are you saying that all your chrome builds give you the html of the page if you run
chrome --headless --dump-dom

I launched my chromium build with
chrome --remote-debugging-port=9222 --headless
and ran the attached Node.js program. I ended up with the attached empty screenshot. For other pages the screenshot was not empty.

Comment 7 by, Aug 21 2017

1.5 KB View Download
2.7 KB View Download

Comment 8 by, Aug 21 2017

Thanks for the script!

Yes, the site works for me. 
I've noticed that you mention a proxy server in your script. Note that your non-headless version may be picking up the proxy configuration from your user-data-dir. This is *not* supported in headless mode (and it actually uses a different user profile when running). 

Maybe try and setup the proxy configuration using the --proxy-server flag:

Comment 9 by, Aug 21 2017

No I don't use any proxy server, I just quickly picked this script up at because it seems to do the "handleCertificateError" you mentioned and I didn't remove the comments from the original script.

Comment 10 by, Aug 21 2017

I guess just handles invalid server certificates. It doesn't seem to help change chrome's behaviour in case the server sends a client certificate request.

Comment 11 by, Aug 22 2017

I'm not sure then why it could be happening. I don't get any certificate error and the page renders just fine. 

You could add a console.log step in your handle certificate function to see if you are actually getting a cert error, or if there's other issue.

Comment 12 by, Aug 22 2017

I have no idea why this only happens to me and only in headless mode. I added a console.log in the Security.certificateError callback, nothing was logged. This is all I get in wireshark when visiting the page:
Screenshot from 2017-08-22 02-45-49.png
120 KB View Download

Comment 13 by, Aug 22 2017

I've tried headless firefox in the meantime without issues. I am usually using and selenium to communicate with the browsers.

Comment 14 by, Aug 23 2017

Labels: TE-NeedsTriageHelp

Comment 15 by, Aug 23 2017

I have the same issue as mentioned above, and I used the command like this "./headless_shell --no-sandbox --disable-gpu --enable-logging --v=1".

[0823/181016.905454:VERBOSE1:MemoryCache.cpp(166)] Evicting resource 0xb37aeff2f10
for "" from cache
[0823/] Failed Provisional Load: https
://, error_code: -110, error_description: , showing_repost_inte
rstitial: 0, frame_id: 2
[0823/] Navigation finishe
d at (smoothed) timestamp 13147956616933442

My headless_shell version is `60.0.3090.0`. When I compiled version 62, I had the same issue. And on my ubuntu, using the command "./chrome --headless --disable-gpu", the error occurred again.

Comment 16 by, Aug 26 2017

I am able to reproduce the same problem with as well.

Comment 17 by, Aug 27 2017

Summary: Headless doesn't handle net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED error (was: headless mode fails for

Comment 18 by, Aug 27 2017

 Issue 758452  has been merged into this issue.

Comment 19 by, Aug 28 2017

Using a mitm proxy solved this problem.

Comment 20 by, Aug 28 2017

Sounds like you're hiding it by letting the proxy handle the problematic ssl handshake.

Comment 21 by, Aug 30 2017

Status: Available (was: Unconfirmed)

Comment 22 by, Aug 31 2017

I know this isn't a self-contained repro, but the following illustrates the issue (and that server is not scheduled to shut down anytime soon)

'use strict';

const puppeteer = require('puppeteer');

(async () => {
    // NB: ignoreHTTPSErrors gets us only so far. It still trips over the
    // client certificates in our certs (even when they're optional), or
    // perhaps something else:
    const browser = await puppeteer.launch({ignoreHTTPSErrors: true});
    const page = await browser.newPage();
    await page.goto('', {waitUntil: 'networkidle'});
    await page.pdf({path: 'out.pdf', format: 'A4'});


Perhaps it helps, though it doesn't print the error message.
This does though: and you get `{ message: 'net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED' }` when trying the above URL.

Comment 23 by, Sep 24 2017

Will be very useful if this is fixed. We use the headless mode extensively and are affected by this issues for some of our major use cases.

Comment 24 by, Nov 27 2017

Depending on this issue as well. Waiting for a fix here :)

Comment 25 by, Nov 27 2017


Comment 26 by, Dec 5 2017

Did anyone find a workaround for this? I don't actually need (or even want) the client-side SSL certificate provisioning to succeed, I just can't let the fail on the ERR_SSL_CLIENT_AUTH_CERT_NEEDED error. I tried to generate a self-signed certificate with a CN and saN of the service (OpenShift in my case) to connect to, convert it to PKCS12 [1], and import it into the NSS DB so that chromium should be able to see it [2]:

❱❱❱ certutil -d sql:.pki/nssdb/ -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI - test                                             u,u,u

But this doesn't make any apparent difference, Chromium headless still refuses to connect (same error).


Comment 27 by, Dec 6 2017

Status: Assigned (was: Available)

Comment 28 by, Dec 18 2017

 Issue 754210  has been merged into this issue.

Comment 29 by, Dec 18 2017

Components: Platform>DevTools
Summary: Headless/DevTools doesn't handle net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED error (was: Headless doesn't handle net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED error)

Comment 30 by, Jan 5 2018

The same problem is reported in puppeteer

Comment 31 by, Mar 4 2018

Owner: ----
Status: Available (was: Assigned)

Comment 32 by, Apr 4 2018

Is there any update on this? It is a pretty significant issue I would say.
Researching this bug I found many discussions where people ended up switching to Firefox.

Comment 33 by, Apr 4 2018

Status: Assigned (was: Available)
Andrey, mind taking a look?

Comment 34 by, Apr 5 2018

Status: Started (was: Assigned)

Comment 35 by, Apr 5 2018

Project Member
The following revision refers to this bug:

commit c8f0691b18dc5d941d5b6b3c67a483da02400670
Author: Andrey Kosyakov <>
Date: Thu Apr 05 15:05:12 2018

Headless: do not cancel requests if server wants a certificate

... just tell content to proceed with no certificate instead
of cancelling the request.

Bug:  757181 
Change-Id: Ib7db0d5bbbdf73dfd3bad4fb5827519eb8c0dbbd
Reviewed-by: Alex Clarke <>
Commit-Queue: Andrey Kosyakov <>
Cr-Commit-Position: refs/heads/master@{#548422}

Comment 36 by, Apr 5 2018

Status: Fixed (was: Started)

Comment 37 by, Apr 5 2018

Wow this was quick! Thanks!
When should we expect a fixed build that we could use?

Comment 38 by, Apr 5 2018

This really depends on what channel you are. This site lets you track what releases have certain commit:

Comment 39 by, Aug 19

Commit c8f0691b... initially landed in 67.0.3390.0

running with chrome 68.0.3440.106 problem persists.
any idea why?

Comment 40 by, Nov 14

this problem persists with macos version. 70.0.3538.77

Comment 41 by, Nov 19

I am still having issues on macos version 70.0.3538.77 as well. It fails to attach client certificate stored in Keychain on headless mode but the request works fine with headless-mode disabled. Should I submit a separate bug report for this?

Sign in to add a comment