Hacker News Reader

Comment by anonymousguy | Hacker News Reader

HTTPS everywhere is nice... except if your current web host makes free HTTPS hard because they make money from selling certificates.

View on HN

Quick plug for Dreamhost, who have partnered with LetsEncrypt and offer free SSL certificates with their standard web hosting product, easily setup from the control panel: https://www.dreamhost.com/hosting/ssl-tls-certificates/

This is despite the fact they previously made money from selling certificates, and still will take your money for doing so if you want.

(Not an employee, just a satisfied customer who now has free HTTPS hosting etc..)

Thanks for that, I've been on commodity hosting for a while (site5, actually been very happy with them), but they don't offer lets-encrypt, so this is quite attractive.

Same for cpanel, chances are if your hosting uses cpanel you can set it up just by clicking.

And I'll counter this plug with a quick reminder that Dreamiest stores your password in cleartext, as was recently confirmed to me by a support tech.

(All in all, a satisfied customer also, but I ran to the Two-Factor Authentication setup in the panel as soon as I found this out.)

Couldn't you just use "Let's Encrypt" then, unless someone else is hosting the content for you?

Think that's part of it - a substantial amount of the web is on shared hosting (and probably dictated by other areas of the business) and as such wont have any level of root access. Therefore the hosting company can control cert installation and thus cost.

You don't need root access.

We run a cpanel server and have a let's encrypt plugin that allows users to generate and install their own certificates.

Usually add-ons are administered by the hosting company though (?) - so if they want to own the cert purchase/installation flow, then they can certainly do that.

Don't use a hosting company who does that. Take your money and spend it elsewhere.

These hosting companies are already doing enough things "wrong" that if "well, everybody just stop using them" were going to be a viable strategy it would have worked by now for those other things.

We currently do not have the power to change the behavior or the market share of these hosting companies in any significant way. That leaves working around their behavior as the option.

Who said anything about doing it to change their behaviour? Do it because you aren't getting value for money! If there are better alternatives, then use them.

If you have a shell and public I address, you can get a certificate. Root access is only required for Http authentication, you can also authenticate to LE using DNS. I actually just learned about the DNA ability.

Check out Lego project, it makes DNS Auth very easy :)

Extra effort + more computing power, I don't think cheap shared hosting companies are too interested.

It's called "competition". Clients can make sure the ones not too interested become very interested in a few easy steps.

When we are talking about cheap shared hosting providers, the only competition is price and it's driven extremely low.

Competition can only kick in when browsers go crazy about plain text etc.

Well, if the client doesn't care about that warning, why should the provider care?

As I said, there are easy steps clients can use to make their provider care. But if the clients themselves don't care, nobody will.

The performance impact of HTTPS is negligible.

Article from 2010: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...

Not if you have user-generated subdomains, or have subdomains that you don't want to advertise in subjectAltName, or simply just want the full power you used to have with HTTP to use any subdomain you want -- then you'll need a wildcard certificate, which Let's Encrypt won't offer you. Nor will any other free CA, except for CAcert, which browsers will not trust.

The absolute cheapest I've found one of those for is $95 a year. So basically, more than all of my server hosting, my domain hosting, and my domain privacy combined, all to sign my CSR that has a one-character change in it.

Of course, if you want both yourdomain.com and www.yourdomain.com (because just *.yourdomain.com won't match the former), then that will, of course, cost extra. A lot extra.

This is going to sound stupid, but could you have Lets Encrypt dynamically create a cert for the subdomain when the user creates it?

I've heard it's possible, but it would be a substantially increased maintenance burden. You won't be able to put all your subdomains into the subjectAltName section of one certificate, and so you'll need to constantly reload your nginx/Apache configurations to reference all of the different certificates. Plus Let's Encrypt certificates expire every 90 days, and you will have to update all of your certificates before that happens.

I really can't for the life of me understand why they won't offer a wildcard certificate, if you prove you are the owner of the base domain name. The cynic in me expects it's the same reason every CA in existence charges four to ten times more for a wildcard certificate that literally costs them nothing more to make. That entire market would vanish overnight if Let's Encrypt offered them for free. I would even immediately start using them for my site.

I suspect it's both a policy question and the fact that there's not really much of a consensus on wildcard validation in ACME (i.e. how to approach it, and whether it should be a topic for ACME or just a policy decision for the CA).

In terms of policy, wildcards encourage some users to both reuse the same certificate for multiple services (i.e. mail, website, api, etc.), and use certificates that are "broader" than needed (use wildcards everywhere because they're "easier", despite the fact that you only need a certificate for imap.example.com). This increases the impact of Heartbleed-like vulnerabilities significantly (in that unrelated services using the same key are suddenly all vulnerable to MitM attacks). It might not be the worst idea to give the ecosystem some time to get used to non-wildcard certificates in order to discourage that behaviour.

I think there's a good chance we'll see wildcard support sooner or later.

I would welcome key usage constraints to limit a wildcard cert to https only.

But yeah I do hope you're right. I'll switch my domain off self-signing the moment a trusted CA offers a free wildcard cert with elliptic curve signing.

> Plus Let's Encrypt certificates expire every 90 days, and you will have to update all of your certificates before that happens.

I don't see why that would be a problem, given that one of the main points of Let's Encrypt is that it can be automated.

Cloudflare works at the DNS/routing level. You can use their layer to communicate via HTTPS with the browser. The connection between your site and Cloudflare won't be encrypted... which is a bit of an antipattern (as discussed elsewhere).

It can be end-to-end SSL: https://www.cloudflare.com/ssl/

User<>CloudFlare and CloudFlare<>Origin use separate SSL connections, so not quite end-to-end (CloudFlare sees the traffic unencrypted)

Yes it can, but not in the context of the post I commented on.

I once tried to do Let's Encrypt or any free SSL with my namecheap domain and apparently you can't. Is that true? I don't really want to change domain name companies because I'm lazy and it's probably time consuming to get right... can I get free HTTPS if I host my site on Netlify and just point my URL there?

All I use it for is my Jekyll-powered personal site on GitHub pages. I don't mind not using GitHub for it anymore, just want it to work with SSL.

I've got SSL working via lets encrypt on namecheap but don't host using github pages, so can't comment on how you set that up.

GitHub doesn't support custom SSL for pages. A workaround is to change your DNS provider (which is probably Namecheap right now) to Cloudflare and use Cloudflare's free SSL (so it essentially will be an SSL proxy).

You can do this wile still maintaining Namecheap as your registrar, and it's totally free.

In order to do this, you'd need to put an SSL endpoint between your github page and the client. It could probably be done but it sounds like a no-no.

For instance, I'll bet that if you set it up so that your namecheap DNS A entry was pointed to your own box that had nginx/haproxy/cloudflare/whatever handling SSL decryption (and certs) and then backended to your github pages, it would work, but I'm not a fan of the idea.

Domain registrar has nothing to do with the hosting. As long as you can point a domain to an IP address you can get a certificate.

Namecheap even goes a step further and has an API for domain validation (makes LE certificate authorization easier) so they are very friendly in regards to Let's Encrypt.

Yes. You can get free HTTPS for your existing domain by using netlify. No need to change domain registrant.

Let's hope that the pressure is high enough for these hosts to rethink their strategy. If your website has a visible warning and search engines push it back just because of your host wants more money for a certificate that you can get anywhere else for free, you are likely to switch.

This is a common reaction I see from a lot of people. Tech is hard, but the truth is there are a lot of very smart people working on making it easier for everyone.

When something many people/companies do/use/have feels hard or out of reach, I think it's important to start asking different questions and look around for real solutions.

For the sake of an example https://www.cloudflare.com/ isn't exactly hard, and is free.

Cloudflare protects User <=> CloudFlare connections, but doesn't required the CloudFlare <=> Server connection to be secure.

A good reason to look for another webhoster.

Reply on news.ycombinator.com