Slashdot Mirror
Cheap SSL Certificates for Small Websites?
zaqattack911 asks: "In the workplace today it is becoming more and more common for everyday applications to be accessible over the web. Just about all the booking and tracking systems at my job are handled via web-apps these days. Along with this trend, is the increased need for secure transactions over the web. Just about all of the apps on my webserver are going to be SSL only. Some of them are for internal use only, some for the outside internet to use. Is there a cheap alternative to getting your certificates signed? Self signing my certificates works of course, but just about all browsers make a big fuss about it. Verisign asks for about 400$ initially, and 300$ to renew a certificate every year. This seems like a scam to me, and I'd love to know if anyone knows of alternatives out there? Is there a way to get around the certificate signing business? I looked at a company called RSA Security which allows a company to 'self sign' and use their accepted signature. The website doesn't mention the price, and I'm sure it's not very affordable. What else is there?"
a bunch of excellent geeks I know use entrust.
four-oh-four
They charge $199 for certificate, and have a pretty good service. I've been using them for years.
we use them for all of our commercial sites.
A year spent in artificial intelligence is enough to make one believe in God.
The stories /. has already had on the topic....
0 1/03/18/18 55230&mode=thread&tid=93
0 1/09/06/04 51218&mode=thread&tid=148
Why Are SSL Certificates So Expensive? by Cliff with 192 comments on Sunday March 18, @04:48PM
http://ask.slashdot.org/article.pl?sid=
Are FreeSSL Certs Worthwhile? by Cliff with 8 comments on Friday September 07, @11:50AM
http://ask.slashdot.org/article.pl?sid=
Rackshack.net has a link to a $49 QuickSSL certificate. I haven't used them, but it sounds like a good deal.
Title says it all
I say the same thing about signing my Java applets. Sun only puts Verisign or Thawte root certificates. So if you want to avoid your customers seeing some redicuouls
"Jesus!! this software is unsigned!!!"
message, then you gotta buy the certz. I am self signing right now. I would love if OSDN could have their own root certificate and let us public folks buy from them. Any malicious signers will be found out quickly so whats the big deal???
I think this signing thing is DRM in action. Nobody is realizing it yet.
You can purchase a ridiculously cheap ($50) 128bit SSL cert, trusted by browsers from http://www.geotrust.com
All you need a valid credit card to get a
cert. The CA key is loaded in almost all of the browsers, the notable exception being Opera.
They do send a 'auth check' by emailing the domain admin contact you can select.
The entire ordering process (including filling out forms) takes less than about 5 or ten minutes.
This should SCARE you if you're relying on the security provided by Veri$ign and the root that ship with browsers. - pablos.
You may find what you're after over at http://www.cacert.com The creator of this website believes that trusting someone should be free, and is doing his best to make this happen.
There is a nice page, http://www.whichssl.com. Through the comparison tables there I found comodo's http://www.instantssl.com. I generated a demo certificate first and after I had no problems with it, I bought it. For $49 a 128 bit, not 40. Recommended.
comes with openssl. It even has a nice perl script to make it easy.
What Verisign and co have that you don't is their root certificates installed with the browsers by default. For internal use you should have no problem using your own certificates. For external use, where an existing business relationship exists (ie you aren't selling to the public, but to people who can trust your cert because they know who you are) it should take little more than a quick explanation.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Sure we all hate VeriSign for all kinds of reasons.
However when you get an SSL Certificate from VeriSign and some of the other Cert signers out there, you are getting two things.
The most commonly understood thing you are getting is the encryption thats automatically accepted by just about any modern browser. However, the reason it's automatically accepted is because VeriSign is suppose to verify the identity of the business. This is why they require a Duns and Bradstreet # (It's a business credit identifier). This way you know when you're going to https://secure.yourdomain.com to enter your credit card information, that you are indeed still on yourdomain.com and that your information is encrypted, and verified to be sent to the company you intend to send it to.
So if all you are concerned about is encryption, just generate your own. It will however throw a warning in just about any browser that the identity of the site can't be verified. Other than that, cost of this service isn't going to drop very dramatically without losing its verification services.
I understand though, that browser warning annoys me too.
..There's a-dooin's a-transpirin'
You're going at the problem wrong. Don't worry about getting your clients to accept a self-signed cert, worry about getting them to add your own root certificate to those they trust.
This is actually straightforward - you point them to a URL that returns the root cert, with MIME type application/x-x509-ca-cert, and tell them to accept it for all uses when the broswer pops up a dialog box.
You should then use this root cert to sign your web server certs (and certs for mail servers, databases, whatever). All should be trusted immediately, assuming you have your other ducks in a row. (E.g., you need to have your web server cert's common name resolve to the IP address of the web server.)
It's a bit more work to maintain a mini-CA than to just use self-signed certs, but overall the benefits outweigh the hassles. Many of us are working on JSP tools to operate mid-range CAs, but I don't know how far most are. (The problem is Microsoft's eternally changing standards on how clients generate the cert request on their side - I can handle Netscape/Mozilla with ease, but it seems like every version of MSIE is just slightly different.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Have your company buy a key, then create signed keys for your domain private domain with it as the issuing key. Nobody will know, as most people still use IE, and it still has that fun bug.
The Right Reverend K. Reid Wightman,
.sig: file not found
I couldn't find rackshack listed in any of the "approved" signing sources for mozzila or netscape.
"Eve of Destruction", it's not just for old hippies anymore...
... and can manage an installation of certificates on all clients, you can create your own certificate authority all by your self.
Here are some *SIMPLE* instructions for building a self-signed CA cert, and then signing SSL certs for servers. Any real implentation should probably be assessed for security (like ca-generation on an isolated machine, etc ...)
That's pretty much it. mix into your IT operations as nessecary
Why aren't you encrypting your e-mail?
Actually, you are mistaken.
Today's browsers (even the first SSL enabled browser, Netscape 2.0) recognized _dozens_ of certificate authorities. Besides Verisign and Thawte, there are RSA, Entrust, and others.
You are also mistaken that RSA started Verisign; RSA Security was the company that licensed the RSA public-key algorithm. They actually compete directly with Verisign as a CA.
To see for yourself:
(Netscape|Mozilla): Edit->Preferences->Privacy->Certificates
IE: Tools->Options->Content->Certificates
We just need the a trusted authority (for certain definitions of 'trusted' and for the definition of 'authority' that is ubiquitously recognized instead of decided by the highest bidders in the browser wars) to make digital assertions.
You'd start with certifying identities: my state might sign a certificate certifying my name, maybe driver's license number, perhaps address and even a photograph. I should now be able to sign e-mails with this now independently of my e-mail address. The resulting signed message could carry whatever signed assertions I wanted to put on it. (Probably my name and maybe my photograph.) I can't forge these, because these components are signed by the state in connection with my identity. A posting to a self-help group might just assert my identity in the form of a photograph and an unsigned nickname.
Taking this a step further, I should be able to use this ID to sign other things, even web sites. This will require changes to the way users perceive an "authenticated" web site. If I go to a bank at www.example.com today, they have a certificate that basically states "www.example.com is Example Bank, and their identity is certified". What my own signed web site might assert is "www.example.com is Joe User". User agents need to give more weight to the name here and less weight to the fact that the domain name matches what's in the certificate.
Extend this now to corporations. When a corporate charter is created, a digital ID for that corporation is created along with it and signed by the state of incorporation. That corporation can now sign assertions like "Joe User is the CEO of Example Corporation".
So now, when Joe User sends an e-mail, he can include this information:
- Joe User (signed by the state of residence)
- (Joe's picture, signed by the state)
- Job Title: CEO (signed by Example Corporation)
At this point, we really have a framework to allow the signing of most any type of assertion. If someone feels that we still need a signed DNS-based model, we'd do this within the DNS framework. I.e. registrars, when creating a domain, would also create a certificate for the domain name created and pass that on to the new owner, who can now sign for sub-domains as needed. When presented with www.sub.example.com, we have "www" signed by "sub" signed by "example" signed by one of the registrars for ".com".Some of these concepts will require a re-thinking of the way we approach authenticated online identities. We need to stop placing so much importance on online identifiers (like domain names and e-mail addresses) and start paying attention to who is making those assertions. I can sign an assertion stating that my e-mail address is 'joe@example.com', but unless that's really my e-mail address, it's not going to do anyone a whole lot of good. If I go around forging e-mails from joe@example.com and including that signed assertion, everyone should be able to take one look at that and say, "Who the hell is this guy claiming to be joe@example.com?". Only the guy with the certificate stating the assertion that he is "joe", signed by "example", signed by a valid registrar for ".com" would be able to say that with any authority.
A lot of this can be done today with signed/encrypted XML, provided we have a common framework to start sharing the assertions.
1) Almost every known root CA targets businesses as their primary customers. The prevailing mentality seems to be that if you want to secure your HTTP server's connections to members of the general public, you must be running some sort of business. Their cost per certificate is nothing; you are paying them not for the certificate itself, but for a certification of your trustworthiness as a business.
But what if I'm offering a free service, which nonetheless requires that my users have absolute trust in their browsing security? What if I'm running a nonprofit organization? If the CAs were truly interested in security, they would offer a low-cost alternative for people who are offering free services, and perhaps a free certificate for non-profit organizations.
You may point out that I can now get a cheap certificate for $50. While this is true, the low price of certificates these days is the result of market pressure. These guys aren't lowering their prices out of the goodness of their hearts, or to help Joe Q. Webmaster who wants a secure website. They're doing it only in response to competition.
2) 'Wildcard' certificates cost an absurd amount of money, usually $500 or more.
Excuse me? The entire premise of the certification, is that Thawte (or VeriSign, or whoever) is certifying my trustworthiness as an organization. As such, it shouldn't matter whether I have one, ten or a hundred DNS names associated with my website and with my organization. By forcing you to buy separate certificates for your web server's DNS name, your mail server's DNS name, your LDAP server's DNS name and others, they are extracting even more money from your wallet. Even if all my services are hosted on the same machine, I must pay hundreds of dollars extra for the privilege of giving them separate aliases. The only other alternative is to host all of my services on one machine, under one DNS name. Thank you so much, VeriSign, for sticking your nose into my system administration.
And, finally,
3) VeriSign, the biggest fish in the pond, has demonstrated on more than one occasion that it is in fact not trustworthy.
Remember the incident involving a falsely-issued code signing certificate for Microsoft? That's right! This supposed paragon of trustworthiness gave some unknown cracker free reign to masquerade as the largest software company in the world. If they're that damned vulnerable to simple social engineering...then why did I pay them $200 or more, again? What exactly were they certifying?
From the start, the entire digital certificate business has been about politics and moneymaking, nothing more. It's a pity that we're forced to live with it.
Er, um, you can. It's trivial to be a certificate authority. You simply need to read a couple of HOWTOs and understand how X.509 certificates work. At MIT for example, we are our own CA. The MIT CA signs all other certifiates, such as certificates for machines that offer secure services, or client certificates for users to authenticate themselves for confidential services. Sure, your browser will claim that it won't recognize the certificate authority. But go ahead and download the root certificate, and tell Netscape you want to accept that certificate authority to certify "Internet sites", and you're all set. You only have to do that _once_. Ever. Just make sure that all your server certificates are signed by the certificate authority.
At MIT we get around the "accepting the certificate authority" problem by re-distributing Netscape with our CA alrady in the database. If your organization isn't big enough for this, then just hand the customers printed instructions on how to do it. Tell them by doing this, you're saving them money, with less costs to pass on.
Commercial Certificate Authorities mean jack shit. All they "certify" is "Joe Schmoe paid me $400, so I will now say that he is who he claims to be." Big fscking deal. Who exactly are they to claim that, anyway? Do they have access to Joe's birth certificate? His passport? His social security record? I had to provide more documentation to get a Massachusetts Drivers License than I did to get a certificate from Verisign. Once the general public realizes this, Verisign will need to find a new source of revenue. I envision a future when certificate authorities can be obtained for a nominal processing free ($30) provided the requestor provides proof of identity (or corporate identity).
There is no sig, there is only Zuul.
Yes, and this is just a preview of the next economic layer that is going to be laid on top of the Internet with the arrival of Palladium. What do you suppose you will have to do to get your content enabled so everybody's PC will be allowed to open it? It's not just a scam, it's maybe the ultimate scam. Inflict the publishing industry's business model on the Internet by taking control of all the hardware connected to it.
These bastards are pure evil.
Almost instant (like 10 minute) issuance.
Trusted by 99% or so of in-use browsers (IE>=5.0, Netscape>=4.x, AOL>=5, Opera>=5).
Works great. Highly recommended.
I would be very hesitant to add you, someone I do not know or have a particular reason to trust, as a CA. I wouldn't mind accepting your self-signed certificate to do an SSL transaction with your site, but adding you as a CA is a much bigger security risk. If I do that, you can then sign certificates for any site, including sensitive sites like my bank's. Then you, as a potentially malicious CA, can trick me into accepting false certificates identifying my bank's site.
Thus if you don't want to use a certificate signed by the major CAs, then please just self-sign. I have no problem accepting self-signed certificates, but adding random sites you don't know as CAs is a huge security risk that no one should do (so it'd be nice if you didn't require people to do it in order to visit your site).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10