

Stop Paying For SSL Certificates You Don't Need - bensedat
https://www.tinfoilsecurity.com/blog/stop-paying-for-ssl-certificates-you-dont-need-openssl-ca-tutorial-guide-how-to

======
xenophonf
OK, I'll bite. This article offers _terrible_ advice, especially if the reader
is a neophyte who thinks they are a hacker:

* barely mentions operational security

* nothing about potential costs or risks

* no scoping of the CA certificate

* bad recommendations for key lengths

* only an off-hand mention of CRL publication

* no mention of intermediate CAs

If it was just some guy saying, "hey, here's how you set up your own toy CA
without having to read the crappy OpenSSL manual pages, but don't use it for
anything real because it isn't safe from anything other than the most trivial
attacks," then I wouldn't even bother to down-vote the thing. Instead, it's
some guy saying, "hey, use your toy CA for real stuff" without the attendant
cost-benefit analysis that includes scenarios like "my toy CA got hacked and
issued certificates that caused one of my customers to get hacked, and now my
customer is suing me for negligence."

Not only is this person wrong, but their advice will make the Internet less
secure. I'm no fan of X.509 PKI (that Mozilla ticket about Honest Achmed
really tickles my funny bone and not in any of the ways that make me laugh),
but I'm not about to second-guess the kinds of heavy-duty security engineering
that goes into running a real, live root CA.

</rant>

------
chrislaco
If you're going to roll your own CA to secure your infrastructure, get in the
habit of also creating your own intermediate authority, esp if you're going to
do some minimal client certificates. Then you can keep your root ca offsite
and never used. IF your stuff get's compromised, then it's a matter of
revoking all of your intermediates certs rather than starting over with a
completely new CA.

~~~
chrislaco
So for example.

We have a root ca for everything. Then created an intermediate for the
infrastructure (posgtres, etc). We also created an intermediate just the API,
from which we issue client certificates for API access.

This is just for securing the connection to allowed users. Once connected via
a client cert, they still have to do the proper auth with OAUTH, etc on top of
that. Should the intermediate or client certs get compromised, we reissue an
API intermediate, and new client certs. All of course, on top of OAUTH
revoking, etc.

------
mankyd
This sentence is not anywhere near close enough to the top:

"This CA isn't going to be trusted by your website visitors, but your
infrastructure can trust it as long as you keep it safe. "

In other words, this doesn't mean you can buy a single cert and then go around
creating new certs for your other domains and subdomains. You're still going
to need to pay for those.

------
chrislaco
Good article, if for no other reason than the internet is littered with "self
signed certificates are bad", which is true for most scenerios except for
those pointed out in this article.

------
pwf
The only reason I've personally bought an SSL certificate was to make the
payments page of my website PCI compliant. Pretty sure this doesn't get me
around that.

More people do need to know this kind of stuff though; I'm using it at work to
great effect.

------
cdjk
I'm waiting for the widespread adoption of DNSSEC so we can just start adding
TLSA records with the public key fingerprint. Yes, it means you have to trust
whoever has access to create DNS records, but you already have to trust them.

------
otterley
It seems like a false economy to bother with the hassle of setting up your own
CA, whose certificates will raise alerts in most browsers, considering that
you can get an SSL certificate for $9 from cheapssls.com.

------
asdahjnkdasrgk
Or join cacert.org and use the web of trust.

