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?
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.
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.
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.
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?
> 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?
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?
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.
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.
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.
>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.
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?
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.
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.
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).
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.
"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?
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.
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.
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?