HTTPS broken on Chromium browsers

[k1sul1]

• Operating System: Arch Linux
• Node Version: 10.16.3
• NPM Version: 6.9.0
• webpack Version: 4.41.2
• webpack-dev-server Version: 3.9.0
• Browser: Chrome 78

• This is a bug
• This is a modification request

Code

// relevant part of the config
const config = {
  webpack: {
    publicPath: '/wp-content/themes/doge/dist/',
    serverAddress: 'doge.local',
    wordpressUR: 'https://doge.local',
  }
}
const { webpack } = config
const devServerPlugin = (opts = {}) => {
  const isWin = /^win/.test(process.platform)
  const isMac = /^darwin/.test(process.platform)

  // Override publicPath
  const publicPath = (isHTTPS ? 'https' : 'http') + `://${host}:${port}${webpack.publicPath}`

  return merge({
    devServer: {
      host,
      port,
      https: isHTTPS,
      stats: 'errors-only',

      overlay: {
        errors: true,
        warnings: false,
      },

      watchOptions: {
        poll: isWin || isMac ? undefined : 1000,
        aggregateTimeout: 300,
      },

      open: process.env.OPEN !== 'false',
      hotOnly: true,
      clientLogLevel: 'none',
      publicPath,

      proxy: {
        '/': {
          target: webpack.wordpressURL,
          changeOrigin: true,
          autoRewrite: true,
          secure: false,
          headers: {
            'X-Proxy': 'webpack-dev-server',
          },
        },
      },

      // Allow access to WDS data from anywhere, including the standard non-proxied WP
      headers: {
        'Access-Control-Allow-Origin': '*',
        'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, PATCH, OPTIONS',
        'Access-Control-Allow-Headers': 'X-Requested-With, content-type, Authorization',
      },
    },

    plugins: [
      new WriteFile({
        test: /^(?!.*(hot)).*/,
      }),
      new HotModuleReplacement(),
    ],

    output: {
      publicPath,
    },
  })
}

Expected Behavior

Not this.

Actual Behavior

Can't access the development site because the browser doesn't let me. Downgrading to 3.8.2 fixes the issue.

"... the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later."

For Bugs; How can we reproduce the behavior?

Install 3.9 on Linux and use a chromium browser.

[alexander-akait]

Please create reproducible test repo, can't reproduce 😕

[k1sul1]

I don't have time for that.

It doesn't happen with 3.7.1 or 3.8.2, only 3.9.

[alexander-akait]

@k1sul1

I don't have time for that.

I found the time to ask you and find out that no works like that, so a little respect would be nice.

I asked to do this not because I want to, but because I do not have this problem, maybe something is wrong on your side and I would like to figure it out to help you and other developers, thanks

In near future we will do release next version, so you can pinned permanently

[k1sul1]

Well I have bills to pay, and TWO deadlines this week. One of them is TOMORROW, so excuse me if I don't prioritize work that doesn't pay me a dime.

Even if something was wrong on my side, the fault didn't appear before upgrading to 3.9.

I tried upgrading for the first time about two weeks ago, and when it didn't work, I checked the issues, and there were none. When the problem persisted after trying to upgrade today, I took the time to write this issue, despite being busy as fuck.

[alexander-akait]

No information === no solution, sorry

[k1sul1]

I gave you all the information that I can. I don't really care if you fix it or not. The old version works for now, when it stops working, I'll stop using Webpack.

Simple as that.

[alexander-akait]

@k1sul1 feel free do not use webpack

[akx]

I can repro this with

$ yarn add webpack webpack-dev-server
$ touch index.js
$ webpack-dev-server --https --entry ./index.js --host 0.0.0.0

Chrome 80.0.3955.4 on Windows says ERR_CERT_AUTHORITY_INVALID and allows one to bypass the error.

Chromium 78.0.3904.97 (Official Build) Arch Linux (64-bit) says ERR_CERT_INVALID with no visual option to bypass (aside from typing the secret thisisunsafe passphrase into the page 🙃) .

There are errors in the stderr log:

ssl_client_socket_impl.cc(969) handshake failed; returned -1, SSL error code 1, net_error -207. (-207 stands for ERR_CERT_INVALID.) This doesn't help much.

cert_verify_proc_nss.cc CERT_PKIXVerifyCert for localhost failed err=-8101. According to this page, NSS error -8101 stands for SEC_ERROR_INADEQUATE_CERT_TYPE, "Certificate type not approved for application.". This sounds apropos to #2274.
According to the Chrome certificate dialog, the Certificate Key Usage fields are "Not Critical", "Signing", "Non-repudiation", "Key Encipherment", "Data Encipherment", "Certificate Signer"; the extended key usage fields are "Not Critical", "TLS WWW Server Authentication (OID.1.3.6.1.5.5.7.3.1)", "TLS WWW Client Authentication (OID.1.3.6.1.5.5.7.3.2)", "Code Signing (OID.1.3.6.1.5.5.7.3.3)", "Time Stamping (OID.1.3.6.1.5.5.7.3.8)".

In comparison, example.com only has a cert for "Critical" / "Signing" / "Key Encipherment"; "TLS WWW Server Authentication (OID.1.3.6.1.5.5.7.3.1)" / "TLS WWW Client Authentication (OID.1.3.6.1.5.5.7.3.2)". It could well be possible that some Chrome/Chromium configurations disallow certificates that are too broad. I'll look into things and report back.

[akx]

Downgrading to 3.8.2 (yarn add webpack-dev-server@3.8.2) fixes this (or at least turns ERR_CERT_INVALID into ERR_CERT_AUTHORITY_INVALID), as @k1sul1 noted.

The NSS error we get now is -8172, SEC_ERROR_UNTRUSTED_ISSUER. Sounds about right.

The certificate generated by 3.8.2 has no Extended Key Usage fields at all, only a Certificate Key Usage field of "Not Critical", "Signing", "Non-repudiation", "Key Encipherment", "Data Encipherment", "Certificate Signer".

[akx]

Yep - fully removing the extKeyUsage block added by a4dbc3b (#2274) from my local copy of WDS 2.9.0 fixes this.

The cert is again ERR_CERT_AUTHORITY_INVALID only in the badly behaving Linux Chrome, and still works (though unsafe) on the other browsers I had at hand, namely Firefox 68.0.2 on Win10 and Edge version whatever blah blah on Win10.

[akx]

Hmm. My best guess here at this point is that the self-signed certificate itself can't be, as far as Chrome cares, both a certificate for issuing other certificates and have extended key usages. (An empty Extended Key Usage extension in the cert also breaks Linux Chrome.) (This seems relevant: https://security.stackexchange.com/questions/194283/root-ca-with-extended-key-usage-fields)

@evilebottnawi Could we have this reopened? It is a real reproducible issue.

[k1sul1]

Thanks @akx. I don't know how the browser nor webpack internals work and producing a reproducible example for this would've taken me a lot of time that I do not have.

TIL you can use webpack-dev-server without a config.