Forgot your password?
typodupeerror
Security

Cheap SSL Certificates for Small Websites? 445

Posted by Cliff
from the why-can't-we-be-our-own-certificate-authority dept.
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?"
This discussion has been archived. No new comments can be posted.

Cheap SSL Certificates for Small Websites?

Comments Filter:
  • by r00tarded (553054) on Wednesday October 02, 2002 @06:02PM (#4376973)
    a bunch of excellent geeks I know use entrust [entrust.com].
    • by Anonymous Coward on Wednesday October 02, 2002 @06:04PM (#4376991)
      Title says it all
    • by dildatron (611498) on Wednesday October 02, 2002 @06:08PM (#4377019)
      I just checked them out. Decent prices. Their prices are here [entrust.com] for those who are interested.
      • ...and they use a classic US-centric approach.
        International prices are way higher, an approach similar to Verisign. For non-US customers, Thawte seems to be the best choice. Their root certificate is installed by default in many older browsers.
        • by quacking duck (607555) on Thursday October 03, 2002 @12:07AM (#4378809)
          I used to work there, and there's a fairly good reason international prices are much higher.

          Entrust is a company headquartered in the US but with the bulk of the workforce in the US. When applying for an SSL certificate, there's a very stringent set of rules set out by both US and Canadian governments that they have to follow in order to verify that the person requesting the certificate in fact represents the organization he/she claims to, and that the request for a certificate was authorized.

          Verification requires three independent contacts within the requesting organization. These can be managers, sysadmins, billing, etc. All three need to be contacted.

          Calling these contacts up can get expensive when you handle a lot of international orders. International information like addresses can also be difficult to verify halfway around the world, too, adding more costs. This is partly why Canadian prices scale up with the US exchange rate, but international ones are so much higher.

          The OTHER reason it's a bit higher is that Entrust doesn't WANT to have to handle international verifications, preferring to pass that on to their affiliates located around the world. This way, customers place the order through the affiliated site (at a price that's supposed to be a fair bit lower than the international pricing Entrust itself offers), the affiliate handles the verification themselves. Since affiliates are located in the same geographic area as their customers, they're better qualified to judge whether the info is correct or not. Once the affiliate has verified the information Entrust issues the certificate.

          So if you're not based in the US or Canada, check the list of affiliates [entrust.com] to see if there's an affiliate in your country that offers lower "international" pricing. Don't mean to sound like a sales agent, but that's why affiliates are there.
    • We built our own PKI with Entrust products. Very good stuff. If they had a marketing department they'd be dangerous.....
  • Thawte (Score:5, Informative)

    by JM (18663) on Wednesday October 02, 2002 @06:03PM (#4376979) Homepage
    They charge $199 for certificate, and have a pretty good service. I've been using them for years.
  • by tiwason (187819) on Wednesday October 02, 2002 @06:03PM (#4376983)
    The stories /. has already had on the topic....

    Why Are SSL Certificates So Expensive? by Cliff with 192 comments on Sunday March 18, @04:48PM
    http://ask.slashdot.org/article.pl?sid=0 1/03/18/18 55230&mode=thread&tid=93

    Are FreeSSL Certs Worthwhile? by Cliff with 8 comments on Friday September 07, @11:50AM
    http://ask.slashdot.org/article.pl?sid=0 1/09/06/04 51218&mode=thread&tid=148
  • by Anonymous Coward on Wednesday October 02, 2002 @06:03PM (#4376984)
    You can use it to create certs, and you can even add your organization to the browsers trusted organizations so the users don't get an error message.
  • QuickSSL (Score:5, Informative)

    by Anonymous Coward on Wednesday October 02, 2002 @06:03PM (#4376985)
    Rackshack.net [rackshack.net] has a link to a $49 QuickSSL certificate [rackshack.net]. I haven't used them, but it sounds like a good deal.
  • by sabat (23293) on Wednesday October 02, 2002 @06:05PM (#4376993) Journal

    There aren't really many options, because the browser has to recognize the signer, and the major browsers only recognize Verisign (and Thawte, which is also Verisign).

    RSA is the company that started Verisign, so you can guarantee they'll not be of help.

    If this is a situation with a limited client base, like a company, you can self-sign and send everyone your CA certificate and have them all import it into their browsers (all browsers support this, I believe). But what a pain.

    I wish the news was better, but you're right -- it's a scam. The problem isn't technical; it's political.

    • and Thawte, which is also Verisign

      WTF? How? Do they get their service through Verisign, or are they held by Verisign now?

      Arrrrg. Verisign is the hydra...
      • Verisign bought Thawte about 2 years ago.

        As I understand it, Thawte mostly deals with customers outside of the US (which has been their domain for years). Verisign mostly deals with customers inside the US and Canada.

        I they they are mostly two distinct entities, with 2 different sets of managers (A few managers probably work both sides of the fence). The profits from both entities drop in the same bucket.

        Thawte's support used to be much, much better then Verisign's support. Let's hope they spread the Thawte philosophy among the Verisignites...
    • by 1984 (56406)
      This is somewhat misleading. I bought a cert for a smal personal Web server from Comodo [comodogroup.com], since it was cheap (about $60). It works fine with (i.e. is trusted by) all 4.7x Netscape and above, all IE 5 and above.

      The only point of buying one, after all, being that visitors aren't subjected to confusing warnings about certificates.

      Besides that one certificate I haven't dealt with Comodo so won't recommend at random -- but they supplied the certificate quickly, cheaply enough, and it works.

    • by Slycee (35025)
      and the major browsers only recognize Verisign (and Thawte, which is also Verisign).

      That depends on what you mean by "major browser." Take a look at the list of authorities that Mozilla recognizes, for instance (in prefs > privacy and security > Certificates). It's quite a large list.
    • by lylonius (20917) on Wednesday October 02, 2002 @06:56PM (#4377348) Homepage
      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


    • Anyone know what it would take to be included in the major browsers default certificate list?
  • Thawte [thawte.com] may be worth looking into. They used to be a competitor to Verisign, although now I believe they are owned by them (what isn't?).

    They have certs available for $199. Still not cheap, but better.

    -Pete
  • It is a scam (Score:5, Interesting)

    by dnoyeb (547705) on Wednesday October 02, 2002 @06:05PM (#4376997) Homepage Journal
    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.
    • Re:It is a scam (Score:3, Interesting)

      by ADRA (37398)
      "I think this signing thing is DRM in action. Nobody is realizing it yet."

      I think everyone is realizing it, but doing nothing about it. It is one of those sticky technologies that can be used for good and evil. There is and always will be good uses for this technology like the way it is being used today, but on the other hand, forcing certificates on those that just want secure internet connections seems rather arguable to me, but since it is in spec there isn't much for us to do until I take a flame thrower to all the anal-monopolistic companies.

      Just to clearify the DRM == cert part, I think the nature of DRM forces anyone who implements that security mechanism to use certs.

      The real problem when internet connected devices become more pleantiful, and central authorities like Microsoft and Verisign start signing everything under the sun. Running a program on Windows 2004:

      #bash
      - Error 31337 -
      Problem: This program has not been signed by an
      application trusted provider.

      Solution: Bend over and take it like the
      mule that you are
      -

      #Format C:

      - Error 31337 -
      Problem: This program has not been signed by an
      application trusted provider.

      Solution: You can never escape us! MWAHAHAHAHA!
      -
      • Re:It is a scam (Score:3, Interesting)

        by RAMMS+EIN (578166)
        ``forcing certificates on those that just want secure internet connections seems rather arguable''
        Right. That's a point I forgot to make in a previous post. Most of what I know about certificates comes from research I did in an attempt to offer users of my services a secure connection. Turns out the only way to enable https connections is by using certificates. Of course, I didn't want to fork out all this money just for test-driving the system, so I went for self-signed certs. This popped up a security warning whenever the secure connection was requested (unless disabled after the first time), in effect reducing people's sense of security instead of increasing it.

        I see the point in using certificates. It's an excellent way to ensure the entity you're communicating with is in fact the entity you think you're communicating with (although, of course, CAs are run by people, and people are flawed). I see why certificates are expensive; there is a lot of work in deciding whether the requester is thrustworthy or not. Certificates are not my problem. My problem is: Why do we need them if all we want is encrypting communications?
    • by serutan (259622) <snoopdoug@geekazon . c om> on Wednesday October 02, 2002 @09:46PM (#4378263) Homepage
      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.
  • I would just go for one of the thousands of web hosts [google.com] that give you some sort of SSL package. Unless you need your very own certificate, they are definately the way to go for the small business because the host purchases the stuff and just charges you a small fee.

    If this is not acceptable for your situation, then I am afraid you have to bite the bullet and front the money.

    But don't get lost in the middle - remember the whole reason you are using SSL is for security. Whether the certificate comes directly from you or your webhost doesn't really matter as long as it is secure. That's why I would recommend that you let them pay for it and disperse the cost among their users.
  • Comodo - $49 (Score:2, Informative)

    by wooft (608721)
    Comodo [comodogroup.com]

    You can even get a free 30-day trial cert.

  • by pablos (122458) on Wednesday October 02, 2002 @06:11PM (#4377034)
    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.
    • If I go to a page and an applet pops up that says "You are about to run an app signed by foo.com. Geotrust asserts that this really is foo.com" I'm going to say "who the hell are Geotrust" and hit cancel.

      -a
  • by kylegordon (159137) on Wednesday October 02, 2002 @06:11PM (#4377035) Homepage
    You may find what you're after over at http://www.cacert.com [cacert.com] The creator of this website believes that trusting someone should be free, and is doing his best to make this happen.
    • by V. Mole (9567) on Wednesday October 02, 2002 @06:42PM (#4377253) Homepage

      Nice idea. Unfortunately, the MD5 fingerprint on the root certificate doesn't match what the webpage claims it should be. This leads to doubts...

      I suspect what happened is that they issued a new certificate on September 15th, and forgot to update the webpage. But that kind of sloppiness is not reassuring, and the fact that nobody has fixed it in 17 days indicates that it's probably not very widely used. (And yes, I e-mailed the webmaster about the problem.)

  • Easy one (Score:5, Informative)

    by shurdeek (571257) on Wednesday October 02, 2002 @06:11PM (#4377038)
    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.
    • That's interesting (Score:5, Informative)

      by petard (117521) on Wednesday October 02, 2002 @06:37PM (#4377223) Homepage
      WhichSSL [whichssl.com] is nothing but an ad for Comodo:

      Registrant:
      Comodo Research Lab Ltd
      10 Hey Street
      Bradford, Yorkshire BD7 1DQ
      US

      Registrar: Dotster (http://www.dotster.com)
      Domain Name: WHICHSSL.COM
      Created on: 25-JUN-02
      Expires on: 25-JUN-04
      Last Updated on: 25-JUN-02

      Administrative Contact:
      Abdulhayoglu, Melih steve@comodo.net
      Comodo Research Lab Ltd
      10 Hey Street
      Bradford, Yorkshire BD7 1DQ
      US
      +44 1274 730505
      +44 1274 730909

      Technical Contact:
      Abdulhayoglu, Melih steve@comodo.net
      Comodo Research Lab Ltd
      10 Hey Street
      Bradford, Yorkshire BD7 1DQ
      US
      +44 1274 730505
      +44 1274 730909

      Domain servers in listed order:
      DNS01.EXODUS.NET
      DNS02.EXODUS.NET
      DNS03.EXODUS.NET
  • InstantSSL (Score:3, Informative)

    by aldjiblah (312163) on Wednesday October 02, 2002 @06:11PM (#4377039)
    Just switched from Thawte (adding $100 each year for your certificate services is NOT a good way to hold on to your customers, Thawte!) to InstantSSL [instantssl.com].

    At $49 a piece for standard certificates they're the cheapest my company could find when we went looking last month. So far I have no problems recommending them.

    • Re:InstantSSL (Score:2, Informative)

      by Snap E Tom (128447)
      I'll vouch for InstantSSL/Comodo. I'm using it on a local non-profit site [sspca.org]. $49/year gets you a 128 bit certificate. They've got a 30 day trial program, and their support staff was very helpful when we had a problem.
    • Re:InstantSSL (Score:2, Interesting)

      by letxa2000 (215841)
      I just switched from Thawte to InstantSSL, too. I didn't even know there were cheaper alternatives now available until I had a run-in with Thawte over their procedures during my renewal process, which caused me to go shopping. Saved some good money in the process.

      I started an online store on my site in September 2001. At the time I couldn't find anything cheaper than Thawte. I went through all the paperwork hassles, process, etc. and eventually got one--though it was issued to me personally because they had weird requirements to prove my business existed (even though it was listed in DUNS, has been in business since 1993, etc.).

      Last month it was time to renew. I wasn't looking forward to it but I figured I'd just be able to pay the bucks and be done. But NO, Thawte presented me with a whole new set of documentation that I had to provide. Never mind it was just to prove that I exist personally since the certificate was issued to me as a person, not the company. Never mind we had already gone through this the year before and nothing in the certificate was changing.

      I got supremely pissed off and did some searching. Found InstantSSL by Comodo. The standard cert is $49/year with discounts available if you purchase more than 1 year at a time.

      A little skeptically I signed up with them. I had my certificate the same day with no need to provide paperwork because their system was able to establish the existence of my company. And it was registered to my company (as it should be), not to me personally. Pleased with their service I purchased another certificate for another site I'd been meaning to get secured--since they already had certified my company that cert took about 2 hours to reecive.

      I gave Thawte the 1-finger salute. I asked for a refund for the renewal I had initiated and purchased 2 years with InstantSSL for less than I was going to pay Thawte for 1 year. This is even better since Thawte is owned by Verisign, so by going to InstantSSL I effectively am free of Verisign. Always good.

      I highly recommend InstantSSL. It's the Godaddy of SSL certs. :)

  • by Chuck Chunder (21021) on Wednesday October 02, 2002 @06:12PM (#4377045) Homepage Journal
    comes with openssl [openssl.org]. 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.
    • Seriously, why SHOULDN'T you do this? The only thing Verisign does is take exorbitant amounts of money to "prove" you are who you say you are. But if you don't trust someone at their word, you probably don't want to do business with them in the first place!

      I'd suggest that doing this even for sites used by the general public is OK. Just put a quick explanation on the site. The exception might be if you're running a large operation collecting credit card numbers, in which case you can afford Veri$ign's price and don't want to lose a bit of business.
      • The average user becoming used to ignoring security warning is a bad thing.

        Part of the trust involved isn't just that I trust the name I see on the site, it's that I really am talking to to who I think I am. Remember, I can create a self signed certificate for www.abcd.com just as easy as the real owner of www.abcd.com. All I need to do then is hijack his DNS (or get my IP address with his name in your hosts file) and you're talking to me and think you're talking to him. And because we're both using self signed certificates we'd both look as real.

        That's why the third party is important.

        If you have an existing relationship with the people accessing the site (ie you have a channel whereby they can verify the cert once and don't become used to ignoring warnings) this isn't a problem.
    • From the original question:
      Self signing my certificates works of course, but just about all browsers make a big fuss about it.
      Making yourself a CA out of the blue and signing your own certificates is no different in the "big fuss" department, except the browser only makes a "big fuss about it" once for all your websites. So I highly doubt issuing his own CA cert would be any more acceptable to the poster than signing his own cert.

      There is another drawback to becoming your own CA that is much more serious, though. I, as a web user, have no real problem accepting a self-signed certificate for an individual website or two. I'm very very hesitant, though, to accept Joe Schmoe as a CA, as this means I have given him the ability to, for instance, authorize whatever certificate he wants as a valid certificate for my bank's website. This is not cool with me. When I'm sending sensitive data over SSL to my bank (and others), I need to know (as much as possible) that the party on the other end of the transaction is who they say they are. My browser (Mozilla) doesn't offer any way to limit the scope of a CA's power at finer granularity beyond "this certificate can identify web sites."

  • by antis0c (133550) on Wednesday October 02, 2002 @06:13PM (#4377052)
    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.
    • 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). [...] Other than that, cost of this service isn't going to drop very dramatically without losing its verification services.

      That would be a fine argument if they actually do any significant verification. My impression is that they don't.

      I think it's foolish to rely on VeriSign or anybody else to guarantee that the company on the other end is who they claim they are. And you don't need that anyway--you don't get that protection for mail order either, and, besides, lots of people can get your credit card number without all the hassle of setting up a web site.

      What matters ultimately is the money trail: not VeriSign, but MasterCard, needs to know where your money went and get it back for you. That's their responsibility as credit card companies.

      • by antis0c (133550) on Wednesday October 02, 2002 @06:45PM (#4377267)
        I agree. Thats why I said "VeriSign is suppose to" and not "VeriSign does". Obviously they don't, remember the whole fiasco with them giving out a cert to someone posing as Microsoft? I'm just saying, thats the idea. I don't agree with it. :)
    • 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).

      knowing your social security number does not make me you. it makes me someone who knows your social number. nothing more. nothing less.

      while a lot of people seem to think they know the mechanics of cryptography pretty well (and probably do), there still seems to be a lot of people who aren't really in the habit of thinking where security supposedly comes from in any given scheme.

  • RSA Who? (Score:3, Funny)

    by Blrfl (46596) on Wednesday October 02, 2002 @06:13PM (#4377054) Homepage
    Never heard of 'em. Must be some fly-by-night operation. :-)
  • Try out FreeSSL.com [freessl.com] - they used to give fully signed SSL certificates away that lasted for three months.. I read that they were planning to offer free 'year' certificates.

    They also currently offer a ChainedSSL certificate at a cost of $25 per year...
  • For the 85-90% of you using Internet Explorer, take a look at Tools->Internet Options->Content->Certificates->Trusted Root Certification Authorities.

    The established certification companies are already on this list. You are not. If you self-sign, you are basically counting on your potential customers to trust you as a certification authority. They can add you to that list individually. The question is, will they?

    Since you are an unknown, small company, basically your customer has to trust that you have done everything right in order to protect their security. That's a lot to ask someone. Having a big player certify you tells your potential customer that even though you are a small unknown, you have done everything right.

    It's just my personal opinion, but its one based on running an e-commerce site for the last four years. Go with an established certifier. If you are doing any sort of business at all online that requires SSL you will more than make up the annual fee in the sales you don't turn away because you were too cheap to get a real certificate.

    • Its easy to click-through with internet explorer. But what if you've got Netscape 6 or Mozilla?

      Sure, its easy to use https mode, but what if you want to sign applets?

      Its a REAL pain. You have to download a public key, open up a console, find your certificate store, and manually add it.

      I made something [freeshell.org] that I wanted to do that with. What a pain!
  • Has anybody used InstantSSL [instantssl.com]? They claim to work with IE 5+, NS 4+, AOL 5+ and Opera 5+, which they say is 99% of the browsers in use out there. Sounds like a good deal to me.

    I'm looking at using the cert to do some credit card auth for a webhosting company, and I don't really think I'd have a problem turning away that 1% of people who can't upgrade to a browser that came several years ago. That whole 80/20 rule kicks in there. I'm sure somebody who can't be bothered to upgrade to a modern browser is going to be a tech support nightmare.
  • by coyote-san (38515) on Wednesday October 02, 2002 @06:28PM (#4377142)
    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.)
    • By any chance, can somehow give a link to a good reference on how to set up your own CA? mod-ss-makecert makes self-signing really easy, but I have no idea what's involved with making a CA.
      • The parent post is exactly how we do it in our organization (a non-profit with not a lot of money for certs, but lots of things we want to run over SSL). Once someone trusts your root cert you're good to go.

        I mostly figured out how to set it up from the Apache mod-ssl module FAQ at http://www.modssl.org/docs/2.8/ssl_faq.html#ToC29 [modssl.org]. BTW, mod-ssl comes with a nice little signing script that is quite handy.

        Once I got the hang of it with Apache sites I used the technique in the FAQ almost verbatim to produce certs for our IMAP and SMTP servers.

        You might also check out http://www.openca.org/. I'm not using it, but if I was starting over I would be looking into it.

    • by Trepidity (597) <delirium-slashdot@@@hackish...org> on Thursday October 03, 2002 @02:51AM (#4379189)
      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).
  • In Mozilla, anyway, you can see a list of the trusted certificate authorities. There's a lot of them in there; Verisign couldn't have bought all of them (yet).

    I think a lot of people out there use some other browser than Mozilla, though, so you might want to see what certs that other browser supports.

  • by giminy (94188) on Wednesday October 02, 2002 @06:32PM (#4377177) Homepage Journal
    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.
    • I'd love you to explain this one. Who sells key pairs and how do you make the certificate show that it was verified with the intention of accting as a CA?
      I have a horrible feeling this is a +5 troll... anyone got a link to prove me wrong?
      • Who sells key pairs...

        Verisign.

        ...and how do you make the certificate show that it was verified with the intention of accting as a CA?

        You don't make the certificate show that, but IE doesn't check correctly. That's the point.

        I have a horrible feeling this is a +5 troll... anyone got a link to prove me wrong?

        Yes, this [securityfocus.com] explains in more detail.

  • by Eric Seppanen (79060) on Wednesday October 02, 2002 @06:40PM (#4377235)
    CA links [pki-page.org]
    CA links [netscape.com]
  • by mystik (38627) on Wednesday October 02, 2002 @06:52PM (#4377329) Homepage Journal

    ... 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 ...)

    • openssl req -newkey rsa:2048 -keyout ca.key -out ca.req - Answer all questions it asks
    • openssl x509 -signkey ca.key -req -out ca.crt -in ca.req -days 1200 - Self- signs the CA certificate
    • openssl x509 -signkey ca.key -trustout -req -out ca-trust.crt -in ca.req -days 12000 - produces a "Trusted certificate"
    • use the first step to generate any other certificate requests. Some servers like IIS & Domino have their own request-generation tool.
    • openssl x509 -CA ca-trust.crt -CAkey ca.key -req -days 360 -in certificate-request.req -out cert.crt -CAserial ca.srl [-CAcreateserial] - to sign requests. The first time, you'll have to use CAcreateserial

    That's pretty much it. mix into your IT operations as nessecary

    • I would recommend making the CA certificate's key absurdly large, say, 16384 bits long, particularly if you want it to last 30+ years.

      The idea is that this is the thing the users are going to have to all import into their browsers. You don't want to make them do it more than once. But the whole reason keys expire is that with concerted effort over time they can be factored. So you need to make the key length proportional to the expiration period in at least an attempt to insure that the key will remain secure over its lifespan.

      The server cert should have a much smaller key, say a kilobit, because it's used a lot more than the CA cert (validating a server cert will be "hard" because its signed by a 16 kilobit key, but once it's done, the certificate is known-good as long as it remains valid), but because of that it should expire anually. But since you have a long-lived CA cert key, the users won't have to do anything when you do replace the server cert.

      Of course, all of this is tempered by how paranoid you need (or want) to be.

  • by adamy (78406) on Wednesday October 02, 2002 @07:09PM (#4377432) Homepage Journal
    Certs prove you are who you say you are, not that you are a reputable company. Otherwise, someone can spoof your IP address and or domain name, collect your clients secure information, and the whole process is encrypted using the attackers keys, not yours.

    It is a boot strap problem. Since your clients connect to your over the web, there is no way to prove that you are really you. Instead, you say, my CA (e.g. Verisign) says I am me, and hand them something they can use to verify that info. The browser checks the cert that your site offers, and using the Verisign public key, can ensure that you are actully signed by verisign. The fact that Verisign's public key was shipped with the browser means that the trust chain goes like this:

    Install disk (or Download from Mozilla site)->Verisign->You

    You can become your own CA, but that borken link is still there.

    Another option is to use something like PGP or hand delivered Certs, which would work for an internal website or a limited audience.

    Adam
  • I use InstantSSL [instantssl.com] (Comodo) [flash alert]. Works great. A little Apache tweak, nothing on the client side, and haven't found an unsupported browser.

    Best part: $49.

    S

  • by Fastolfe (1470) on Wednesday October 02, 2002 @07:42PM (#4377637)
    This is the situation where we need the government to step in. We're all getting driver's licenses from the government, passports, etc., and these are really the only real-world pieces of identification people accept. What we need is for the government to step in and issue digital ID's, to individuals and corporations. These ID's would tie us to whatever electronic identifiers are appropriate (domain names and/or e-mail addresses), and appropriate delegation would be permitted from there.

    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 [w3.org], provided we have a common framework to start sharing the assertions.
  • If you are using it for extranet type functionality and don't need customers to use it, and you have skills but no money, create your own certificate, set up a server to do authentications (it keeps private key and is used to issue new certs), and then add your own server as a root server on each of your company boxes.

    -Frums

  • Big Fuss? (Score:2, Insightful)

    by wdr1 (31310)
    How is a pop-up a big fuss? Also most browsers allow you to permentantly accept the certificate as valid, don't they?

    -Bill
  • What about governments providing a non-profit cert service? Sure, there is the typical caveat of having to "trust" the government...but how much do you really "trust" Verisign anyway? Governments already certify physical documents...why not electronic ones? You could just get a cert from the government covering the region you operate in (ok, I know on the net this can be worldwide)...from city, to state, to regional, to national, or maybe even international. This might also have the effect of localizing the trust - perhaps as a consumer you don't trust a cert generated by some middle of nowhere town or province...
  • Its soooo quick (10 minutes) and soooo easy, and it only costs $120 (last I checked). Doesent even need a DUNS number!!! I love it! No more Verisign for me...

    (no i dont work for them -- haha)
  • 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.
  • by Sarin (112173) on Wednesday October 02, 2002 @08:25PM (#4377882) Homepage Journal
    I wouldn't pay more than $25 for a ssl certificate this a year, which is a reasonoble price, but still too much! Perhaps I'd even make use of a recent bu in ie.

    What is the meaning of this ssl certificate?

    It's less than 1 kilobyte (remember this term from the 80's?) and it's stored on a socalled certified system so they can check if the certificate is true.

    The whole secure web server could be corrupted with a dozen of exploits by missing only a couple of security patches.

    I mean this whole thing does reeks of greedyness.

    Shouldn't be the opensource community bring out their own SSL certificates. The opensource browsers should neglect the standard certificates, since they don't mean anything anyway.
    The certificates that are accepted by opensource browsers are the ones that are certified by a nonprofit organisation, the only way to be recognised by the browser is that the database of this organisation is sure that the server is maintained well.

    What are you paying for otherwise?
  • by xant (99438) on Wednesday October 02, 2002 @08:43PM (#4377976) Homepage
    Verisign does a halfway decent job of checking who you are. Back before they bought Thawte, I purchased genuine certificates from Entrust, Verisign and Thawte, to make sure that our company's web product worked with all three certificates. All of them did a rigorous check, requiring such documents as the company's certificate of incorporation and a statement signed by several authorities in your organization.

    Having established my experience with these entities, I can tell you that CA trust is worthless. Why? Because there are many CA's, and each one of them dilutes the trust pool instead of strengthening it. They each claim to be an "authority", and the browser trusts that they are. Let me ask you this rhetorical question: If you're dealing with 6 bosses, instead of 1, does that make your bosses individually stronger or weaker as authority figures? I would say it makes them weaker, because you don't know which one to really trust.

    The same goes for CA's. Each of them has a different method for establishing trust, but the trust from any one of them produces the same result: specifically, the browser stops warning the user about your website. As soon as that warning message goes away, your users have stopped thinking about your certificate entirely. If they know anything about certificates at all, they probably think you've gone through a rigorous identification process to get a certificate trusted by their browser. Most likely, you have.

    But it only takes one bad CA to ruin it all. One CA that checks only the email address; one CA that doesn't do a follow-up phone call on every single customer, and ALL CA's trust is broken, because now the bad certificates are out there hiding with the good ones, hidden behind the absence of that nasty warning message simply because that bad CA was trusted by your browser. It comes down to: do you trust your browser's choice of Root Certificates? Do you even know how to answer that question?

    You shouldn't, because there are already lazy/cheap CA's giving out easy certificates and their Root Certificates are in your browser, just like everyone else's.

    Paying for a cert signed by a "real" CA is a fool's game. Don't play it. Let their broken business model die.
  • by jdreed1024 (443938) on Wednesday October 02, 2002 @09:29PM (#4378183)
    from the why-can't-we-be-our-own-certificate-authority dept.

    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).

  • by Nonesuch (90847) <nonesuch@msg.nDALIet minus painter> on Wednesday October 02, 2002 @09:40PM (#4378231) Homepage Journal
    Just this week I have started looking around before we purchase a certificate for a semi-private Internet server. I've found the 'WhichSSL.com' site to be very helpful, especially http://www.whichssl.com/faq/compatibility.html [whichssl.com].

    Our users are easily alarmed, so we need to use a certificate from CA that is fully trusted by all of the common browsers. This pretty much limits you to Verisign/Thawte. If you expect that most users will have mostly upgraded to more modern browsers, then your available choices increase dramatically.

    I am currently considering InstantSSL... so far it's taken two days, and no signed certificate, but the price (free trial, $49/year) is right.

  • InstantSSL.com (Score:5, Informative)

    by fwc (168330) on Wednesday October 02, 2002 @11:26PM (#4378667)
    $49/Year.

    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.

  • by iebgener (592564) on Wednesday October 02, 2002 @11:41PM (#4378723)

    You might need a certificate signed by a well known CA for your connections from the internet, but for all your backend server you can create your own CA. This will enable you to use a full strenght 1024/128 bit sll for nothing. There is a project called tinyca [sm-zone.net] which enables you to create and signed certificates with your inhouse CA. So you create a CA for your company and add the CA to all your backend server. Once this is done, any certificate signed by your CA will be valid and fully secured.

    I have tested it for Apache and Weblogic and Websphere and they work very well.

To the systems programmer, users and applications serve only to provide a test load.

Working...