SSLMate – Buy SSL certs from the command line | Hacker News Reader

SSLMate – Buy SSL certs from the command line

sslmate.com

118 pointssleepyhead67 comments

Take a look at https://letsencrypt.org/ which will (mid-year) let you get a cert from the command, for free!, and automatically renew it as well.

If ever there was proof that "someone out there has the same idea as you" is true, this is it; I've been conceiving an open to audit public, free CA for the past couple of weeks.

It looks like my dream is coming true!

Is this live? It says it's coming 'mid 2015', and the standard (Ubuntu 12.04 LTS, I believe) repos don't seem to have any mention of it.

Edit for anyone else curious about this: No, the letsencrypt CA isn't ready yet; there are test builds available for all of the software, but any certs you get will not be properly signed, and your users will get nasty browser warnings. Something to keep an eye on in the future, I guess.

No, it is not mid 2015 yet.

Hence the edit, man.

Why do you consider Ubuntu 12.04 standard? 14.04 is the most current LTS release.

Why are wildcard SSL certs so expensive? I want to use SSL certs on my personal subdomains, but they are usually priced at around $150/year at least. I hope let's encrypt will support multi or subdomains.

StartSSL offers as many wildcard certs as you want for a low fixed yearly fee (50$)?

Multiple name certificates are included in that too, which is handy if you have several distinct domain names, limited IPv4 addresses, are worried about ancient browsers that don't support SNI. I have a single certificate that covers a couple of domains that way. Saves on admin too (though could be a pain if the PK were ever compromised as every service would need to be updated - if you have separate certs for everything and one is compromised you don't have that complication).

StartSSL is very much "you get what you pay for", though. Their web interface is sporadically unreachable, and their validation is rather sloppy – as long as you pay up, you can happily break their terms of service and still be re-validated.

I never understood how that matters, though. My visitors will see a green bar, job done. Breaking the ToS or not, I don't care as long as my address bar is green. How is Verisign any different from StartSSL, in that regard?

> I never understood how that matters, though.

It will matter if StartCom is abused to print certificates for foreign domains. Even if your domain isn't targeted, browsers and OS vendors will probably react by invalidating all StartCom CA certs. That means no green bar.

Has this ever happened before? I'm genuinely curious, as I've heard this warning often but it seems more like FUD than anything else.

Google just removed CNNIC as a trusted CA from Chrome because of their sloppy security and trust.

CNNIC had provided "unauthorized digital certificates for several Google domains" and in an update on April 1st Google said that "To assist customers affected by this decision, for a limited time we will allow CNNIC’s existing certificates to continue to be marked as trusted in Chrome, through the use of a publicly disclosed whitelist" - http://googleonlinesecurity.blogspot.ro/2015/03/maintaining-...

So, I doubt they would treat StartSSL any worse than they treated China.

Can you link to this? I wasn't able to find info about this fixed yearly fee plan on their site.

Looks like it's only a one time fee? of 60$ here are some links: https://www.startssl.com/?app=2 as well as this answer: https://www.startssl.com/?app=25#27

A friend of mine got validated and he send me signed and working wildcard cert with multiple domains a few days ago - so it's a real thing I believe.

they will not support wildcard domains. you can create a cert per domain though or one for multiple subdomains.

You mean I can issue multiple certs at each subdomain separately instead of one wildcard cert? That's promising. It's also OK on my personal use.

Bugger. I was really excited for Let's Encrypt specifically for the possibility of a free wildcard cert.

I was thinking of building an app which would be under two domains like heroku.com/herokuapps.com and github.com/github.io and I rather not spend hundreds of dollars on two wildcard certs. Guess I'll just buy one and not use subdomains on the main site.

You can get a certificate covering multiple specific domains. https://github.com/letsencrypt/lets-encrypt-preview/issues/6...

A wildcard cert wouldn't cover both heroku.com and herokuapps.com anyway. https://en.wikipedia.org/wiki/Wildcard_certificate

They said they'd rather not spend money buying two certificates.

Certs from Let’s Encrypt will be free.

My initial reaction would be that is just stupid, but is there a good reason for that refusual? It is usually as a way to make money, but in this case?

I've picked up wildcard certificates signed under AlphaSSL for around $50 on sale in the past. For personal projects the acceptance is decent.

The price of Wildcard SSL certificate is a bit expensive because multiple sub-domains are secured with single certificate.

For a large business with multiple sub-domains (mail..com, blog..com, info..com, anything.com, etc...), if the business purchases individual SSL certificate for each sub-domain it need to spend more money, and the process will be so long as generation of new CSR, private key, certificate installation, etc...

A Wildcard SSL secures unlimited sub-domains which saves time and money as well.

$150 is much higher for a wildcard SSL certificate, Visit CheapSSLSecurity (https://www.cheapsslsecurity.com) where you can get Wildcard SSL certificate at $60/year for Domain Validation and $108/year for organization validation.

$42 wildcard ssl - http://community.spiceworks.com/topic/539962-wildcard-ssl-fo...

This is really interesting. It's very annoying to always fire the browser the renew/buy a certificate. I would definitely git it a shot for a standard one, the wildcard looks quite expensive honestly. In other sources you can find it at half-price with promo codes.

This looks interesting. Couldn't figure it out right from the FAQ: If SSLMate is a single-command buy & install, where do the certificate details (company name etc.) come from? From my profile on the website?

For domain validated certificates those details are often ignored, only the domain name is part of the final certificate.

If you want a company name, you need an EV certificate.

Domain Validated (DV) certificates (the free ones, or cheap in sslmate's case) are just proof someone - we don't know who they are - has control of a domain. Hence Domain Validated - someone did something to prove they had control of the domain and was given a DV certificate.

They don't include your company name, company ID or physical address in the subject because there is no requirement for the CA to verify those things. Here's HN's DV certificate:

https://certsimple.com/images/blog/non-ev-subject.png

Now visit http://github.com - who have an EV certificate. It shows 'GitHub Inc' in a green bar on every web browser. Click the green bar, and compare the certificate details:

https://certsimple.com/images/blog/ev-subject.png

- you can actually see GitHub's registered in Delaware, with company ID 5157550, which matches their state registration: http://businessprofiles.com/details/github-inc/US-DE-5157550

- you can also see GitHub's office in San Francisco

That info has been manually verified by a CA - that's the extended validation in 'EV' - and that's why browsers show 'GitHub Inc' in green.

You can also see the difference using openssl:

    openssl x509 -in example.com.crt -noout -text | grep Subject

DV cert:

    Subject: OU=Domain Control Validated, CN=billing.example.com
           DNS:billing.example.com, DNS:www.billing.example.com

EV (green bar with company name) cert:

    openssl x509 -in example.com.crt -noout -text | grep Subject
    Subject: 1.3.6.1.4.1.311.60.2.1.3=GB/businessCategory=Private Organization/serialNumber=09378892, C=GB, ST=City of London, L=London, O=example Limited, CN=billing.example.com, DNS:billing.example.com, DNS:www.billing.example.com

Disclaimer: I sell EV certs at https://certsimple.com. I specifically /don't/ sell DV certs, and we send people to https://letsencrypt.org if they really want a DV cert.

"Single server EV certificates are $469, multi server name certificates are $769. Both last two years."

Why do you charge 300$ for 2 characters? Like the "*." for a wildcard cert?

Our prices fall somewhere in the middle of the market: much less than Symantec, a little more than Comodo. We're faster than all of them. Each server name is manually verified by a human.

Wildcards are explicitly banned by browsers and CAs when making the EV requirements: otherwise you get *.company.com being used for bankofamerica.com.company.com like what happened with DV certificates.

See https://certsimple.com/blog/wildcard-ev-certificate

Edit, replying to BukhariH due to rate limit: that's an excellent question, and illustrates why server names are manually reviewed by a human. A company called 'Company' who asked for an EV cert for bankofamerica.com.company.com would be rejected during validation.

"Wildcards are explicitly banned by browsers and CAs when making the EV requirements: otherwise you get *.company.com being used for bankofamerica.com.company.com like what happened with DV certificates."

That doesn't make sense because the whole point of the green badge is that it shows the identity of who controls the website you're on.

So, even if someone were to do: bankofamerica.com.foobar.com; the green badge wouldn't say "Bank of America Corporation" so the user would know they're not on BoA...

The main intention is that the CA is able to run its own phishing checks on every (sub)domain and deny the issuance of a high assurance certificate to it. Otherwise, you might be able to do something like what nailer said.

CAs explicitly deny issuance to domains that have popular brand names in them - issuing a certificate for comodo.ian.sh would not be possible in most circumstances. I doubt the CA/B Forum wanted that workaround for EV as well.

"CAs explicitly deny issuance to domains that have popular brand names in them"

That requirement only is so incredibly stupid and gives no more safety than not being there. Who draftet this crap, seriously?

What popular is changes rapidly, sometimes overnight.

> What popular is changes rapidly, sometimes overnight.

That's correct. CAs also check for TLDs in unusual places (and unicode hacks, etc) in the requested SANs (Subject Alt Names, practically server names) during verification.

> Wildcards are explicitly banned by browsers and CAs when making the EV requirements: otherwise you get .company.com being used for bankofamerica.com.company.com like what happened with DV certificates.

Name validation is supposed to, and generally does, forbid "." in the part represented by the .

Founder here. As nailer says, the only detail signed in a DV cert is the hostname of your website. One of the crazy inefficiencies about buying certs elsewhere is that they tell you to use the openssl req command to generate a CSR. This prompts you for all sorts of details like your city, state, and company name. This information is all ignored, and having to enter it is a waste of time.

I've found that CAs sometimes actually do require the country to be present for some reason. Anyway, in case it it useful to someone, here's a one-liner to generate a key and CSR:

    DOMAIN=example.com sh -c 'openssl req -sha256 -nodes -new -newkey rsa:2048 -keyout "${DOMAIN}.key" -out "${DOMAIN}.csr" -subj "/C=US/CN=${DOMAIN}"'

Indeed, one of SSLMate's CAs actually does require the country code to be present in the CSR, so SSLMate includes it (we get it from your online profile so you don't have to type it every time). Despite this requirement, the country code is not present in the signed certificate.

This looks pretty cool. Although I do not understand why I would have to sign up on the website. The demo makes it look like it's a minimal-config command line tool. Instead the website makes it look like it's a service and there is no clear indication who stores my creditcard info etc. on the front page. This is explained in the FAQ though. A quick notice about stripe processing payments on the front page would be nice.

True, the demo doesn't show the sign up process, but you only have to sign up once and after that, buying certs is as simple as in the demo. (And the sign up process is itself very quick.)

Thanks for the feedback about the credit card processing information. I'll think about how to make that information more prominent.

Any reason you couldn't just have me enter the credit card info in the app?

Prices are much higher compared to Namecheap and their SSLs.com [0].

[0] https://www.ssls.com/

Many of our customers realize that fact, but are nonetheless extremely happy to use SSLMate. We're not a normal certificate vendor, and the ease and automation of SSLMate sets us far apart. If these features aren't important to you, Namecheap is a fine choice - I used them myself before creating SSLMate.

I understand, but during times when you can buy a decent whole web servers for just $60 per year with traffic and all, the SSL certificate prices are just outrageously high!

Wow, that's half the price of the same certificates they sell on their main namecheap.com domain. But they are both Namecheap sites? Why would they sell for less on a different label? Really makes me lose confidence in them even after having been a mostly satisfied customer on their main domain for years. Turns out they have been ripping me off!

Apparently this also happens for things like mattresses, airline tickets, and food (which doesn't make it less frustrating when you notice it).

Careful. I just checked and the cheap certificates are for 3 years.

I literally bought a 3y Comodo PositiveSSL certificate yesterday at namecheap.com for $27. It's the exact same CA! I feel cheated :-/. It's not even about the money, but the feeling of dishonesty. From a vendor selling "trust".

I'm the paranoid type; I would have a very hard time trusting a certificate key which was downloaded over the internet.

Where is the SSL key generated? If I create my own certificate and key, can I pass the signing request over sslmate to get it signed?

I couldn't find the answers to these questions on your FAQ or in the documentation.

Their FAQ implies they do it the usual way: "The sslmate command generates a 2048 bit RSA key."

Which is good, as sending you a key would be egregious incompetence from a cert vendor.

Egregious, perhaps, but not unheard of.

https://www.startssl.com/?app=42

They don't actually generate the key on the server but use the keygen element. This generates a key in the browser and doesn't send it to the server.

https://github.com/SSLMate/sslmate/blob/master/bin/sslmate

Useful (and confirms that it makes the cert locally), but we shouldn't have to read through the source code to get the overview of how the cert is created and signed.

"Your private SSL key is generated on your system and is never transmitted in any way to our servers. The sslmate command is a simple script that anyone can examine to verify that this is true."

https://sslmate.com/faq

You might also be interested in checking out our security page: https://sslmate.com/security

Apparently you still have to create an account on their website...

And at 15usd/year that is infinitively more expensive than lets encrypt.

So while I might use it today, I don't see how they plan to have much of a future.

Reply on news.ycombinator.com