Hacker News Reader

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.

Is it, because you re-sell?

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.

then you are dealing with the wrong resellers! I can buy a wildcard SSL for $64 RETAIL

https://www.gogetssl.com/wildcard-ssl-certificates/

(these guys also have a reseller program but I don't know what that price is)

Yeah, it sounds like they're in a direct relationship with the CA which only works when you have $10k+ to front for reasonable rates.

Thank you, I will check your rates next time I need to renew my certs for sure!

StartSSL will give you unlimited certs, including wildcard certs for $60/year.

  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.)

Sure, go for it.

Honestly this sounds absolutely awesome. If it packages it all up into the appropriate types of files for nginx and/or haproxy all the better.

Any chance of adding wildcard support? We need that.

We have wildcard support. Just specify a hostname like '*.example.com' when buying a cert :-)

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).

Yup, we create three cert files for every purchase:

www.example.com.crt - the certificate by itself

www.example.com.chain.crt - the intermediate certificate

www.example.com.chained.crt - concatenation of the certificate and the intermediate certificate

Most software, including nginx, takes the .chained.crt file. Apache takes the .crt and the .chain.crt file as separate config options.

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:

https://twitter.com/markloman/status/453502888447586304/phot...

(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.

If you sell a premium service you can charge a premium. The command line feature is worth $5 per certificate for his customers.