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.
*.internal.example.com
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()?
If the machines are windows based and reside on a domain then Group Policies can push out these certs rather nicely.
Even non-windows machines - you can script the certificate update via logon script. I do this in my own domain I have setup for issue reproduction purposes.
It is rather simple.
http://lmgtfy.com/?q=how+to+set+up+a+certificate+authority Then distribute the *organization's* cert to all the servers and clients. If you have a few clients or don't get many that fast, just do it by hand. If you have hundreds of computers or lots of turnover, you should be running central config management anyway. MIT for example distributes an MIT cert. Presto, everything on campus is protected. It's partially a question of tradeoffs: sign a cert by a CA already trusted for $$, or make your own CA and spend labor (your or users) dealing with adding the certs by hand. It's also a question of security of the CA. Perhaps some Slashdotters could share links to best practices for an internal CA.
Please help metamoderate.
At home, I simply am my own CA, which really isn't all that hard. You just need to deploy the CA public certificate to the clients and you'll never get the warning. Now, depending on the "applicances" you might be able to replace the certificate with one you signed with your own CA, but I've never tried it.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
On window the list of CA on the machine can be centraly maneged...
Thats the best solution. It's not that complicated, either. Godaddy has cheaper serts as well, if that's not an option.
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."
We just use the same wildcard certificate that we use for our external sites. *.domain.com, works wonders.
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
http://www.ejbca.org
Open source, full featured
Find a cheaper service. We payed something like 500 euros for a 5 year SSL certificate.
Go for a cheapie wildcard cert. That will cover all your intranet needs.
For a private (e.g., not ecommerce, banking, etc.) web site, just create a certificate authority and use self-signed certificates, and send an email to the users covering the installation of private certs in MSIE, Firefox, Chrome and Safari. Don't waste your money on a versign cert because all it does is eliminate the warning for a price, whereas your users can eliminate it for free. Why add the tracking of additional "licensing" fees to your workload?
If it's public-facing then by all means buy the cert to ease support costs, but for employee use this is a deployment and documentation issue.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
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?
PuTTY FTW.
Check the name on the cert. if it is self signed, then you just have to deal with it. But if it is root signed, look at the site name. If you can find a way to use that site address to access the device then you will not get prompted.
My home router has a valid cert, but I would use the ip address and get prompted every time. I ended up making an entry in my host file for "linksys" at that address. Now when I go to https://linksys/ everything is ok.
At the end of the day, remember the whole reason these devices use SSL is not so you can verify the connection. They use it to encrypt the connection. It is so much better to use SSL instead of plain text, even though the cert is not root signed.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
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.
http://pki.fedoraproject.org/wiki/PKI_Main_Page
I do deploy them but I do avoid getting robbed by Verisign for these and other certs by shopping around.
Currently I pay around $10 a year for individual host certs, and $126 a year for wildcards.
http://www.namecheap.com/learn/other-services/ssl-certificates.asp
If you have a large number of street facing certs the wildcard is the most cost effective solution anyway but for lower volumes I use individual certs as well.
It has some cost but the reduction in uninformed user headaches is well worth it.
There absolutely needs to be some kind of warning for untrusted certs. I can see an argument that the current solution is overkill (I disagree), but treating it the same as an HTTP page gives users no easy way to check whether or not they should trust the connection.
Now, I'm of the opinion that browsers handle untrusted certs as well as they can with current technology. Time and time again, end users have shown that they'll click through simple warning dialogs and send their data to phishers. When a server establishes an HTTPS connection with a client, it's telling the browser that this should be a secure communication, and sensitive data is going to be transmitted. If the browser can't validate that the connection is trusted, the user needs to know something is wrong.
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
http://ejbca.sf.net/
In it's easiest form (everything on one host), it should be easy enough to implement.
Windows 2000 - from the guys who brought us edlin
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
Here's where you went wrong. If you insist on keeping this constraint at any cost, then you have lost. Pay that cost (you don't get to have intranet sites) instead of getting what you want, and accept that you got the lesser of two "evils" (from a very perverted point of view).
The main problem with looking at it that way, is that you (or someone) already did what you claim you want to avoid. Those workstations don't just magically trust Verisign utterly and completely as an introducer while not trusting you a bit. They trust Verisign and not you, because web browsers got installed on them, with preferences configured to to that (and Verisign's business model is to count on people being lazy and keeping those settings). Go ahead and set up your company CA, then bite the bullet and tell all your workstations to believe it (instead of seeking to avoid this step) and get it over with.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
We have a pretty small employee base, about 35 people and several rotate in and out all the time in the sales dept. I choose to use an self signed cert for our site. Mainly to help if that odd ball virus got on a computer. I require everyone to use Firefox and with that you have the option to accept the cert and not deal with anymore annoying popups.
The biggest problem is in off-the-shelf appliances (like wifi routers) for the whole spectrum (from personal to enterprise); they don't have domain names, so you can't have an internal CA root blessing them (at least, not out of the box), and a non-enterprise location can't easily do that.
One solution could be to bundle a CA root into the router. Initial setup would involve picking an internal TLD (with a randomly generated suggestion so we don't have everybody using "home" or "linksys"), then the CA root certificate is generated for that TLD. New appliances would have to somehow register with that CA, and for proper security, this would have to be approved by the human setting it up, but this could conceivably be streamlined.
I'm actually surprised this problem isn't solved via workaround; properly-encrypted wifi doesn't really need SSL (though a MitM attack is possible for the first connection since the AP MAC isn't yet known), and everything seems to be moving to wifi.
I'd also like to see an extension to USB Mass Storage devices that puts a tiny CGI-enabled web browser in the "filesystem" that enables configuration. Since you're plugged in, security is easier.
Use my userscript to add story images to Slashdot. There's no going back.
$400 is the price of name recognition. I use GoDaddy certs and they are 1/10 the cost. All you need for any purpose.
For some of my stuff I use the shared cert that my host provides. Still secure but throws that bloody warning. At least firefox let's me permantely store the certificate exception.
First, $400 is a stupid price to pay for an SSL cert, many providers are much cheaper...
Some cert providers (Eg startcom) will provide unlimited certs under a particular domain, so assuming you use the same domain internally its quite easy to generate more certs for the same price you paid for your external certs.
On the other hand, if its internal to your network why don't you create an internal certificate authority and just ensure its root cert is trusted by all your devices.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I don't know why I'm getting modded troll, or offtopic of all things, so let me clarify:
Browsers should treat untrusted certs the same as unencrypted pages - they're at least as secure [as unencrypted pages], possibly more secure than "trusted" certs (such as me connecting to my home server with a self-signed cert, I can be certain no third parties, even governments, could illegally obtain the certificate and perform a MITM).
"When information is power, privacy is freedom" - Jah-Wren Ryel
Surfing without encryption opens you up to eavesdropping and spoofing.
Surfing with encryption protects you from eavesdropping and spoofing.
Surfing with a self-signed encryption protects you from eavesdropping, but not spoofing, since you don't know who the signer is.
Yet, Firefox treats self-signed certificates as if they were worse than no encryption at all. The default behavior should be to treat self-signed certificates as if there was no encryption at all (from a user perspective). To give users these dire warnings, when in fact they are better protected, is just silly.
Personally, I find using the Windows Server Certificate Authority to be great for internal sites. The reason is that it automatically pushes the root cert trust to all domain members. It is also very easy to do a CSR to the internal cert server from IIS. Since you have to still do a CSR no matter how you do your "trusted" cert, going this route can be fairly painless. The other benefit is you can then use your internal cert server for other purposes such as company email signing, encryption, etc... You can also use OpenSSL, but it may take a little more to configure, but it is free. If you have a domain controller, you can just tag on the cert authority too if you are limited on Windows Licensing or hardware.
Time and time again, end users have shown that they'll click through simple warning dialogs and send their data to phishers. When a server establishes an HTTPS connection with a client, it's telling the browser that this should be a secure communication, and sensitive data is going to be transmitted. If the browser can't validate that the connection is trusted, the user needs to know something is wrong.
That browser behavior is what needs to change. When accessing a site with an untrusted cert, the browser should act like it would with a plain HTTP connection. No padlock, no blue/green address bar, no indication of enhanced security, but no warning - maybe it could show a status bar icon, a padlock with an exclamation mark or something, as a little unobtrusive indication that the certificate is untrusted, but it shouldn't interfere with the browsing experience by stopping the page from loading and displaying DANGER WILL ROBINSON! CERTIFICATE NOT TRUSTED!
And the user should act just like they do now - they shouldn't send critical private info without an indication of enhanced security.
"When information is power, privacy is freedom" - Jah-Wren Ryel
we held out for a very long time, as a non-profit academic institute that didn't want to pay for certs...
The final straw was iPhones and the like, not only NOT talking to our self-signed IMAP-SSL server, but not even complaining why... (in fact, they say everything is fine, but never retrieve the mail...) The mail app doesn't even give you opportunity to accept the cert.
yeah, you can post your cert as a file on a webserver, and point safari to it, and explicitly add it as a profile... but that didn't seem to be a long term viable solution.
so, we finally purchased a wildcard cert. I hate paying the money, but it did fix our "problems".
If it's an enterprise using domains, set up your own CA and create your own CA signing certificate. Push that certificate out into the root certificate bundle or database for your browsers etc., and use it to sign all your server certificates. Since browsers can validate your server certificates, they won't complain. Have the certificate available for importing into browsers that don't accept automatic pushes. That should solve the problem, at least internally.
I don't know about your corporate policies, but if the main IT department doesn't want to deal with it, you could set up your own root cert for your department and just use that. Presumably you have a bit of internal server space somewhere that you could host it on. They're not really that hard to set up, there are a lot of tutorial online that will help you.
I read the internet for the articles.
Most of my company intranet is plain http. There are two parts that we encrypt with SSL. First is the optional login widget on the intranet front page. Employees can customize their front page if they choose to login, but it's not required. But since we use a single sign-in type of situation, where many services are authenticating against the same LDAP service, we feel like we should keep that password encrypted, even on pages not available to the outside world.
The second page that is https is a web form that allows you to change said LDAP password, by entering in the current password, and then the new password twice. Once again, same reasoning. This password gives you access to everything internal. We use a separate RADIUS server to authenticate for external services like VPN, etc.
So yes, we did buy SSL certs for these pages, but they are not from VeriSign, and sure as hell are not $400 per year. Look around, there are a lot of cheaper SSL certs that are in the root chain for nearly all browsers and devices. The only thing we had trouble with--where users had to import the root CA and the cert themselves--was Android 1.x devices. Since we're an iPhone shop and don't officially support Android, I let them figure that one out. :-) But apparently Android 2.x devices worked without any extra hassle. But back to the main point, I think we paid $200 for three years' worth of SSL for these sites.
Now, for our VPN and Zimbra webmail, which are both public facing, yeah we buy some fancy-schmancy VeriSign certs that make the address bar turn green and other features that allow the big CAs to gouge you for their certs. We do this for widest compatibility, as we allow people to check their webmail via https from any internet-connected computer in the world.
:q!
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.
Perspectives does that, and then some.
Assorted stuff I do sometimes: Lemuria.org
If you become verified by StartCom at the level 2 rate you can issue *unlimited* SSL certificates for any verified domain (verification is free). The second level is $50 per year for unlimited certs... highly recommended! I use this on all my internal "appliances" and websites.
If you have a Windows environment with a Active directory you could deploy with GPO (Group Policy) to all the desktops on the domain. http://www.tcpdump.com/kb/os/windows/certificate-deployment-using-gpo/all-pages.html If you have Linux desktops may be you colud deploy a package with the certificate. If you set up your own CA, then you must have to deploy the CA certificate once too.
Damia
Once per browser, that is.
My company's web-managed product just uses self-signed, with the option to add a third-party signed if the customer is willing to pay for and install it themselves.
Another non-functioning site was "uncertainty.microsoft.com."
The purpose of that site was not known.
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!
Startssl.com will give you a free Signed SSL certificate for use with a webserver. Good for your base host domain & 1 additional host. I've been using them for a couple years. I run my own server for fun at home and wanted to try SSL to add it to my resume, and also to secure communications, and just because I could. It wasn't too hard, and well worth it IMO. Give it a try, worst case you are out the cost - NOTHING!
1- get tinyca2...
2- install, start the tinyca2 GUI (yes, not command line!!) and generate *your own* CA
3- create the certs you need, sign then with your CA
4- import the your CA to the browsers, put it on a webpage, so people can easily install by just clicking on a link
5- profit!!!
tinyca2 is just one, there are more PKI packages out there, both more simple (easy-rsa) to more complex (openCA), to different license (bsd based - XCA)
Higuita
The above is in no way plus 4 insightful. That poster has no clue what they speak of.
"But they don't authenticate the remote site."
Wrong: Browsers check that the certificate matches the domain that served it, and that the said certificate was issued by a trusted certificate authority. Without those steps, malicious sites would have to hijack DNS entries for target domains, and use either self-signed certificates or certificates signed by non-trusted CAs.
"The protocol should also have some reasonable way of doing rollover"
It does: Look up "SSL renegotiation"
"is this site using the same certificate as the last time I connected to it"
Learn how it works before speaking: A site can change its certificate at any time. In fact, some certificates are intentionally short-lived and are replaced frequently. So the bottom line question is "does it matter if the certificate presented is identical to the previous one for this site?" In truth, it doesn't. So the best thing for browsers to do to fit 99% of usage patterns it so validate the certificate for the given session against the know certificate authorities. And that's exactly what happens today.
To call it all a scam while being so uninformed is.. well.. either from a naive kid, or typical internet trolling.
Why the above tripe was modded insightful is beyond me. Certificates are the oldest and most reliable way of anonymously verifying identity between sites or otherwise anonymous users.
Nobody expects certificates to perform on the fly authentication. Authentication is performed before the certificate is issued, and thereafter one has the assurance that the certificate is being held by a previously authenticated authority. You might as well complain that authentication itself is a scam because it is not 100% reliable.
Where the F have you been for the last 15 years, anyway? Essentially, you're making the ridiculous claim that assymetric public/private key based encryption is worthless, when it has been proven to be anything but.
No, Thursday's out. How about never - is never good for you?
Why the hell would they agree to $100 per cert? I've never ever seen such a high price on a non-EV cert.
If it's a damn internal cert, you can spend $15 and get the cheapest one that works on the stuff you support.
Hell, you can probably find a wildcard for $150 if you look around.
Of course, all this is stupid, you shouldn't have to sign stuff to get encryption, but we've all beaten that dead horse.
If corporations are people, aren't stockholders guilty of slavery?
Needs a Chrome extension. Used it extensively with Firefox, but no longer use Firefox =(
SSL certificates have two goals, identity/trust and encryption. Self-signed certs establish encryption by default. If you save the self-signed certificate in your browser, then trust/identity is established manually, which is the only selling point of of a cert signed by a CA. Once you have the cert saved an error message is no longer displayed unless the certificate changes.
Firefox has this option selected by default upon bypassing the initial error message. In IE, view the certificate and "Install certificate..." Done.
You indeed can use RPM packages to deploy certs. When I was at a DOE lab working on LHC stuff, we had hundreds of CAs from all sorts of EDUs that needed to be installed on grid computing systems. All done with RPM package management (with yum of course).
Yeah, that's pretty much what all the non-idiots have decided.
About 10% of this site is in some delusional world where users might get 'tricked' by the fact it's https, but, gasp, unsigned...which totally ignores the actual fact that either users are smart enough to check for a padlock, or they have no damn idea what you're talking about and will trust any domain that claims to be anything.
There's no middle ground of users, who are running around checking for 'https', and not noticing the lack of a padlock. And if that really was the damn problem, we could just invent that unsigned certs use 'httpe' or something instead, which would also be port 443 but not checked for signed certs, just use general encryption and store a hash of the key to compare to next time.
But the goddamn standards are run by the signing companies, and they certainly don't want to make themselves useless. So instead of sites being 1% signed, 50% partially encrypted for non-critical, user stuff, and 49% unencrypted, we have them being 3% signed, and 97% unencrypted.
Gives them three times as much business, renders half the goddamn internet insecure.
There is, indeed, a middle ground for security. A place where username and passwords to forums get sent encrypted so people can't sniff them. A place where you can use the same cert on multiple domains so you don't need to waste an IP per-site. A place for moderately secure traffic, or intranets. The stuff now that either has no security, or a giant warning about self-signed certs.
And the 10% of slashdot composed of total idiots on this issue about to start leaping in talking about 'a false sense of security is no security at all', which is also why you shouldn't lock your house unless you're using a bank vault door.
If corporations are people, aren't stockholders guilty of slavery?
A wildcard certificate has the server name *.yourcompany.com in it and you can install it on as many servers as you wish.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
Sorry, to reply to myself, but my post was a little confusing and vindictive unless you remember the last time this comes up. Every time SSL certs are mentioned, people are 'I don't understand why self-signed HTTPS is treated worse than HTTP?' and everyone agrees until idiots show up to disagree for some utterly inane reason.
Many of them are convinced, convinced, that self-signed certs are as insecure as no encryption, despite people constantly pointing out that sniffing and recording is a hell of a lot easier than intercepting and rewriting.
There's really no reason the entire web shouldn't be encrypted. Signed certs for the important stuff, unsigned for everything else, your web browser keeping the cert hashes in your history, and even with an option to keep specific ones permanently.
Of course, now with DNSSEC, signatures are utterly stupid to start with. HTTPS cert hashes should simply be listed in the DNS for a domain, tada, our work here is done, the end.
If corporations are people, aren't stockholders guilty of slavery?
...to ask honest questions (even if top-level, not "do my job for me" detailed).
It is the place, however, to get pilloried by experts who exclaim if you had only used the right search terms in Google, written a small kernel patch, rolled your own Linux distribution with it, and installed it on every server and PC in the company over the holiday weekend, your problem would have been easily & trivially solved in time to come up from the basement and join mom and dad for Thanksgiving dinner.
This is not for the OP but for the German Slashdot crowd.
I have been using PSW Group at http://www.psw.net/ and I am very happy with them.
Their website looked like a scam site to me but I researched them before I purchased and they are legit. I am now paying 29/year for not having to explain the private cert deal anymore.
Everyone who buys Wild Hunt will receive 16 specially prepared DLCs absolutely for free, regardless of platform.
A lot of responses that I have seen to this question are basically the following.
"Create your own CA (certificate authority) certificate and distribute them to the client workstations." Then they accuse the original poster of having asked an overly simple and uninteresting question.
I am going to say something nobody else seems to have said. SSL sucks big time for large workgroups inside a private intranet. It is an inappropriate solution that is being used for the lack of anything better. IE will give AD based authentication for browsers, but did not extend that to securing the communication channel itself.
This issue is much nastier and more complex then anybody has allowed for. SSL does a very good job of solving the problem of creating secure communications over untrusted anonymous networks. However, they are a real pain when the only thing you want to do is create a secure communication between two machines in the same room. In those cases, SSL comes with a lot of overhead that is really not needed. In the case of two machines in the same room (or workgroup), the machines are already on internal corporate IP addresses, so a lot of the issues that SSL was designed to solve (validating that the IP address really points to the expected entity) just are not applicable. Usually the only reason why you want to encrypt the data is so that somewhat private data won't be sniffed by other users. You are not trying to prove that you are a legitimate seller of any goods or services.
What really astounded me were the claims that it would be easy to get users to accept company controlled installs of browsers and tools. I have worked in such an environment and it was actively resisted and foiled because the choices were so limiting. For those who say "it would work it was done right", probably have not done cross browser development where you had to test on Linux, Mac, and variants of Windows machines. Nor have they done Java development where the Java has to communicate to the server (over https) as well (Java has its own client CA chain distribution).
Every place I have ever worked (big or small) has had http web sites when they really should have been https because of the pain of trying to use SSL. To say that this is because of bad IT management I think gets it wrong. SSL is a bad fit for this problem space and browsers (and Java) need to support other security solutions. It would be nice to recommend Kerberos, but Kerberos has really only gotten full implementation with AD and is even more painful for client adoption in most (with non Microsoft machines in the mix) real world scenarios I have seen. The state of intranet security is broken at its foundations and the proposed solutions that have been suggested here would not work (in practical, reliable, real world usage) for many workgroups working inside a much larger corporate entity.
Find the cheapest single-root wildcard that will let you do at least 2K. Then install it everywhere in the intranet, being careful with the permissions so nobody can easily steal it.
Either get it on a single-year basis or be prepared to do a revocation if it gets stolen before it expires. If you are conscientious with your file and folder structures and permissions, though, and you hire trustworthy techs, it probably won't get stolen. Unless you depend heavily on an OS with lots of zero-days and your site is a high-value target, of course; banks that use IIS are just asking for trouble.
If you never patch your server OSes or firewalls you shouldn't buy certs at all. They'll just get stolen.
This is the most sane way to handle this, if its truly an admin only control interface. It's also a great way to allow access to appliances from outside of the private network as well.
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...
Seeing as how certificates don't actually do anything at all except eliminate browser warnings, why on earth are you spending $400 for an internal appliance when you can cet one for $15/year? or $35/year, or $75/year all in a matter of minutes.
.... that knows everything there is to know about technology.
No false modesty there, thanks goodness....
IANAL but write like a drunk one.
Man on the middle attack: It can happen on an Intranet. This is why you need things like SSL.
IANAL but write like a drunk one.
Certificates expire. They do that because they can be brute-forced, given enough time and a big enough bot net. A cert that has not changed since the last time you connected may not be as secure as you think. And a cert that has changed due to expiry, change of provider, or any other reason is no indication that there is anything wrong either. I do agree that the authentication part is edgy though, seems that you have inadvertently farmed out the implicit trust - but not to the issuing authorities. You handed authority to Microsoft, the Mozilla foundation and Apple, because of whatever choices they decided to make as default in your browser. (You can be assured that a lot of money changes hands there)
Starbucks, Harbuckle of Breath.
one could also get a class 2 cert (valid for *.company.com). It would be also valid for internal.company.com domain.
We typically just reuse our wildcard cert from DigiCert. They allow as many resigns as you want.
http://www.digicert.com/
A large company could distribute their new CA information via a login script. It sounds like this guy lacks that luxury.
- they're at least as secure, possibly more secure than "trusted" certs.
and no, no they are not. How did you reach THAT conclusion?? Untrusted certs should be treated as unencrypted pages, exactly because they are as secure.. that is.. not secure at all.
There are certain situations where a self-signed, untrusted cert can be more secure than one generated by a third party:
http://slashdot.org/comments.pl?sid=1880524&cid=34319778
"When information is power, privacy is freedom" - Jah-Wren Ryel
SSL is a PITA. It's much easier to configure Apache to only serve admin pages to the local machine. SSH tunnels are more secure and easier to maintain too.
Expected time to finish is 1 hour and 60 minutes.
CA's should have to validate a business or home address, a phone number, a name, a bank-account that mirrors the supplied data and an ISP for the requested domain must also mirror supplied personal data.
Payment must come from the above bank account and No PO boxes accepted.
The CA would call the Bank and ISP and be like "We're calling to verify that you have a customer with this name with this registered address". The bank would also have the account number as part of the question, so name/address/account must match.
For business class certs anyway.
Browsers should warn for non-business class certs.
This would cut down on certs being bought by anyone.
This is a great post; it was very informative. I look forward in reading more of your work. Also, I made sure to bookmark your website so I can come back later. I enjoyed every moment of reading it. http://www.optionpoppers.com/
I recently came across your article and have been reading along. I want to express my admiration of your writing skill and ability to make readers read from the beginning to the end. I would like to read newer posts and to share my thoughts with you http://www.optionpoppers.com/