webpack-dev-server: HTTPS broken on Chromium browsers
- 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.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 20 (13 by maintainers)
Commits related to this issue
- Remove basicConstraints extension from certificate Based on https://github.com/webpack/webpack-dev-server/issues/2313#issuecomment-558400603 — committed to akx/webpack-dev-server by akx 5 years ago
- fix: remove basicConstraints extension from certificate This fixes TLS on Chromium Linux (see #2313) Based on https://github.com/webpack/webpack-dev-server/issues/2313#issuecomment-558400603 — committed to akx/webpack-dev-server by akx 5 years ago
- fix: remove basicConstraints extension from certificate This fixes TLS on Chromium Linux (see #2313) Based on https://github.com/webpack/webpack-dev-server/issues/2313#issuecomment-558400603 — committed to akx/webpack-dev-server by akx 5 years ago
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.
@k1sul1 feel free do not use webpack
I don’t have time for that.
It doesn’t happen with 3.7.1 or 3.8.2, only 3.9.
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.
No information === no solution, sorry
I can repro this with
Chrome 80.0.3955.4 on Windows says
ERR_CERT_AUTHORITY_INVALIDand allows one to bypass the error.Chromium 78.0.3904.97 (Official Build) Arch Linux (64-bit) says
ERR_CERT_INVALIDwith no visual option to bypass (aside from typing the secretthisisunsafepassphrase 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 forERR_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 forSEC_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.
it is because of folks like this that I’ve completely abandoned open source. So much hate in the open source community.
@k1sul1
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
@akx thanks for investigation, i like when developers help that way
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
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:
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 😃