The state of things really does suck, and I'm trying to do something about it.
SSLMate [https://sslmate.com] sells SSL certs from the command line for $15.95/year. The sslmate command line tool takes care of properly generating the key and CSR, and properly assembling the certificate bundle containing the chain certificate. Certificates secure both example.com and www.example.com. No more hard-to-use websites or obscure openssl commands. I'm working on a config file generator too, so you'll be able to specify your server software and it will output a secure config for you.
And since the author mentioned out-of-process SSL termination, I'm also the author of titus [https://www.opsmate.com/titus/], an SSL terminator that is so paranoid it stores the private key in an isolated process (which would have been impervious to Heartbleed). It also solves the original IP address problem by using Linux's transparent proxy support - your web server sees the client's actual IP address even though the connection was proxied through titus.
Shut up and take my money. I had to jump through so many hoops when I setup SSL about a year ago that I almost just gave up. I have your site bookmarked and next time I need to setup SSL I will be using your service. It looks really easy and how I would expect SSL certs to work.
Why o why do you charge almost ten times for wildcard certs? A wildcard cert is technically identical to non-wildcard certs - only one single parameter is different.
Yes, we do resell and that's just how certificate authorities price things.
If you have fewer than 10 hostnames to secure, definitely go with individual certs and use SNI instead of a wildcard cert. Support for SNI is quite widespread now, and SSLMate makes managing lots of certs easy.
Do you sell Extended Validation (EV) certs?
No. The long and complicated approval process for EV certs
does not work well with the SSLMate model, which emphasizes
quick and simple SSL purchases from the command line.
Planning on changing your mind anytime soon? I'd like to switch to you, if just for automatic renewal, but the boss wants an EV cert.
Does SSLMate sell SHA-2 certificates?
Not yet, as our upstream certificate authority has
incomplete support for SHA-2 certificates.
We expect to add full support for SHA-2 certificates in Q4 2014.
Yes, actually, I've been contemplating offering EV certs, and have some ideas for making it work well with the SSLMate model. I do understand the boss factor. Do you mind if I shoot you an email at the address listed on your website?
And I know it's lame about the SHA-2 certs, but my hands are tied for now. We're not selling any SHA-1 certs that expire after 2015 so we're not running afoul of the deprecation schedule set by Google. (And if you do buy an SSLMate cert, we can reissue it as a SHA-2 cert but it's a manual process.)
Amazing. What about the proper file creation? (Although that's not that hard with a couple of calls to "cat" but getting the order right is hard for people who haven't done it before).
I hope we see more key isolation going on in the near future even where titus is overkill. Process-per-connection tends to cross the cost-benefit threshold for high-traffic/low-to-medium importance stuff, but key compromise is a giant pain in the ass no matter what you're doing.
On the other hand, if you want to go further into tinfoil-hat territory, find a way to isolate each process in a separate container. :) (Bonus points: Tear down/rebuild the container for each new connection.)
There's definitely overhead to the process-per-connection approach, but I disagree that protecting the key is more important then protecting the state of the connection. A private key is just a means to the end of securing a connection, and what terrified me most during Heartbleed wasn't the private key compromises, but the fact that it exposed private user data like passwords:
(there was probably other sensitive content like emails in that dump too)
This kind of information is far more useful to attackers, since it can be used immediately and independently, whereas a compromised private key is only useful in conjunction with an active MitM attack (if forward secrecy is used) or a passive eavesdropping attack (if forward secrecy is not used).
As for containers, titus is already using a lot of container-like techniques, such as filesystem and network isolation, and I plan to use PID namespaces in a future version. So it's probably already deep in tinfoil-hat territory ;-)
I'd be willing to take the hit for the login process itself, but for most of the other stuff I care about, the biggest concern is MitM -- users need to trust that the (mostly non-personal, non-confidential) data they're receiving actually comes from me.
Good point about serving non-personal, non-confidential data - in this case, there's no benefit to the process-per-connection model, but there is still a benefit to isolating the private key. Unsure how you could easily separate out the login process from other pages on the site. I think you'd need to use separate hostnames/IP addresses and an SSO-like system.
Sure, but that's already a requirement for a lot of applications, and a lot more can be handled just by setting '.example.com' cookies if they don't have any untrusted subdomains.
Late edit: Ultimately this all comes down to a more general desire for better tools for segregating data and APIs into appropriate security domains. It's still way too much work, especially for small teams, to separate things into appropriate security domains with appropriate tradeoffs.
SSLMate solves a huge problem for me, specifically `download --all`. I've been trying to figure out a good workflow for building a docker-based deployment system but I kept getting stuck on how to manage certificates. I'm going to start using this the next time I have to generate a cert, for sure.
Why do SSL cert vendors sell the same things at different prices? For example, I've used these guys before https://getssl.me/ and they sell one at 9.95.
SSLMate [https://sslmate.com] sells SSL certs from the command line for $15.95/year. The sslmate command line tool takes care of properly generating the key and CSR, and properly assembling the certificate bundle containing the chain certificate. Certificates secure both example.com and www.example.com. No more hard-to-use websites or obscure openssl commands. I'm working on a config file generator too, so you'll be able to specify your server software and it will output a secure config for you.
And since the author mentioned out-of-process SSL termination, I'm also the author of titus [https://www.opsmate.com/titus/], an SSL terminator that is so paranoid it stores the private key in an isolated process (which would have been impervious to Heartbleed). It also solves the original IP address problem by using Linux's transparent proxy support - your web server sees the client's actual IP address even though the connection was proxied through titus.