Show HN: My Weekend Project, AutoSSL | Hacker News Reader

Show HN: My Weekend Project, AutoSSL

autossl.co

38 pointsSandeepg33k42 comments

Creator here. While building my current startup, we had this requirement to offer custom domains to our users. We also wanted to serve those domains over HTTPS. After days of searching and brainstorming, I had no luck! I found a couple of potential solutions but they were either too expensive or too complicated.

So, I spent a few weeks building an in house solution that automates the whole process of provisioning and renewing SSL certs for our users. It involves Let's Encrypt and has been working great so far!

Last week I thought of offering this as a SaaS product. With the help of my friend, I coded an app where customers can add their domains in a few steps. It's live at https://autossl.co. Once a domain is added to our system, we generate a CNAME record for that domain. When the domain is accessed for the first time, we generate an SSL cert on demand through Let's Encrypt and renew it every 3 months. I also expose APIs to add domains to our system. So, if you are a SaaS company offering custom domains to your customers, you can completely automate SSL issuance in an easy and cost effective way.

I think it has got some potential. What do you think?

Pricing?

We are still figuring it out. We will most likely have 4 tiers with the highest tier offering unlimited domains. We are thinking of pricing the highest tier somewhere between $400 - $500 and offer discounts to startups with < 10 employees.

Note that this is not final. I haven't given any serious thoughts to it. We'll discuss pricing if this works and businesses are willing to pay for this service. At this point, this is just an experiment.

Cool website for a weekend project - what tools did you use to make it?

I am using Caddy internally in fleet mode and Node.js. Caddy takes care of SSL negotiation, provisioning, and renewals. My Node.js app sits behind Caddy and proxies requests to the origin. I am trying to create an edge network where SSL is negotiated at a location that is closest to the users. Caddy is battle-tested, but managing multiple Caddy servers, monitoring them and backing up the certs can become cumbersome. That's the reason I am trying to automate the whole process for businesses.

You should have spent a couple of minutes instead of weeks to use something like Lego, certbot or even Caddy, which makes it fully automatic. Sorry, but you wasted weeks reinventing a worse wheel than what already exists.

The branding is confusing. AutoSSL is a very popular feature with WHM/cPanel, so many shared hosting providers offer their "AutoSSL" service.

Additionally, Let's Encrypt is a partner with cPanel's AutoSSL, so even more confusion may arise out of that.

For example: https://www.google.com/search?q=autossl

I like the idea. My startup started with managed hosting. We use to provide subdomains of customer.company.com domain for each customer to quickly onboard users. Later, when the customer was ready to move to their own domain, we had to ask them to setup A records or provide DNS credentials. The tech stack wasn't too hard for us but hand holding each customer to get the custom domain working was the pain point.

* Will AutoSSL also provide a way for the customer to login and provide them instructions on how they can setup the domain on their side?

* Some of our customers had CAA records preventing LE from working. This is about informing the customer that this record exists and what the possible alternatives are.

* This was mentioned elsewhere but AutoSSL is a cPanel feature. So, I would consider rebranding.

* What are the proxying limitations? Does it support Websockets? How much load can it handle?

Thanks!

> Will AutoSSL also provide a way for the customer to login and provide them instructions on how they can set up the domain on their side?

Yes, I expose two APIs - add and delete. When your customer adds a domain, you can hit our API to whitelist it. The API responds back with CNAME instructions. Your app just needs to pick it up and display it to the users.

> What are the proxying limitations? Does it support Websockets? How much load can it handle?

I have 5 servers right now that handle TLS and fetch content from the origin. I just did a load testing with about 20K requests per minute, and it did fine. Will do more tests as I move forward. But before doing anything just wanted to know if anyone is actually going to use the product. :D

That's an interesting fresh idea in the "auto-renew TLS certs" market. (And the website looks superb!) A few thoughts:

- If I were a service provider I wouldn't wanna be dependent on a third party service for something as basic as TLS certs. I'm not an expert in your domain but to me this looks like something that could happily coexist as a service with a self-hostable (possibly FOSS) option (since the convenience advantage of a service is still there).

- Security: Can you read my customers' traffic? (A self-hosted option could also help with this for high-sensitivity use cases).

- What about rate limits? My customers could be in a situation where the standard LE rate limits are already pretty tight. Can I (and subsequently my customers) see/manage how much quota AutoSSL is using?

>- Security: Can you read my customers' traffic?

Yes, anything that (re)terminates TLS will be able to - including this - and there is no way around it short of hosting it on-prem.

Marketing it as end-to-end security the way the author is doing is ... wrong.

>Can you read my customers' traffic?

Yes they can.

>A self-hosted option

https://letsencrypt.org/docs/client-options/

Aren't those enough options?

Are those fit for the purpose AutoSSL was designed for? Looking over that list it seems like those clients were all built for managing a single (or few) certificates just for yourself. AutoSSL was built for managing your customers' certs (i.e. a lot of them) and I have the feeling trying to use conventional ACME clients (like certbot) in this automated fashion could turn into a shitshow rather quickly.

Read the readme of

https://github.com/GUI/lua-resty-auto-ssl/blob/master/README...

And tell me what this service can do what resty-auto-ssl can't. And there are a lot of different implementations for every language because it is easy.

I've had good luck with dehydrated (https://github.com/lukas2511/dehydrated)

It takes a file with a list of domains to check and you can write your own hooks to handle the DNS management and certificate deployment however you want.

COmpanies buy "security" "turnkey" solutions all the time, why would this be anything different?

All that networking hardware terminating SSL between external and internal traffic can also read all a company's traffic, but I guess Cisco or some chinese manufacturer is more trustworthy...right?

... not affliated with the OP at all.

Some of the security groups at major fort-500 companies I've worked at were run by people that could powerpoint well, graduated from surfing suitcase schools, and showed no awareness of even mass media security failings (heartbleed).

You'd think these divisions would have extremely smart PhD level security folks that could follow the basics of what the attacks used, but they were all just people that did vendor RFPs, made dumb policies (8 char max password, only use approved versions of software that were already out of date and had known vulnerabilities, internal password change site wouldn't show in Chrome because the cipher suite was hopelessly compromised)

A difference between on-prem solutions like networking hardware and outsourced services is that the on-prem solution doesn't phone home (at least not the processed data hopefully).

Different idea though: Shouldn't GDPR data processing agreements cover these sorts of cases?

So, a few comments:

- Branding as SSL is confusing, SSL is dead. TLS is the replacement.

- SaaSes can just front their apps with https://caddyserver.com/v1/docs/automatic-https

- Writeup of a SaaS using Caddy for this instead: https://ohdear.app/blog/how-we-used-caddy-and-laravels-subdo...

There's also https://github.com/containous/traefik (caddy is awesome too)

>SSL is terminated at an edge location that is closest to the users.

So this is routing plain text http for most of the connection and at the same time giving the managed edge location direct access to the traffic and a valid tls cert for the domain? Isn't that mostly snake oil then, as the secure connection never originates from the target service?

Hi.. The TLS is terminated at the edge, and from that point we fetch the data from origin server. As long as the origin has SSL, the communication is secure end-to-end.

>As long as the origin has SSL, the communication is secure end-to-end.

No it isn't. You are doing a MITM.

>As long as the origin has SSL, the communication is secure end-to-end.

It cannot be secure end-to-end, as your edge location is quite literally performing a MITM. That aside:

How are you validating the TLS cert that the origin presents?

Going by the info on your website, the possibilities are as follows:

Scenario 1: The SAAS provider presents a TLS cert not valid for customer-domain.com when accessed as customer-domain.com

Scenario 2: The SAAS provider presents a TLS cert valid for customer.saasprovider.com when accessed as customer.saasprovider.com

Assuming scenario 1, you would need to validate the certificate out-of-band as the traditional trust chain does not validate for the given domain. Assuming scenario 2, you would need to rewrite the URLs from customer.saasprovider.com to customer-domain.com to prevent the users from following generated resource URLs to the origin domain. Or am i missing something?

you're talking about "piecewise end-to-end".

the "end"s are the _browser_ and the _origin_, and if there isn't a single secure channel that goes all the way between them, that's not "end to end".

I mean take the "piecewise" argument to its natural conclusion.

If the reason it's okay for you to be in the middle is that you're going to ensure that your request to origin is also encrypted, why should you be the only party in between that can decrypt the contents of the connection?

Why not let the ISP also decrypt the contents? What about the layer 3 interconnect providers? How about your cable modem and your router (they're _probably_ patched 'enough' that it's safe to let them see your plaintext).

I'm harping because misuse of the term "end to end" is _actually dangerous_ to real people.

All of this is to say nothing of the fact that when you allow "middle-boxes", the client no longer has control over the ciphers that are used for the end-to-end connection, so they lose control over perfect forward secrecy.

you might say,

> but this is what cloudflare does!

yes, and it already caused one of the worst breaches in the short history of the internet https://news.ycombinator.com/item?id=13718752

“vanity” domain? Only big corps are real; all else is vanity?

Seems like yet another betrayal of the end-to-end principle (as is this product for that matter)

Ok - it seems like I need to rephrase the term, but I didn't mean any offence to anyone.

Come on, all domains are vanity.

Good point: we can’t use IP addresses as machines may move but domain names should have been generated at time of request, à la lisp gensyms: G001.com, G002.com. Perhaps randomize the numerical component to avoid gaming the system.

Is it too late to make this switch? Names are sort of like that in China.

Names are like that in China because they are puns and rhymes for Chinese words. It's easier to remember for people who don't know pinyin and quicker to input.

I would have said that the companies who would most benefit of this is also be the company who should not outsource this.

Possible bug report:

From the home page, I click the "Features" link, then press the back button on my browser. It returns a blank white page with the text: "An unexpected error has occurred." No other links seem to do this (probably has something to do with the hash url).

I'm on Windows 10 using the latest Chrome.

Interesting niche. I wouldn't use it because I don't want my customer's web traffic dependent on your edge servers being up, available, and not overloaded with the traffic of your other customers.

Great idea! Wishing you a lot of luck!

"So, I spent a few weeks building an in house solution". That's not a weekend project. So you just stated it was get more attention for yourself... that's little dishonest isn't it?

Some people also use "weekend project" to describe projects that they work on during the weekends. It's a phrase with two notably different meanings.

EDIT: After reading the comment you quoted (https://news.ycombinator.com/item?id=21527011), this doesn't seem to be a personal project after all...

We have actually been using it for our existing product https://hashnode.com/devblog. So, I thought why not let everyone use it? That's when I spent my weekend coding an app that lets customers sign up and add their domains. :)

This makes no sense. TLS termination should be done locally at the site, not at some random server on another end of the internet. It doesn't make any website safer, it is literally a man-in-the-middle.

Also, and not that a bit of competition is bad, but doesn't Cloudflare already provide this service?

Yes, you are right, but that's not their only service and they are CDN first, that is just another service. Also a big difference is that you can install a cert on your server, so the traffic between you and them will be encrypted too. They can still man-in-the-middle you though, but they seem more transparent and security conscious than a one-guy shop.

Yes, starting at $5000 per month...

Reply on news.ycombinator.com