The HTTPS dev cert shipped in @windycom/plugin-devtools (used by this template's rollup.config.js as certificatePEM) has only a legacy CN=localhost and no Subject Alternative Name. It's the same cert across versions – still identical in the latest 3.0.4.
Since Chrome 58, Chromium ignores CN and requires a SAN. So https://localhost:9999/plugin.js shows "Your connection is not private", and – the real problem – it can't be fixed by trusting the cert: after importing it into the Windows Trusted Root store, Chrome/Edge still reject it with NET::ERR_CERT_COMMON_NAME_INVALID. There is no way to get a clean dev setup with the current cert.
The cert already has CA:TRUE, so the only thing missing is the SAN. Please regenerate it with one:
openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 3650 \
-subj "/C=CZ/ST=Czechia/O=Windy/CN=localhost" \
-addext "subjectAltName=DNS:localhost,IP:127.0.0.1,IP:::1" \
-addext "basicConstraints=CA:TRUE"
I'm also attaching the diff with this command run.
index.patch
With a SAN, developers can add the cert to their OS trust store once and get a working green-padlock dev server.
The HTTPS dev cert shipped in
@windycom/plugin-devtools(used by this template'srollup.config.jsascertificatePEM) has only a legacyCN=localhostand no Subject Alternative Name. It's the same cert across versions – still identical in the latest 3.0.4.Since Chrome 58, Chromium ignores
CNand requires a SAN. Sohttps://localhost:9999/plugin.jsshows "Your connection is not private", and – the real problem – it can't be fixed by trusting the cert: after importing it into the Windows Trusted Root store, Chrome/Edge still reject it withNET::ERR_CERT_COMMON_NAME_INVALID. There is no way to get a clean dev setup with the current cert.The cert already has
CA:TRUE, so the only thing missing is the SAN. Please regenerate it with one:I'm also attaching the diff with this command run.
index.patch
With a SAN, developers can add the cert to their OS trust store once and get a working green-padlock dev server.