Tools: HTTPS

[indolering]

Mixed content can cause problems in some browsers, it would be ideal if Polyserve came with a self-signed cert that could be added to the browser's trustbase.

[justinfagnani]

I'm far from a security expert, but I'd be wary about publishing a cert that's intended to be installed into a users browser. What about an option to use a cert supplied as a command-line flag?

[indolering]

It wouldn't be seeded into the trustbase automatically, for 99% of developers, "adding a cert to the trust base" translates into manually overriding a warning and (for Firefox users) saving a permanent exception that only be valid for the loopback address. Furthermore, Polyserve would generate the cert during installation, so an attacker would need to have local access to your machine anyway.

[indolering]

The cert should be valid for localhost, 127.0.0.1, and 10.0.2.2. The IE/Edge VMs use the latter address as a proxy for the host loopback address.

[tony19]

PR https://github.com/PolymerLabs/polyserve/pull/98 adds support for h2 and https. It generates the TLS key/cert for the user, so we don't need to provide one (although the PR supports specifying a key/cert if desired).

[abdonrd]

The #98 should have solved the HTTPS?

With polymer serve --protocol h2 --manifest push-manifest.json, I see:

[justinfagnani]

@abdonrd this is expected, as self-signed certs aren't actually trusted. They would need to be added to the browsers set of trusted certs manually.

[abdonrd]

Thanks @justinfagnani! I added the cert manually and marked as trusted:

And now the error is different: NET::ERR_CERT_COMMON_NAME_INVALID

[justinfagnani]

There's also a flag to trust invalid certs from localhost. That's what I'm using.

[abdonrd]

@justinfagnani thanks! Only with chrome://flags/#allow-insecure-localhost enabled works! :)