Self-signed TLS certs not valid

Operating System: Windows 10 20H2 (19042.685)
Node Version: 14.15.1
NPM Version: 6.14.8
webpack Version: 4.44.2
webpack-dev-server Version: 3.11.0
Browser: Chrome, Edge, IE

This is a bug
This is a modification request

Code

Expected Behavior

No warnings in the browser and the app is served on a secure connection.

Actual Behavior

Warning screen with following warning:

NET::ERR_CERT_AUTHORITY_INVALID

By clicking 'Advanced' button and then 'Continue to localhost (unsafe)' the app loads and works (sort of) for a while. Then same warning screen appears after a while. I would expect there is a way to trust the root CA for this certificate, like any other development webserver? I can't find any command or documentation how to add a trusted root CA for the automatically created self-signed certificates. Or is the only option to generate our own self-signed certificates? That's not very helpful or convenient that every developer on the solution has to do that.

For Bugs; How can we reproduce the behavior?

Enable https and start serving the app.

One convenient way of getting rid of the warning screen is to enable this flag in the browser settings chrome://flags/#allow-insecure-localhost. But the certificate is still invalid and hot-reloading doesn't work.

I think it is expected, try to do this without webpack-dev-server and you get the same problem

So there is no way that the automatically created certificates can be generated with a trusted root CA, that we need to trust beforehand somehow?

For example IIS Express prompts you first time to trust the certificate. Dotnet core (5) CLI also have a command to trust the certificate. So this is a one-time operation you do once for your computer/user. Then all subsequent generated certificates are trusted.

But this message from browser, not webpack-dev-server

Seeing the same thing, not sure what changed as well or if it has anything to do with webpack and it's dependencies.

Yes it manifests itself in the browser, but the root cause is that the certificates are not generated with trusted root CA.

@JohanPetersson

@JohanPetersson did you try with --http2 false?

Unfortunately we are on webpack-dev-server 2.11 and I don't see this option, but removing h2 from the array here fixed it.

@johnpmitsch

@johnpmitsch made no difference. Thanks for the suggestion. The generated certificate still lacks a trusted CA.

If somebody have ideas how to fix it, PR welcome

Unfortunately I lack the competence, otherwise I would happily contribute.

It seems like this is "by design". So maybe this is more of a feature request. But it's kinda weird that certificates are generated automatically, but not valid ones. Wouldn't we be better off just removing the feature, or why would anyone want invalid certificates?

I think it is new behavior from browsers for localhost, try to use other internal local address

@JohanPetersson

@JohanPetersson Sorry, I actually think I'm seeing a separate issue, using http2 with the generated self-signed cert results in the browser complaining about NS_ERROR_NET_INADEQUATE_SECURITY. I was able get around it with the workaround above. I'm not sure if something changed in the browser or fell out of date with the certs,

As far as always need to re-trust the cert in the browser, we've seen that too. I think it's more common if you are using a hostname instead of localhost, for example running webpack on a VM and accessing with a hostname you set up locally. But can't say for sure.

@alexander-akait

@alexander-akait I will try running the app on different host. Thanks for the suggestion. I however don't see how this will change the generation of the certificate.

@alexander-akait

@alexander-akait I will try running the app on different host. Thanks for the suggestion. I however don't see how this will change the generation of the certificate.

My understanding is they are valid, but self-signed, certs. Browsers tend to not trust them and keep increasing the security features around them. So it's just a pain for development.

I guess you are asking if there is a way to create the cert signed by a CA cert to and allow users trust that CA certificate as a one-time operation?

I guess you are asking if there is a way to create the cert signed by a CA cert to and allow users trust that CA certificate as a one-time operation?

Exactly. That's how donet/kestrel solves it, you trust a root certificate which is then used by all generated development certificates.

Exactly. That's how donet/kestrel solves it, you trust a root certificate which is then used by all generated development certificates.

That would be nice, however I don't think selfsigned supports it, so it may be a big ask.

I've solved the untrusted cert warning by creating my own root CA (I think I used openssl), adding it to my trusted certs in OS & browsers, then dynamically creating a new client cert signed by my root CA and passing it to webpack-dev-server. It'd be nice if there was an option to point webpack-dev-server at my root CA and have it create the client certs for me, but it's not hard manually.

In webpack.config.js my config is dynamically built and returned. Here are the pieces you can add to yours to get this to work. This requires the pem module.

Add this somewhere before your config:

const certificates = await getCertificates();

Add this inside your config:

https : {
  key  : certificates.key,
  cert : certificates.cert,
  ca   : certificates.ca,
},

Add this after your config:

function getCertificates() {
  const pem = require('pem');

  const keyFile  = fs.readFileSync(`${__dirname}/../path_to_your_root_ca/ca.key`, 'utf8');
  const certFile = fs.readFileSync(`${__dirname}/../path_to_your_root_ca/ca.crt`, 'utf8');
  const args     = {
    clientKey    : keyFile,
    commonName   : 'localhost',
    organization : 'Your Org',
    locality     : 'Boise',
    state        : 'ID',
    country      : 'US',
  };

  return new Promise((resolve, reject) => {
    pem.createCSR(args, function (error, results) {
      if (error) {
        throw error;
      }

      const args = {
        serviceKey         : keyFile,
        serviceCertificate : certFile,
        csr                : results.csr,
        days               : 30,
      };

      pem.createCertificate(args, function (error, keys) {
        if (error) {
          throw error;
        }

        const data = {
          key  : keys.serviceKey,
          cert : keys.certificate,
          ca   : certFile,
        };

        resolve(data);
      });
    });
  });
}

@Enchiridion

@Enchiridion that seems like an OK workaround. But I'd like to get away of first having to generate a root CA, because if you have to do that, then why not just generate them all manually. It still begs the question - why is self-signed certificates automatically generated when they don't seem to add any value? Or am I missing something?

I guess it would be possible to include your code in webpack-dev-server and also include a root CA for localhost. Then add a CLI command that prompts you to trust it. Then package it up nicely

I guess it would be possible to include your code in webpack-dev-server and also include a root CA for localhost. Then add a CLI command that prompts you to trust it.

Sounds good

Another option is to use office-addin-dev-certs.

const devCerts = require('office-addin-dev-certs');

return {
    devServer: {
        https: await devCerts.getHttpsServerOptions()
    }
};

Looks like it is impossible to fix, for using self-signed certificates you need to import pem, steps:

Import name.pem as an "Authority" (not into "Your Certificates") in your Chrome settings (Settings > Manage certificates > Authorities > Import)

Chrome improve security for localhost too (https://web.dev/how-to-use-local-https/), I think we will improve our CLI output for better using and importing pem

Also you can use mkcert util (https://github.com/FiloSottile/mkcert), mkcert automatically creates and installs a local CA in the system root store, unfortunately current library on node.js is not working

@creage

I used the Office add-in @creage posted. Worked like a charm and gives you a trusted cert. But I don't know how to incorporate that into Webpack.

@JohanPetersson

@JohanPetersson What is your os? I am on ubuntu and it is not work, but works fine on windows, office-addin-dev-certs try to do the same as mkcert, but there are some platform limitations...

I'm on Windows. But looking at the source code, it looks like it should work on all platforms, https://github.com/OfficeDev/Office-Addin-Scripts/blob/master/packages/office-addin-dev-certs/src/install.ts#L26.

Anyway asking root password is not good idea by default, also I looked at source code and issues, and there are also problems on macos + some linux os have other paths, so it is not work (I think I am here), I think using button in browser (to allow using certificate) is most good solution here

Navigation Menu

Repository navigation

Self-signed TLS certs not valid #2957

Code

Expected Behavior

Actual Behavior

For Bugs; How can we reproduce the behavior?

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Self-signed TLS certs not valid #2957

Description

Code

Expected Behavior

Actual Behavior

For Bugs; How can we reproduce the behavior?

Activity

JohanPetersson commented on Jan 8, 2021

alexander-akait commented on Jan 8, 2021

JohanPetersson commented on Jan 8, 2021

alexander-akait commented on Jan 8, 2021

johnpmitsch commented on Jan 8, 2021

JohanPetersson commented on Jan 8, 2021

johnpmitsch commented on Jan 8, 2021

JohanPetersson commented on Jan 8, 2021

alexander-akait commented on Jan 8, 2021

JohanPetersson commented on Jan 8, 2021

alexander-akait commented on Jan 8, 2021

johnpmitsch commented on Jan 8, 2021

JohanPetersson commented on Jan 8, 2021

johnpmitsch commented on Jan 8, 2021

JohanPetersson commented on Jan 8, 2021

johnpmitsch commented on Jan 8, 2021

Enchiridion commented on Jan 28, 2021

JohanPetersson commented on Jan 28, 2021

alexander-akait commented on Jan 28, 2021

creage commented on Feb 14, 2021

alexander-akait commented on Aug 18, 2021

JohanPetersson commented on Aug 18, 2021

alexander-akait commented on Aug 18, 2021

JohanPetersson commented on Aug 18, 2021

alexander-akait commented on Aug 18, 2021

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions