Browser-sync ignoring development server address and SSL errors on localhost

[filip-van-hoeckel]

I have this as per documentation
"watch:browser-sync": "browser-sync start --proxy "clientname.test" --files "theme" --no-notify --no-inject-changes", but browser-sync still opens localhost:3000. The browser then of course throws an SSL error. I have tried appending the port number to the domain but that just leads to another SSL protcol error.

[gregsullivan]

Hi Filip—Thanks for posting this!

When you say it throws an SSL error, does it give you the opportunity to accept a self-signed certificate? That is the intended workflow, according to the Browsersync maintainer:

Browsersync is a development tool to be used on local addresses that you're working on - in those cases it will work fine with HTTPS - you'll just have to click accept on the warning about self-signed certs :)

If there is no option to accept the self-signed certificate, can you please share what error you're seeing?

[filip-van-hoeckel]

No self-signed certificate and when starting BS it opens localhost:3000 - not clientname.test (which might explain why there's no certificate). FWIW; when running the server and approaching clientname.test SSL is no issue at all.

[gregsullivan]

I would expect it to open localhost, proxying the .test domain.

My understanding is that it will ask you to approve a self-signed certificate created for the localhost connection. Is it doing that? If not, what does the error say?

[gregsullivan]

It appears the protocol now needs to be explicitly set for Browsersync to work. I've updated the documentation. Please let me know if that works for you!

(So you'll need "https://clientname.test" rather than "clientname.test".)

[filip-van-hoeckel]

Still does not open the proxy, but localhost:3001 with this error message net::ERR_CERT_AUTHORITY_INVALID

[gregsullivan]

The intended outcome is that it will open a localhost domain, proxying the .test domain, so this sounds right to me!

That error message is also what I'd expect to see, but you'll need to accept the self-signed certificate. The steps for this vary by browser, but typically there will be an "Advanced" button or something similar, and then you confirm you understand the risks and choose to proceed.

[filip-van-hoeckel]

Clicking Advanced then proceeding works, but is this something I'd need to do for each session?

[gregsullivan]

I think it depends on your browser / OS settings. If you want HTTPS and don't want the warning, it is possible to specify a key and certificate:

https://browsersync.io/docs/options#option-https

But I think you'd need to use an external configuration file, and I think there are different steps in terms of trusting those certificates and so on.

Another possible option would be to run your local development server over HTTP rather than HTTPS.

I'm going to convert this issue to a discussion since Browsersync is working as expected, but I'm happy to answer any other questions you might have!

[filip-van-hoeckel]

We use Laragon and that takes care of SSL for the virtual hosts, but not for localhost. Which makes sense, right?

[gregsullivan]

That does make sense, yes! If you hypothetically wanted to go the non-SSL route, you would do that by switching the WordPress URL from the HTTPS version to an HTTP one and ensuring you don't have any automatic redirects from HTTP to HTTPS. So long as you could browse the site on the virtual host while staying in HTTP, you would know it was working.

If you wanted to go the key and certificate route, your steps are basically:

• Generate the key and certificate
• Set your computer / browser up to trust them
• Have Browsersync use them

[filip-van-hoeckel]

Thing is, and I'll try once more to explain: the virtualHost _has a working cert. However BS redirect to "localhost" NOT the virtualHost. AFAIK it's impossible to generate certs for localhost. So I have a cert and key for virtualHost but these will never work for "localhost". And that's what BS does: it proxies virtualHost to localhost.

[gregsullivan]

Yes, that all sounds as expected to me: Browsersync needs to modify the HTML of the page, so it needs to proxy your virtual host and will always load via localhost. If you want localhost to have a trusted certificate, you need to generate it yourself and trust it. (This assumes you aren't comfortable clicking through the self-signed certificate warnings as suggested by the Browsersync maintainer.)

Here are instructions (for macOS) on generating a self-signed certificate for localhost:

https://stackoverflow.com/a/32169444

Here are the Browsersync instructions for telling it to use a certificate you generated yourself:

https://browsersync.io/docs/options#option-https

[filip-van-hoeckel]

"Note - this is not needed for proxy option as it will be inferred from your target url." source

[gregsullivan]

For anyone finding this in the future, this is the full line from the documentation:

Enable https for localhost development. Note - this is not needed for proxy option as it will be inferred from your target url.

This is the most basic use of the https option:

// Enable HTTPS for snippet mode
browserSync({
    https: true
});

This is the usage I was referencing:

// Enable HTTPS mode with custom certificates
browserSync({
    https: {
        key: "path-to-custom.key",
        cert: "path-to-custom.crt"
    }
});

My interpretation of the line you quoted is that you don't need to set https to true if you're using the proxy option.

I understand that your interpretation is that it is impossible to specify custom certificates if you are using proxy mode.

I'd be very surprised if this were true, but I won't be able to test this myself today or in the near future. If you test it, please let us know what you find!