⚠️ Apparently, this goes against letsencrypt's ToS and I can't use their certificates in such manner. And I have to drop this tool. I would have issued a non-free certificate to keep this tool up, but it doesn't sound like a great idea to publish a private key that is officially registered to my name.
No certificate creation, no tunnels and no hassle ⚡️
The importance of using HTTPS locally
One might assume that HTTPS isn’t needed for local development. But that’s not always the case. You need to test for mixed-content, secure cookies, service workers, etc. This thread by @getify makes the point perfectly.
Running a local HTTPS server can be pain in the neck. You have to create your own certificates, add them as trusted etc. You know the deal.
Using tunnels, at least the freely-available choices, isn’t the best experience either, they create a different URL everytime, they can get really slow, and 3rd parties will have access to your app in plain text.
But what if you could use a static, short and memorable URL to access your app without 3rd parties involvement? ez-s does exactly that. You run ez-s
and access https://ez-s.io
and you’ll see your app with a green badge.
What is EZ-S?
It’s a fork of zeit/serve that gives you the ability to locally run a green-badge HTTPS server. You can see it on GitHub here.
Quick steps
$ npm i -g @alshakero/ez-s
$ ez-s
# => go to https://ez-s.io to see your app
How does it works?
- The domain ez-s.io has a single A DNS record pointing to the IP address 127.0.0.1.
- ez-s package includes SSL certificates generated by letsencrypt.
- There is also a small HTTPS server that uses the aforementioned certificates including the private key. So when you access ez-s.io the certificate provided will actually match letsecrypt's, and you get a green badge. The IP address of the host does not matter. As long as letsencrypt records match the certificates provided by the server, Chrome will not object.
Wait what? Public private keys?! Yes. Because the domain will forever point to 127.0.0.1, impersonating it will not take the impersonator anywhere. Unless the impersonator has power over the victim’s DNS server, which makes ez-s the least of the victim’s worries 😁
Caveat
Since ez-s.io points to 127.0.0.1
, your app will be only accessible locally. You can't test it on your phone or using another machine.
Due to this caveat, serve's --listen
argument is useless in this case. The only configurble network-related parameter is the port (-p
or --port
).
Questions
If you have any questions please go ahead and comment below.
Top comments (6)
This is absolutely horrible advice. You are literally saying 'it's ok to trust someone because they say they are trustworthy'. That is the worst security advice there is.
You can create your own self signed certificate very easily that allows you to test your web code. digitalocean.com/community/tutoria... should work for most linux distributions.
Beyond that, you could also do much better by using LetsEncrypt to generate a test and a production certificate, both of which would be good for 90 days, and simply re-renew them through the acme framework or other similar tools.
Where am I saying this?
I am afraid you totally misunderstood the point of this post. This has nothing to do with trust at all. It is not meant to be secure nor trusted.
It strictly works for
localhost
, and merely to satisfy Chrome while testing if your asset URLs are all https, all your cookies are secure etc.This CANNOT be used in production, because as mentioned in the article, the domain points to 127.0.0.1. And even if I change the domain to another IP address, visiting it would be simply like visiting any URL on the vast web.
The link you cite has nothing to do with this post.
I am getting following error -- An error occurred during a connection to ez-s.io:5000. Peer’s Certificate has been revoked. Error code: SEC_ERROR_REVOKED_CERTIFICATE
I updated the article :(
What exactly did this violate?
I fail to see how this could be exploited?
Is it because you don't actually own ez-s.io?
I own ez-s.io.
I agree. I read their terms and it does not violate them since I own the domain. But the other caveat is that they allow anyone who has access to the private key to revoke the certificate. So even if they didn't mind, someone will inevitably revoke
my certificate just for a laugh.