New issue
Advanced search Search tips

Issue 757181 link

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

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?
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
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
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.
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.
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.
Summary: Headless doesn't handle net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED error (was: headless mode fails for
 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.
Status: Available (was: Unconfirmed)
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.
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.
Depending on this issue as well. Waiting for a fix here :)
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).

Status: Assigned (was: Available)
 Issue 754210  has been merged into this issue.
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)
The same problem is reported in puppeteer
Owner: ----
Status: Available (was: Assigned)
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.
Status: Assigned (was: Available)
Andrey, mind taking a look?
Status: Started (was: Assigned)
Project Member

Comment 35 by, Apr 5 2018

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}

Status: Fixed (was: Started)
Wow this was quick! Thanks!
When should we expect a fixed build that we could use?
This really depends on what channel you are. This site lets you track what releases have certain commit:
Commit c8f0691b... initially landed in 67.0.3390.0

running with chrome 68.0.3440.106 problem persists.
any idea why?
this problem persists with macos version. 70.0.3538.77
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