This an issue all the way from individuals with crappy or misconfigured DNS locally to whole TLDs (fortunately no really major ones) with non-working DNS. But it's often a teachable moment, something others can learn from.
Basically with the DNS challenge, we had to send people away to make DNS changes, have them come back and confirm they were approved, and then we sent them away _again_ to make another DNS change. It was kind of brutal.
(edit: we also tweaked the article to not imply "broken"!)
Having DNS validation as an option is very useful, as not all certificates are used for http servers (think smtp) but not trivial to implement.
Also wildcard certs will require DNS validation.
It’s essentially a reverse proxy as a service. Sort of like Cloudflare but with what looks like a nicer API, and custom domain name SSL eg. for multi tenant apps.
It was a bit pricy when I plugged in how many requests we get per month on our servers, easily in 5-figure per month. Having said that, internally we built most of their selling points already.
POST https://api.cloudflare.com/client/v4/zones/:zone_id/custom_hostnames
{
"hostname":"app.example.com",
"ssl": {
"method":"http",
"type":"dv"
}
}
Once we receive the call we generate multiple certificates for each hostname: one SHA-2/ECDSA that's presented to modern browsers and one SHA-2/RSA that we serve to legacy ones that don't support ECC. (Let's Encrypt doesn't do SHA-2/ECDSA signing yet but plans to sometime next year.)
We also support uploading your own custom certificates for those that, e.g. see value in Extended Validation (EV):
POST https://api.cloudflare.com/client/v4/zones/:zone_id/custom_hostnames
{
"hostname":"app.example.com",
"ssl": {
"custom_certificate": "$MYCERT",
"custom_key": "$MYKEY"
}
}
There are a bunch of companies who've done most of what we've exposed in house (us included in past lives!), once we're a bit older and more fully developed I think we'll have compelling features even for you though! We do have deep volume discounts, fwiw, so if you get tired of running all that stuff let us know. :)
Now, I get that free is not an option. 50/100$ a month is probably OK. But that's beyond reasonable. And prices change depending on where people visit you from (!?)
It's really expensive to do that on top of CloudFlare, and most apps like that aren't using a tremendous amount of bandwidth.
We're not _yet_ a great option as a general purpose CDN replacement (both pricing and featureset) but we're getting there, and are pushing prices down continuously. It's more expensive to buy bandwidth and power in certain cities, too, hence the different pricing per region.
If you're willing, I'd love to know what your traffic breakdown is and how you got to that $1200/mo number. You can email me if you'd like! (kurt.mackey@fly.io)
Clients want an SSL server and it lets me set it up in 10 minutes without additional costs.
Fully automated, no cronjobs to fail. In addition, I have a monitoring on all LBs that verifies the expiration time - it has never hit so far. That cronjob/monitoring is something everyone should have anyway because a well working monitoring system can alert you to so many other possible failure states...
Video link: https://www.youtube.com/watch?v=oYelZided-E https://www.manageengine.com/key-manager/
Disclaimer: *I work for ManageEngine
I’ll let tls certificate slide but ssl certificate just triggers me too much.
The title is perfectly fine for its purpose.
First, thanks to the terminology used by almost all commercial CAs, "SSL Certificates" is still the most commonly known term for that. Like it or not, but if you want to reach a wide audience, you need to say SSL in addition to TLS.
Second, even fewer people know the term X.509, insisting on that is like insisting on saying RFC-7540 instead of HTTP/2.
Third, in the very first sentence the article sets everything straight:
> We've been hard at work making Let's Encrypt TLS certificates as simple and safe as possible for developers and creators of all kinds
So ... is this an instance of commenting before actually having had just a tiny look at the article?
"If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week."
There's only one step required by the customer which is to point their DNS to Clearalias, no API calls or extra set up by the app or the customers.
The API is mainly for people who'd like to automate the process, because they want to provide custom domains for their customers (so more for B2B use-cases) ;)
I don't mind offering 90 day certificates, but requiring it goes against the offered reason of LE to expand HTTPS.
Is this really more stable than a simple cronjob? It is far more complicated, for sure, so there should be significant benefits to make up for that.
I'm curious as to how you get certbot to renew automatically without a cron job or some sort of script in the Docker container that periodically runs 'certbot renew'.
For others who are reading this, the whole process involves reading and storing private keys using asymmetric ciphers and all that. Definitely more stuff than we’d like to be responsible for.
Will definitely keep an eye on fly.io for new features! Thanks
Since we control the http response once DNS changes, we don't have that problem. And it's simpler for people to create CNAME/ALIAS records.
Why not have them create a DNAME, a delegation, or just two CNAMEs?
The http-01 challenge is simpler, we can get people setup with one CNAME/A-record.
Once we're serving traffic, we can do all renewals with an http challenge and they don't need to change DNS ever again.
What makes you think that CNAME or DNAME records are specific to A or AAAA records?!
(Obviously doesn't work if they are to keep control over other subdomains of theirhostname.theirdomain, and also, I haven't tried it with DNAMEs, so I don't know whether their implementation is buggy.)
I mean, assuming you do know that CNAMEs are a thing, this reads to me like "well, yes, HTTP can do redirects, but I didn't know you could also redirect requests for images!" ...
I guess what I am wondering is: What is/was your mental model of CNAMEs that they could redirect DNS resolution, but then it's somehow surprising that they can redirect DNS resolution!?!
CNAMEs are not a feature of application software, but rather a mandatory part of the DNS specification that any standards-compliant resolver has to implement. As they claim to be using DNS, that obviously implies the claim that they implement what the DNS specification defines, and that would necessarily include following CNAMEs.
Another part was that I've never read the dns rfc and honestly I've only ever spent enough time messing with dns until it worked. And I've never seen a CNAME for a record that's resolves to anything but A (or AAAA or another CNAME). So I suppose it was a combination of a failure of imagination, lack of knowledge, and lack of experience. Or maybe, "I dunno I never thought about it".
But now I know! CNAMEs work for all records regardless of type, forwarding the entire lookup elsewhere, which I guess is why they require no other records exist with that name. Pretty cool.
I suppose I could have learned that with a bit less incredulity but hey, it got me here in the end. I guess a link to the RFC might be relevant here [CNAME 1]. I'll probably look through it later, maybe there's some other cool features I didn't know about.