Letsencrypt vs paid certs?

[Red Squirrel]

Any reason to use paid certs over Letsencrypt? LE will be providing wildcard certs starting January 2018 so I'm thinking of HTTPSing all my sites/sub domains and everything. Been wanting to do it for a while I just dreaded all the work involved, but wild card certs will make it easier as I only need one cert per domain. Any cons to them, vs the big guys like Comodo, Verisign etc?

 

[XavierMace]

For home use, no. The lack of OV and EVC certs will make them less appealing to pickier businesses, such as banks.

Edit: Oh, the lack of Windows support and the need for domain validation also limits their usefulness as you can't use their cert for internal only domains. They also only issue 90 day certs which is annoying if you're not on one of the platforms that allows you to automate the updates.

 

[Red Squirrel]

Oh this is for websites not home. I rarely bother with SSL for home given I'm the only one on the network. I do find the 90 day cert thing annoying but sounds like the renewal process can be automated. I run Linux for my web server.

My only fear is if they randomly vanish off the face of the internet then I'm dead in the water and have less than 90 days to figure out my situation. But are they fairly decently established at this point that this is not likely to happen?

 

[XavierMace]

You use the term "dead in the water" a lot. I do not think it means what you think it means. If they did vanish, then you just reenable HTTP until you get your cert figured out. It's not like your server just self destructs. You've been running HTTP for however long your sites have been up so it's clearly not a huge issue.

 

[Red Squirrel]

Still means you have to scramble to fix the issue otherwise your sites are all "down" for the time being. (lot of people won't know to just accept the warning)

The goal is to phase out HTTP. So if HTTPS stops working when HTTP is gone then my sites are essentially down until I can intervene.

Though what I might end up doing is just leave HTTP running to be on the safe side. No reason to phase it out completely. Maybe just for the more critical stuff that involves logins.

 

[lxskllr]

It was my understanding that http is meant to be deprecated, not eliminated. The idea is to make encryption so easy, there's no reason to not use it, even for trivial applications, but http should still be usable if desired.

 

[XavierMace]

Still means you have to scramble to fix the issue otherwise your sites are all "down" for the time being. (lot of people won't know to just accept the warning)

The goal is to phase out HTTP. So if HTTPS stops working when HTTP is gone then my sites are essentially down until I can intervene.

Though what I might end up doing is just leave HTTP running to be on the safe side. No reason to phase it out completely. Maybe just for the more critical stuff that involves logins.

You really like exaggerating issues, don't you? LOL.

Worst case scenario, they (the company) magically disappear without warning or notice which is extremely unlikely. You've still got until the cert expires to take care of it. It takes 5 minutes to buy a basic SSL cert. DNS validation is usually a couple hours at most. Done. If your sites are down it's because you procrastinated on doing something proactively. Even if they happened to disappear on the day all your certs happened to expire, your sites still aren't down, your users will just a get a cert warning.

404: Scrambling not found.

 

[Red Squirrel]

It would take more than 5 minutes. Would still need to google how to install it, and figure all that too. There's some cert stuff that has to be generated on the server too I think. CSR or something like that? I forget all the steps but it's still decently involved. Then repeat for each domain/subdomain. But yeah I guess the odds is small that they vanish, it's just a concern having to rely on a 3rd party. I guess the same issue could happen with any provider though. I imagine I can probably set up some kind of alerting system to alert me if a renewal fails. I'd probably renew like once a week or something so that if something DOES happen to the site then at least I have a few months to figure out what I do. One thing I do like about LE over the other providers is it sounds like the whole renewal process is automated. With the paid ones everything would be manual, and there is the risk of downtime if I did something wrong when I go to restart the server.

Probably going to go with LE. I'll just wait till they announce wildcard certs as that is going to make things way easier than having to set it up for every single sub domain.

 

[XavierMace]

We're talking about if the company randomly disappears in the future after you're already using their certs. Therefore you should already be familiar with the installation process at that point. And no, installing a basic SSL certificate is not decently involved. If this is this big of a deal for you, you shouldn't be running web servers.

Like I said, you're making mountains out of molehills.

 

[Red Squirrel]

Like I said, you're making mountains out of molehills.

No, it's being aware of possible points of failures. Something lot of people fail to do, and then their site goes down for hours or even days because of something they did not think was possible. My point was I just need to be aware of it and come up with a good contingency plan.

 

[Skunk-Works]

If they did vanish, then you just reenable HTTP until you get your cert figured out.

Not true. If the server has HSTS (I think it's called) then the browser expects the site to be encrypted, and if not will fail until the time set expires. Recommendation is 6 months.

OP, if you go to the LetsEncrypt website, you'll see that they are backed by some big names. So the likelihood of them going away isn't going to happen anytime soon.

 

[XavierMace]

No, it's being aware of possible points of failures. Something lot of people fail to do, and then their site goes down for hours or even days because of something they did not think was possible. My point was I just need to be aware of it and come up with a good contingency plan.

Understanding the cert needs to be renewed is "being aware of possible points of failure". Acting like needing to replace standard SSL certificates on websites you've been hosting without HTTPS for ages is a big deal is making a mountain out of a mole hill. I told you it's a straight forward process. You're welcome to go look at Stack Exchange, Server Fault, etc, who all agree it only takes a couple of minutes. You then argued it's not that straight forward but you'd have to Google how to do it which implies you've never done it and therefore have no basis to argue from. Generating the CSR on a Linux box is a single shell command, then you fill out what basically amounts to your shipping details. If you've got even a mediocre typing speed, this takes 2 minutes. It's a quick, painless process for standard SSL's as long as you do it before it expires. Even if you wait for it to expire, that doesn't make it any more difficult to renew, it just confuses/worries your users. Now, if you want to talk about trying to renew/replace an BV/EV in an emergency, that's a different story. But since Letsencrypt doesn't offer BV/EV certificates, that's moot.

Not true. If the server has HSTS (I think it's called) then the browser expects the site to be encrypted, and if not will fail until the time set expires. Recommendation is 6 months.

OP, if you go to the LetsEncrypt website, you'll see that they are backed by some big names. So the likelihood of them going away isn't going to happen anytime soon.

Yes it is true. As far as I know this is for websites he's self hosting, therefore he can configure the server however he wants. Even if he's not self hosting, I'm not aware of any shared hosting provider that enables HSTS by default.

 

[Skunk-Works]

shared hosting provider that enables HSTS by default

I use Cloudflare to accomplish that. So if one uses Cloudflare you'd have the option.

 

[XavierMace]

I use Cloudflare to accomplish that. So if one uses Cloudflare you'd have the option.

OK? And what's preventing you from turning it off?

 

[Skunk-Works]

OK? And what's preventing you from turning it off?

Why would I do that? And if you do, all of the browsers that connected to the site won't work as they cached the HSTS setting. The browser is expecting the connection to be encrypted.

 

[Red Squirrel]

Actually once I do move my sites to HTTPS what is normally the proper way to redirect. Can I just do a HTTP 301 redirect with mod_rewrite? I also need to read up on SMI since I don't want to use an IP for each domain as that is just wasteful. Downside is not all browsers support that but any real browser should. I honestly don't care about IE, my target audience are most likely using a real browser anyway. Hopefully my version of apache supports it. CentOS tends to be super behind.

 

[Skunk-Works]

If done right, your site should serve the HTTPS address on click of the HTTP address. You can do this in htaccess to force all HTTP to HTTPS.

 

[Red Squirrel]

Yeah I am asking how I "do it right" . 301 redirect seems to be the way to go though based on some quick research.

2018 for me is the year of HTTPS. It's about time I start converting my sites. I was reluctant at first as I hate the idea of paying for certs and they are rather expensive when you have a lot of domain/sub domains but with Letsencrypt it's free so may as well do it.

 

[XavierMace]

Why would I do that? And if you do, all of the browsers that connected to the site won't work as they cached the HSTS setting. The browser is expecting the connection to be encrypted.

Because OP is worried about his cert expiring or being revoked and apparently feels that just getting a new cert isn't a quick thing.

 

[Red Squirrel]

I don't know why you're making such a huge deal out of that. It's a valid concern when the certs don't last a full year. Although I'm still going to go with them as it's free. It's a low risk, but it's still there. Given once it's setup it's mostly set and forget it's not like I'll remember the steps I did, so no, it's not "only 5 minutes" if I had to do it all over again, and I presume each provider will be different in how it's setup such as what openssl commands to run, and and what files go where etc. Any time I setup a self signed cert for something I have to research the steps such as the commands, and what file goes where etc, because it's not something I have to do every day. I'm so sorry I don't have 100% perfect memory.

Reading up further on LE now, what IS nice is they seem to have an API that automates a lot of that stuff so once I set it up I should not need to worry, as long as their servers are up. At this point they do seem to be quite big so doubt they are going anywhere. If anything we might start to see more similar services sprout up. There's no reason why certs should cost so much money.

 

[Red Squirrel]

Yay so I got LE to work. They have a tool called certbot that does most of the work for you. I could in theory HTTPS my entire webserver in one go but I don't feel comfortable doing that just in case something goes wrong. I did backup my config of course. Did a few domains. It also offers the option to auto redirect but rather leave that out for now as I'll do it manually when I feel that everything is working great, I want to let this go for a while so I can ensure my auto renew script will work etc.

Right now I HTTPSed these domains:

https://3.14.pizza
https://www.iceteks.com

Kinda pointless to SSL sites that don't handle login info, but given it's this easy and free I may as well do them all.

 

[Red Squirrel]

Oh and for future reference, either for myself or anyone that reads this, you need to put this in your main apache config file (before your virtual hosts, I imagine)

SSLStrictSNIVHostCheck off

This as far as I know, is what enables SMI, which is required to hosts multiple SSL domains without having to use an IP for each one. Some browsers may not support this though such as older versions of IE.

Most Letsencrypt/SSL tutorials don't really mention this. I found it by chance, as I had previously read on how to enable HTTPS for more than one domain on same IP and found out about SMI.

 

[Ken g6]

https://www.iceteks.com

This server could not prove that it is www.iceteks.com; its security certificate is from iceteks.net. This may be caused by a misconfiguration or an attacker intercepting your connection.

 

[Red Squirrel]

I realized this after. It seems I can't do iceteks.com and iceteks.net it's one or the other. Weird. They don't all have the same sub domains so I can't just do a simple redirect.

Oddly enough the subdomain at iceteks.net that I do want to secure is working but not iceteks.net itself but now iceteks.com works.

I think to simplify things though I will just HTTPS everything under the one domain then I can just do redirects from all the others.

Everything I read says to use mod_rewrite for redirect, but would it not be better to do this instead?

redirect 301 / https://www.example.ca/

The HTTP 301 status is important as it tells search engines to index the new location and update listings, at least I think?

 

[Red Squirrel]

I think I mostly got all this down path now. I decided to go ahead and force the direct on all my iceteks domains. I also fixed the discrepemcy between .net and .com. Part of the issue was I had decided at one point that the .net domain was for "network" stuff like name servers, back end admin panels, that kind of thing. I had a self signed cert which was used specifically for only one sub domain. But the top level was still just an alias to the main .com site. Had another few oddities like that. So it caused issues when I tried to secure both separately. I just made it so all the sub domains match across the board and everything just directs to .com. So now iceteks.us iceteks.net iceteks.com iceteks.ca iceteks.info etc...... all go to https://www.iceteks.com. Same with sub domains like forums etc. I only did .com and .ca for those sub domains and kept the .net ones that were already there. Mostly just semantics a this point. Main thing is I seem to have got it fully working now. You can't https to the other domains but if you http you get redirected to the https .com one. Good enough for me.

Going to sit on the other domains before I officially force them to https to make sure my renewal script is working properly and that there is not something I missed. It's too early right now to do an actual renewal but think it lets you renew at the half way point or something like that. I'm pretty sure it's going to work but just want to play it safe.

I'm implementing a single sign on system for my forum that will work across some custom applications too, so it will be nice to actually have SSL. Not sending passwords in clear text over the internet, imagine that. It's about time I set this up.

The only weakness in my idea of single sign on is one particular application I have in mind will be sending it in clear text, but I have an idea for that. I'll probably allow users to set a separate password for different applications if they want to. May even experiment with two factor auth at some point.