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 21 users
Status: Assigned
Last visit > 30 days ago
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 Back to list
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?
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
I have built chromium from source yesterday, same result. I guess that's recent enough?
"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:

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

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.
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.
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
I've tried headless firefox in the meantime without issues. I am usually using and selenium to communicate with the browsers.
Labels: TE-NeedsTriageHelp
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.


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.
Using a mitm proxy solved this problem.
Sounds like you're hiding it by letting the proxy handle the problematic ssl handshake.
Status: Available
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
 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
Sign in to add a comment