SSL AIA does not seem to be followed on Headless on Linux

beeb...@gmail.com

unread,

Aug 7, 2018, 5:00:11 AM8/7/18

to headless-dev

Hi,

Can anybody else a) confirm this issue and b) suggest a 'fix'/workaround.

Basically, going to a website with an incomplete certificate chain such as https://incomplete-chain.badssl.com/ (experienced on other sites as well - but so far, only Digicert certificates have show this problem) where it DOES have the AIA in the certificate:

Authority Information Access:

OCSP - URI:http://ocsp.digicert.com

CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt

Chrome (and headless) on Mac/WIndows manages to automatically follow the AIA/Authority Information Access path and fetch the intermediate certificate from the chain. However, Headless on Linux (try via https://try-puppeteer.appspot.com/ as one example, although our local examples have failed and use just headless dev-tools without Puppeteer) fail to follow the AIA and die with an 'Error: net::ERR_CERT_AUTHORITY_INVALID' error.

My expectations are for headless to work as closely to 'the same' as desktop versions of Chrome as possible (no matter which OS).

We've tried using the latest Curl CACert bundle and Debian ca-certificate updates, but without any change.

I've just tested with:

google-chrome-stable 68.0.3440.84-1

ubuntu 18.04.1 (Docker ubuntu)

Works:

# google-chrome-stable --headless --no-sandbox https://www.chromestatus.com

Fails:

# google-chrome-stable --headless --no-sandbox https://incomplete-chain.badssl.com

[0807/085848.422713:ERROR:gpu_process_transport_factory.cc(1016)] Lost UI shared context.

[0807/085848.889676:ERROR:nss_ocsp.cc(601)] No URLRequestContext for NSS HTTP handler. host: cacerts.digicert.com

[0807/085848.890258:ERROR:cert_verify_proc_nss.cc(981)] CERT_PKIXVerifyCert for incomplete-chain.badssl.com failed err=-8179

beeb...@gmail.com

unread,

Aug 23, 2018, 8:48:58 AM8/23/18

to headless-dev, beeb...@gmail.com

There is a Github thread for this issue in Puppetteer: https://github.com/GoogleChrome/puppeteer/issues/2377 , however it does seem to be a headless Chrome on Linux issue:

On Ubuntu 14.04.5 LTS (Trust Tahr) using Google Chrome 68.0.3440.106 :

``/usr/bin/google-chrome --headless --dump-dom https://www.example.com``

produces the DOM as expected, but:

``/usr/bin/google-chrome --headless --dump-dom https://incomplete-chain.badssl.com``

fails with:

```

[0823/115256.905080:ERROR:gpu_process_transport_factory.cc(1016)] Lost UI shared context.

Fontconfig warning: "/etc/fonts/fonts.conf", line 146: blank doesn't take any effect anymore. please remove it from your fonts.conf

[0823/115257.126541:ERROR:nss_ocsp.cc(601)] No URLRequestContext for NSS HTTP handler. host: cacerts.digicert.com

[0823/115257.126667:ERROR:cert_verify_proc_nss.cc(981)] CERT_PKIXVerifyCert for incomplete-chain.badssl.com failed err=-8179

```

Running on Macos 10.13.6 (High Sierra) using Google Chrome 68.0.3440.106:

``/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --headless --dump-dom https://www.example.com``

produces the DOM as expected AND

``/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --headless --dump-dom https://incomplete-chain.badssl.com``

returns the DOM as expected.

It's definitely an OS dependent issue from my point of view and isn't a Puppeteer issue directly.

Launching Chrome with the arguments ``--ignore-certificate-errors --enable-features=NetworkService`` does *appear* to work - until you turn on request interception (which is needed to handle htauth/htpass username/password authentication or to block/inspect urls).

kiran...@spreadsheet.com

unread,

Sep 17, 2019, 2:22:17 AM9/17/19

to headless-dev, beeb...@gmail.com

Hi Beeb,

Is this fixed? I mean, is there a way now to bypass/ignore ssl certificate in Linux machine (Puppeteer, Headless Mode)