Certificate error since Chrome 58 - NET::ERR_CERT_COMMON_NAME_INVALID

[JayBizzle]

Issue details

Since Chrome 58, self-signed certificates can cause the following message to appear...

Your connection is not private

Attackers might be trying to steal your information from localhost (for example, passwords, messages or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID

This server could not prove that it is localhost; its security certificate is from [missing_subjectAltName]. This may be caused by a misconfiguration or an attacker intercepting your connection.

Details on why this has suddenly started happening can be found here - https://textslashplain.com/2017/03/10/chrome-deprecates-subject-cn-matching/

Info on creating certificates with the SubjectAltName set correctly can be found here - http://fbcs.co.uk/self-signed-multiple-domain-ssl-certificates/

Steps to reproduce/test case

Update to Chrome 58

Please specify which version of Browsersync, node and npm you're running

• Browsersync [ dev-master ]
• Node [ 6.9.1 ]
• Npm [ 3.10.8 ]

Affected platforms

• [ ] linux
• [ ] windows
• [x] OS X
• [ ] freebsd
• [ ] solaris
• [ ] other (please specify which)

Browsersync use-case

• [ ] API
• [x] Gulp
• [ ] Grunt
• [ ] CLI

If CLI, please paste the entire command below

{cli command here}

for all other use-cases, (gulp, grunt etc), please show us exactly how you're using Browsersync

gulp.task('browser-sync', function() {
        browserSync.init({
            ui: false,
            proxy: "https://www.xxxxxx.dev",
            injectChanges: true,
            ghostMode: false
        });
    });

[ghost]

I tried this guide and still no luck. I can confirm this for myself. https://discourse.roots.io/t/self-signed-ssl-cert-w-browser-sync-localhost-proxy-chrome-on-windows/5862/6

[shakyShane]

Thanks @JayBizzle - but as far as I remember, I've always been greeted by this warning - I just accepted it 'something you get' with self-signed certs.

Are you suggesting that for you, you didn't previously see this warning?

[JayBizzle]

@shakyShane Yes, previously we prevented this warning by adding the certificates in the /lib/server/certs folder to our KeyChain and setting them to Always Trust (You can do this with all self-signed certs, so you get the green URL bar whilst in a dev environment)

But, since the Chrome 58 update, the certs aren't valid from Chromes point of view anymore because of the reasons mentioned in the first link in my first post.

Thanks

[shakyShane]

Great, thanks - I'll look into it then :)

[mikemartin]

@JayBizzle @shakyShane I fixed this by generating my own certs with Keychain and including the SAN extension.

This has removed the security error but hopefully Browsersync updates their own certs in /lib/server/certs/ to include the SAN extension soon.

.browserSync({
      https: {
        key: "/Users/mike/.localhost-ssl/key.pem",
        cert: "/Users/mike/.localhost-ssl/cert.pem"
      }
    });

[JayBizzle]

Good work @mikemartin

Will test this out as a short term solution

[glambert]

What would need to be done for this to be fixed?

[JayBizzle]

@ls-guillaume-lambert Create a certificate that satisfies the requirements outlined here - https://textslashplain.com/2017/03/10/chrome-deprecates-subject-cn-matching/

[glambert]

@JayBizzle I'm not too familiar with this, is it simple enough that you could do it and I'd be glad to review 😉

[cwellsx]

There's a related thread here https://github.com/webpack/webpack-dev-server/issues/854 with comments on how to generate appropriate certificates using various tools on various platforms.

[mikemartin]

Amazing. Great to see that @johnboxoll is on the case! Looks like he has a recent pull request here: https://github.com/webpack/webpack-dev-server/pull/857

[glambert]

In the mean time, you can allow-insecure-localhost in chrome flags:

chrome://flags/#allow-insecure-localhost

Found here: https://productforums.google.com/d/msg/chrome/sTyLejkD8NQ/bhAhmHIzAgAJ

[glambert]

This how-to article worked too: https://deliciousbrains.com/https-locally-without-browser-privacy-errors/ combined with custom key/cert in browser-sync's https config:

https: {
  key: '/path/to/localhost.key',
  cert: '/path/to/localhost.crt',
},

[eduardomb08]

The solution here worked for me; running on IE.