Slashdot Mirror
SSL Certificates For Intranet Sites?
wiedzmin writes "Anybody who has worked around anything dubbed an 'appliance' in the past few years knows that they come with a management Web interface, which is usually 'secure.' However, no company in their right (accounting) mind will spend $400/year per appliance to buy Verisign SSL certificates to secure Web interfaces on networks that may not even be open to the public Internet. So network administrators, and sometimes end users, are stuck clicking away at an annoying 'Continue to this website (not recommended)' message every time they connect, setting an unhealthy precedent when it comes to the actual security of SSL and the much-hyped MITM attacks. So the question I have for the Slashdot crowd is: do you have valid SSL certificates on your intranet sites, and if so what do you use? Any cost-neutral, or at least cost-conscious solutions out there that don't involve manually distributing your certificates and CRL to every workstation in the company? Thanks."
Why not set up a private certificate authority? Then you can manufacture as many SSL certificates as you need for private use and all you need to do is distribute the certificate authority's certificate to each browser once for the entire enterprise. Every browser out there has a way to add additional trusted certificate authorities. Indeed, if you have a "centrally controlled" provisioning system, you can even add the certificate to your default system build. Then the scary warnings go away completely.
If it works in theory, try something else in practice.
https://www.startssl.com/
An Israeli company with inexpensive SSL (and other certs). I would also point out the prices they have for Extended Validation SSL certs.
Every browser has a way to store the security exceptions so that you don't get that warning every time. Just set the box up on a private network the first time to avoid a MitM attack and store the cert. If you ever get another warning about an untrusted cert from the box, then you might have a MitM attack going on, but otherwise if the cert matches you're fine.
You could also set up your own local root authority (most larger companies do this) and make your own certs.
I read the internet for the articles.
http://startssl.com/
Do daemons dream of electric sleep()?
On window the list of CA on the machine can be centraly maneged...
FTFP: "Any cost-neutral, or at least cost-conscious solutions out there that don't involve manually distributing your certificates and CRL to every workstation in the company? Thanks." Before snarking on the FP author, perhaps you should actually read the FP's question?
So a login script (or in a Microsoft environment, an AD group policy) that distributes the certificate automatically to each computer meets your definition of "manual distribution?"
Really? That's what you're saying? "Automatic" and "manual" are synonyms in your universe? wow.
What we actually have here is a psychological issue - the cert vendors want you to believe that anyone who doesn't buy their certs is a potential criminal. The rule should simply be "no financial transactions or personal data on a site without an entrusted cert".
Other than common sense, there is nothing to stop me posting my credit card details on Slashdot. If I log into a public forum using HTTPS, I still have no protection against my own stupidity if I do that. Now, without simply modding this troll, can anybody give a coherent explanation as to why browsers shouldn't assess self-signed certs according to their origin - within the intranet, valid server name - rather than treating selfcert.ru the same as selfcert.10.0.0.1?
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
You might find my "PKI in a web page" useful. It doesn't require sending all certs to all browsers, just the one internal CA cert and includes step-by-step screenshots on how to do that. See https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/entry/a_pki_in_a_web_page10?lang=en
Judging by plenty of the comments in threads similar to this, I think most of us are tired of seeing Ask Slashdot posts on how to do his or her job. Had this been really cutting edge, or new grounds, I could understand. However.. Enterprise PKI? Seriously? If this is to be the continuing trend of Ask Slashdot, I need to adjust my filters.. because that is just sad.
I'm finding more and more IT folks are standing around waiting to be spoon-fed solutions, instead of trying to research and educate themselves on what is already out there. It worries me that this is not just the trend in IT, but across all occupations. Am I just getting old and crotchety, or is this a new trend?
HP lights out boards don't retain the self generated cert between power failures. So when power returns you get a different cert, and the exception now needs to be removed and readded.
The only thing the "trusted authorites" confirm is that the person who has the cert paid for it.
Some trust.
The whole SSL certificate crap is a scam. The only interesting thing to know would be "is this site using the same certificate as the last time I connected to it". And the shitty browsers don't tell you that.
(The protocol should also have some reasonable way of doing rollover, like presenting a new certificate in the session "this is what we're going to be using starting...").
But they don't authenticate the remote site. They just check that the remote site has a certificate signed by one of those super trustworthy people like Verisign or the government of China.
Watch this Heartland Institute video
Congratulations on getting your story accepted to the front page!
Dozens of man-hours will now be spent explaining basics of inhouse certificate authorities and self-signing, along with comments on your lack of basic research, intelligence, qualification for your position, and legitimate parentage.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
And to those of you here who claim "half a brain": please remember that you yourselves may someday need to do something (legal, financial, educational, even technical) for which you are less than half competent. Yes, you have achieved a "win" in humilating a sincere poster, but it's the cheap victory enjoyed only by the pusillanimous.
Here's the deal. Either this person is administering a smallish number of machines, in which case he/she can simply go 'round and install certificates on all of them, or they're administering an assload of them, in which case they do indeed deserve the scorn for not being willing to do a modicum of research and choose the standard approach.
Your defense only works if they're in charge of too many machines to administer manually, but yet have no experience doing so - a situation which is highly unlikely. It might be a temporary situation due to turnover, but in that case they shouldn't be implementing a "convenience" feature like this one themselves.
You're special forces then? That's great! I just love your olympics!
It has been said about 300 times here already: install an internal certificate authority and push the CA certificate out to all of your browsers....
The cheap option is to use an open-source SSL CA; a client of mine (one of the planet's most profitable law firms) was using Verisign to sign internal certs, partly out of laziness, for internally protected (https/SSL) apps. I recommended an internal cert auth and their security gurus deployed an open source CA. They pushed the CA cert out to the worldwide desktops via Windows Group Policy so that the browsers would recognize the signing authority. worked a charm: all internal certs signed for free. Lots of money saved...
For another client (big company that manages railway infrastructure on a big island in the Atlantic), we deployed the Oracle "Certificate Authority" (Part of Oracle Identity Management) - don't laugh - and it worked as well. Needed to push the CA certificate out to the desktops via Windows Group Policy. Also worked a charm.
Only fools use public cert auths such as Verisign to sign internal-facing certificates.
Both clients had it on their "to do" lists to deploy the MS Certificate Authority, but is was deemed low priority, so another solution was needed...