DEV Community

Omar Alshaker
Omar Alshaker

Posted on • Updated on

[discontinued] Run a green-badge local HTTPS server with zero configuration


⚠️ 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 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 to see your app

How does it works?

  1. The domain has a single A DNS record pointing to the IP address
  2. ez-s package includes SSL certificates generated by letsencrypt.
  3. There is also a small HTTPS server that uses the aforementioned certificates including the private key. So when you access 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, 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 😁


Since points to, 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).


If you have any questions please go ahead and comment below.

Top comments (6)

daemoen profile image
Marc Mercer

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. 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.

alshakero profile image
Omar Alshaker • Edited

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.

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 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.

alamnr profile image

I am getting following error -- An error occurred during a connection to Peer’s Certificate has been revoked. Error code: SEC_ERROR_REVOKED_CERTIFICATE

alshakero profile image
Omar Alshaker

I updated the article :(

qm3ster profile image
Mihail Malo

What exactly did this violate?
I fail to see how this could be exploited?
Is it because you don't actually own

Thread Thread
alshakero profile image
Omar Alshaker • Edited

I own

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.