Webpack-dev-server: 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

• [x] 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 :confused:

[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 [email protected]) 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 a4dbc3b73921490ca3200b4c21b4ad0540f63327 (#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.

[alexander-akait]

@akx thanks for investigation, i like when developers help that way

[alexander-akait]

@akx If you have ideas how to fix it asap feel free to send a PR, anyway i will look on issue in near future

[akx]

The quick dirty fix is to revert a4dbc3b73921490ca3200b4c21b4ad0540f63327, which will apparently break WDS HTTPS for Safari-on-macOS-Catalina users, but fix it again for Chrome-on-Linux users.

If my guess above is correct, we'd need a solution where we the server cert is a chain of two certificates:

• a self-signed CA certificate that has no SSL Server key usage and no subject names etc.
• a certificate signed by that CA certificate that does have SSL Server key usage and subject names set up (and all of the other requirements Catalina has) set up

I don't know if https://github.com/jfromaniello/selfsigned (the library currently in use) can do that directly, or if it'd even work.

However on a semi-positive note, I think we'll be seeing this problem more across the JavaScript self-signed certificate ecosystem in the near future – someone might already have a working solution too :)

[drdrak3]

We currently have some developers using OSX and some using Linux, so we currently have no way of getting things working for our entire team.

We've resorted to getting the Linux devs to use Firefox for the time being, but not an ideal situation.

A real fix would be great

[alexander-akait]

In my todo, I will look for solutions this week, thanks for reproducible test repo and investigation

[gigafied]

You can fix it by removing the basicConstraints extension... Removing basicConstraints and leaving extKeyUsage works for both Linux and Catalina.

[akx]

You can fix it by removing the basicConstraints extension... Removing basicConstraints and leaving extKeyUsage works for both Linux and Catalina.

That does make sense – way I see it that'd mean the key is not marked for CA use. Care to make a PR? See #2330 :)

[alansouzati]

it is because of folks like this that I've completely abandoned open source. So much hate in the open source community.