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"
}
}
In addition to "http" (described in this thread) we also support "cname" and "email" methods for validation. Some of our customers prefer these other methods as it lets us issue the certificates before /their/ customer points the CNAME over.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"
}
}
Where $MYCERT and $MYKEY are the PEM payloads with newlines removed.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) ;)