Hacker News Reader

Comment by WA | Hacker News Reader

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?

View on HN

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.

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 .

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

Reply on news.ycombinator.com