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.
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.
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.
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.
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.
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.
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.
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.
10 comments
[ 7.6 ms ] story [ 41.1 ms ] threadWe 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.
"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.
More people do need to know this kind of stuff though; I'm using it at work to great effect.
* 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>