Self-signed TLS certs not valid

[JohanPetersson]

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

[JohanPetersson]

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.

[alexander-akait]

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

[JohanPetersson]

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.

[alexander-akait]

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

[johnpmitsch]

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

[JohanPetersson]

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

[johnpmitsch]

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

[JohanPetersson]

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

[alexander-akait]

If somebody have ideas how to fix it, PR welcome

[JohanPetersson]

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?

[alexander-akait]

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

[johnpmitsch]

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

[JohanPetersson]

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

[johnpmitsch]

@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?

[JohanPetersson]

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.