So...
Why's The Reg still holding out?
The Let's Encrypt project has opened to the public, allowing anyone to obtain free TLS certificates and set up HTTPS websites in a few simple steps. It's a major leap forward in encrypting the world's web traffic, keeping people's information and browser histories out of the hands of eavesdroppers and and other miscreants. …
Yes, it would be nice if {accounts|forum}.theregister.co.uk were TLS'd. Thing is, the cookie is carried over to the www site too, it appears. Our techies are working are hard as they can.
As for the ad networks – we use a mix of them. Not all of them do HTTPS.
Believe me, we do want to get encrypted.
C.
Explained in another thread, but for a TLDR: ensuring the infrastructure can work under TLS, mainly - not "only" ads.
True, we'll likely get a smaller pool of ads able to be served under TLS, but that's not all that important.
Tech-wise, it's important that the user experience doesn't break if people use things like HTTPS Everywhere, or if one day we pull the HSTS trigger. And since a lot of commentards are the tech-savvy kind which try to - and do - break things or do unconventional stuff, we ought to be very well prepared.
If it were as easy as pushing a button, we'd have done it donkeys ago.
Thus, Soon®
Been waiting for this to go public, ever since i first read about in on El Reg, many moons ago. T'will save me having to explain to the couple of people I host sites for that the "self signed certificate" error they see when logging into WordPress admin [I know!] are nothing to worry about.
Off to try it now.
Don't get too excited. Great in theory but most of us use control panels to administer our websites. They already have facilities to manage cerificates and those will mostly not match up with the client here which has the deluded belief that it, and it alone, should control your apache configuration files. It don't and the configuration file will likely be overwritten by your control panel when you do something else - breaking your https installation. That basically KOs your sites.
You can do it manually but then you have remember to renew the certificate every 60 days which makes this somewhat more of a bind(!) than the existing free providers albeit my favourites are Russian & Chinese.
When your chosen control panel integrates Let's Encrypt ito its system it will be great but until then it may be best to wait.
I have a wildcard cert through COMODO for my colo'd server, runs maybe $150 a year or something(the cheapest one I could find) I forget, works fine for desktop but my android devices don't like it, so I have to install the cert on them to get them to trust it. There is a more expensive wildcard cert option through COMODO last time I checked which I bet had mobile support I just didn't want to pay that for my personal server (and I didn't want to use self signed since I give https links to other people and don't want the warnings to pop up etc)
So hopefully this service has a CA that is mobile-trusted.
Android wont like it because of your Cyper set-up on your server you need to sort that out, searching on Google for your server type ie Centos SSL Cipher Suite will yield the results you need. This site will show what works with your current SSl https://www.ssllabs.com/ssltest/
> I have a wildcard cert through COMODO for my colo'd server, runs maybe $150 a year or something(the cheapest one I could find) I forget, works fine for desktop but my android devices don't like it
Are you sure you don't need to install an intermediate CA cert in the server?
It is possible to run Exchange with 4 separate certs, instead of one cert with 3 SANs. You just have to make sure to load all certs and assign each cert to its own proper function. So much more work, but should be scriptable in ps.
Although I don't know lets encrypt schedule for windows client, I'm sure it is being worked on.
Those of us required to use Windoze appear to be out of luck
Cygwin might work, I guess, but easiest is probably to download a small live Linux distro and run the script in there. I don't suppose the script will produce configs for IIS or whatever you're running though. Still, you should be able to manually install the cert.
Anyway, some sort of live Linux distro (like Knoppix, especially) is a good tool to have handy even in an all-Windows shop. Using it to reset a forgotten admin password or removing a corrupt page file are a couple of applications that come to mind.
Which is all well and good but from their own words they wanted to make the whole process as simple and straightforward as possible. Installing a bunch of extras including unfamiliar languages isn't ideal nor line with how easy they're making it out to be.
(Also it's a tad difficult to run a live cd on a server in a bit farm without direct access to it or annoying customers with downtime)
@Sgt_Oddball:
I suggested a live CD so that you don't have to install anything. Maybe some packages need to be downloaded (into RAM), so it might take longer, but I'm sure it's all in the READMEs.
As for doing it on a server: don't! Stick a USB key into your laptop or whatever spare PC is to hand, boot from it, do the stuff needed to generate the cert and then copy it onto the secure server. It's not like you're going to be running this stuff (or any other configuration experiments) on a live production server, is it?
"Why would anybody want to run a web server on Windows ?"
About 1/4 the risk of being hacked versus a Linux system as it's relatively secure out of the box, and is much easier to admin / manage, has better performance for most uses on the same hardware with the latest Windows versions and has far simpler corporate integration.
Am I correct that this means handing out HTTPS certificates without verifying true identity, and without identifying ownership of the domain?
Customers use HTTPS not just for encryption but to identify that they are on an organization's legitimate website (bank, government, etc.), and not some imposter website.
If I'm correct in understanding that these certificates are being handed out without identity verification then public trust of HTTPS will soon be in jeopardy.
Oh come on, you can't really expect anyone to trust a root CA if it handed out any domain certificate to anyone? This isn't a back street operation.
If it is going to get allowed onto the trust list of all the major vendors then it has obviously got domain validation. It won't have EV where it checks your company, just that the domain is authorised.
See here if you want the technical details: https://letsencrypt.org/howitworks/technology/
Let's Encrypt verifies ownership of hostname by exchanging plain HTTP messages with content / paths unique enough, against the server you want to install the certificate on, and using the hostname you want the certificate for. So, either you are permitted to run your own script in the context of webserver to allow the exchange to succeed, or you are not. In the former case you are granted certificate for hostname (not organization, it is not part of the exchange, nor is in the certificate). In the latter case you cannot get the certificate.
It takes very little to use "very alike" names on servers you fully control and get a certificate for it using Let's Encrypt, I'm afraid.
The problem is "encryption" is just a proper subset of "security". There are other critical needs which Let's Encrypt doesn't fulfill - the main one is true "authentication", which is a basic features of certificates - they are called that name because they are more than "encryption keys".
I guess I'll remove Let's Encrypt CA from my systems because I will want to be notified of any cert from them.
You can get ssl certificates from many resellers (eg gandi) with the only requirement being proof that you control the domain by hosting a specific file at a specific path or adding a specific DNS record. In that respect lets encrypt is no different (other than the automation)
Well, domain certificates have never verified identity well -- the CAs are not qualified to make legal trademark decisions, for example. (Who is to say that Banko Famerica is not a perfectly common name in Whateverland?)
And as to control of the domain: I've not looked at the protocol yet, but I'm assuming you need to have DNS records in place and pointing to the IP the client is running on for every domain name you want in the certificate at the very least. (People with load balancers are big enough to pay, I'd guess.)
Still, the possible implications for shared hosting and dynamic dns are interesting. Time to pin your certs, I guess.
"Do you honestly believe that spammers are going to come after every individual with an e-mail inbox?"
Why, yes, I believe spammers will go after every inbox for which they can get an address. But, then, spam is practically free and doesn't involve voluminous court filings, so there ya go.
I'm amazed at how many banks need to contact me about security issues with my account that must be addressed immediately! If only I could remember when I established those accounts...