Slashdot Mirror

← Back to Stories (view on slashdot.org)

Creating Your Own CA

Posted by michael on from the snake-oil-enterprises dept.

lisam writes "Rob Flickenger shows how to become your own Certificate Authority, and sign your own, or others', SSL certificates in this onlamp.com article. (He also manages to mention fnords and deny responsiblity for the Microsoft Corporation cert snafu.)"

31 comments

  1. *fnord* by Anonymous Coward · · Score: 0

    Home of the fnords

  2. This is important, but... by rw2 · · Score: 4, Insightful

    It's important the people understand how to do this, but what is missing is some way to understand whether or not to trust a CA. Until your grandma can trivially decide to trust rw2's CAnonical Enterprises, Inc. signing by anyone but the handful of big boys is the most reasonable thing to do.

    1. Re:This is important, but... by 4of12 · · Score: 2, Interesting

      I've thought the only way for a new entity to establish a trust relationship is to tie into some existing entity with a surety bond.

      If rw2 CAnonical Enterprises, Inc. could convince me that some chunk of money backed up any and all claims of their identity, then I'd be willing to transact business using them.

      But I don't see how to do this unless the existing entity is a bank. From what I understand, becoming a bank is no trivial task.

      --
      "Provided by the management for your protection."
    2. Re:This is important, but... by Breakerofthings · · Score: 2, Informative

      Reasonable in that it is easiest, yes. Reasonable that it is the most financially viable option, not necessarily. Not if you need a *lot* of certificates, like I do. Reasonable, to pay VeriSign's extortion? No. No on principle. There is no loss of encryption in not using an "big boy" (which I mean to be an established CA). My ssl is just as secure, in terms of encryption. My only disadvantage is that my visitors have to trust that I am me; I don't have to have VeriSign vouch for me. Arguably, since my CA private cert is in a safe, I am *more* secure, cause I don't have to worry about Verisign F-ing up like they did with MS.

    3. Re:This is important, but... by Sloppy · · Score: 5, Insightful
      No one can really answer that, because there isn't any way for Grandma to know whether or not she can trust a CA. Even if it's the big guys or if it comes with her browser. I mean, from Grandma's point of view, who the hell is Verisign and what did they ever do to merit trust? At best they're just some faceless corporation she's never heard of or dealt with. A cracker CA named "Integro-Trust Digital Signature National Registry (Fidelity Verified)" would have an even better-looking name than "Verisign."

      I don't think you can have real trust without users understanding how things work. Grandma is screwed.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    4. Re:This is important, but... by rw2 · · Score: 2, Funny

      But I don't see how to do this unless the existing entity is a bank. From what I understand, becoming a bank is no trivial task.

      Well, you could always become a bank without becoming a bank... <cough>paypal</cough>

    5. Re:This is important, but... by rw2 · · Score: 2, Insightful

      My only disadvantage is that my visitors have to trust that I am me

      Kind of a big disadvantage one might think...

      Calling it extortion is innacurate, they have trust and that's a big thing. If it were easy to duplicate someone would have done so and competition would drive prices down.

      Arguably, since my CA private cert is in a safe, I am *more* secure

      You can argue that, but it's a loser. People are far, far more lax about security than verisign is.

    6. Re:This is important, but... by Anonymous Coward · · Score: 0

      : I don't think you can have real trust without users understanding how things work

      But do those who understand how things work trust anyone? I don't trust the certificates to prove identity at all. I view them as useful for encrpytion (https) and nothing else..

    7. Re:This is important, but... by rw2 · · Score: 1

      The parent is a brilliant example of how a little knowledge can be a bad thing.

      Dude, unless you *trust* the cert your 'encryption' is worthless.

    8. Re:This is important, but... by Breakerofthings · · Score: 1

      Kind of a big disadvantage, one might thing...
      Heh. Yup. No doubt about that. But, I think, easily dealt with in my specific circumstances (or I obviously wouldn't go that route)

      Calling it extortion is inaccurate, they have trust and that's a big thing. ...

      It is not trust that they have. It is the fact that they are installed in browsers out of the box. I don't trust VeriSign; neither does my grandmother; she's never heard of them. But Microsoft (et al.) have decided for her that VeriSign, Thawte, etc are trustworthy.

      You can argue that, but it's a loser. People are far, far more lax about security than verisign is.

      What the hell? Verisign is a company. That is, Verisign is a bunch of people, operating in the form of a bureaucracy. Point A: people tend to get stupider in large numbers. Point B: Verisign has demonstrated on more than one occasion, and in more than one manner that they are careless and/or generally untrustworthy.

      Besides; we are not talking about "people" in general here ... I gave myself as a specific example; you know nothing of my security practices, how can you even begin to back up a statement that general?

    9. Re:This is important, but... by rw2 · · Score: 1

      It is not trust that they have. It is the fact that they are installed in browsers out of the box.

      They have the trust of the browser vendors. You say this yourself. This is no small bit of trust.

      What the hell? Verisign is a company. That is, Verisign is a bunch of people, operating in the form of a bureaucracy.

      That's right. And, regardless of whether you accept a Randian world view or not, each of those people are looking out for their own best interest. That means that security on the systems is likely to have been designed well, the audits to find holes are likely to have been done properly, the customer service has provided feedback to make it more likely that their product is used properly. On and on and on.

      Verisign has done a mostly excellent job of providing a robust service.

      Point A: people tend to get stupider in large numbers.

      This is simply false. People without common goals tend to do stupid things while sniping at each other. But to say that, for example, GE is doomed because people get stupider in large number is, well, stupid. It's not even a recent phenomena for heavens sake, the great wall of china was built by a large number of people, so were the pyramids. Those two are examples of engineering that is far from stupid.

      Point B: Verisign has demonstrated on more than one occasion, and in more than one manner that they are careless and/or generally untrustworthy

      I disagree with this. Showing me one example (the microsoft one) doesn't show that they are 'generally' untrustworthy. And more to the point, it certainly doesn't come close to the level of proof needed to show me that they are less trustworthy than having 100 million net users manage their own private keys.

      Besides; we are not talking about "people" in general here ... I gave myself as a specific example; you know nothing of my security practices, how can you even begin to back up a statement that general?

      I didn't say *you* couldn't, though I doubt you can unless you work in security. I work on the fringes of security everyday and am glad that kerberos, and the professional security types at my lab, are managing my keys instead of me.

    10. Re:This is important, but... by vadim_t · · Score: 1

      Care to explain that?

      First, trust isn't vital in all circumstances. You *need* to trust the cert if you're doing something like buying stuff online. That's logical, you need to be sure that the site is owned by the company you expect, and not a script kiddie.

      For other things, like a mail server, this makes little sense. If you log into your SSL IMAP server, it accepts your password, and that's actually not your server and somebody managed to set up an alternate server with a copy of all your mail in it, then trust isn't going to help.

    11. Re:This is important, but... by rw2 · · Score: 1

      Care to explain that?

      Sure. The point of encryption is to secure a connection. If you can't trust the cert, then you can't trust the encryption. Ergo, you may as well be using plaintext.

      For other things, like a mail server, this makes little sense. If you log into your SSL IMAP server, it accepts your password, and that's actually not your server and somebody managed to set up an alternate server with a copy of all your mail in it, then trust isn't going to help.

      Huh? I don't follow this. Are you saying that because they copied your mail the security doesn't matter? What of a man in the middle attack?

    12. Re:This is important, but... by vadim_t · · Score: 1

      Okay, let me explain.

      All a trusted cert certifies is the identity of the owner. That's all. You want it to buy stuff online, because of course you want to have some guarantee of that you're giving your credit card number to the right person. All a certificate signed by Verisign gives you is their confirmation: "This guy paid us for the certificate, and presented us documentation that identified him as John Doe"

      For other things, trusting a cert doesn't matter so much. The connection is encrypted regardless of trust, so you can be sure that there's nobody in the middle sniffing the data. That's actually as good as it gets. Verisign will give a cert to anybody with money and a proof of their identity. It won't save you from an evil sysadmin who suddenly decides to make your mail public, for example.

      I use a SSL connection to a Jabber server that uses a self-signed cert. What does that give me? All data between my server and me is encrypted. That means that my ISP can't know what I say to people, or what people say to me. Trust isn't really an issue here. Pretty much everybody else uses an unencrypted connection to ther IM server.

    13. Re:This is important, but... by rw2 · · Score: 1

      Ok, I see what you're saying. But you're talking about something different.

      Trusting the cert does matter. Because it is an identification of a policy. You acknowledge as much when you say that Verisign was presented with "documentation that identified him as John Doe".

      I agree that this matters for commerce. But I disagree with your comment that it doesn't matter for much else.

      You, for example, use a self-signed cert to talk with your SSL based Jabber server. Why do you do this? Because you trust the cert. You trust that it was signed by someone that won't let your Jabber server be spoofed by a man in the middle. In this case, that person is you.

      But do you think that anyone should trust that unknown CA? Should I, when presented with a CA that I don't know the policy of simply accept the cert? No, of course not, to do so would allow people to read my IM stream. Do I care about this less than my back account, sure, but not a ton less. My credit cards are insured against fraud, so what do I care if someone steals them. Heck, that happened to me just last year.

      I agree that your self-signed cert protects you against people snooping your connection. I just don't agree that trust isn't an issue. It is an issue, and you've chosen to trust yourself as a CA.

    14. Re:This is important, but... by vadim_t · · Score: 1

      Hmm, I think I didn't explain very well. The self-signed cert on the Jabber server wasn't made by me. It was made by some random person somewhere. To explain why in this case a Verisign cert doesn't matter much, let's compare:

      Unencrypted connection:
      Data transferred as clear text. It can be snooped easily.

      Encrypted with self-signed cert:
      Data encrypted with SSL, but no signature from Verisign.

      Encrypted with signed cert:
      Data encrypted with SSL, with a Verisign signature.

      What's the difference between those two? That Verisign claims to know who that guy is. Does it do me any good? Not much, probably. I could trust Verisign to check that the certificate includes the real name and location of the server's owner, so that I could say, try to sue him if he decides to log all my messages and put them on his site. Or maybe they could revoke his cert, which they most certainly won't do. After all, how do I prove that the embarrassing log published on foo.com is mine? There's no sure way for me to prove it.

      This probably won't do me much good, however. Suing somebody in another country, whose server I used without any kind of agreement (even clickthrough one) could be complicated. And I could do that without Verisign anyway, I'd just have to hope that the whois info for the domain name lists the right name and address.

      I think you're a bit confused about what a 'signed by Verisign' cert means. It means that Versign says it knows the cert's owner. It's the same thing as if your friend Fred comes to your friend Joe with a piece of paper signed by you, to prove that he's somebody you trust. This has absolutely nothing to do with the effectiveness of the encryption itself.

      Trusting a random CA has the same effect as Fred deciding to trust Joe when he gives him a letter signed by some random person he never heard about. But again, this doesn't have any influence on Fred's and Joe's ability to have a private talk.

      For people to be able to read your IM stream, one of these things should happen: The encryption is broken, the encryption is brute forced, the server's private key is compromised. That last option is the most likely, and is archieved by breaking into the server, or the owner giving his private key to somebody else. Verisign's signature doesn't matter at all for this.

    15. Re:This is important, but... by rw2 · · Score: 1

      For people to be able to read your IM stream, one of these things should happen: The encryption is broken, the encryption is brute forced, the server's private key is compromised. That last option is the most likely, and is archieved by breaking into the server, or the owner giving his private key to somebody else. Verisign's signature doesn't matter at all for this.

      This isn't true. There is a third option, I've mentioned it a few times. A man in the middle attack. This is why the trustworthiness of the CA is important.

      If you can't trust the CA then I can get a cert signed (or sign one myself with my CA) and position myself between you and your jabber server. When you try to connect to the jabber server you instead connect to me, I see the text in plaintext because the channel was encrypted using the cert that I provided you. I then turn around and contact the real jabber server and forward the traffic. Thus, to you it looks like you've connected directly, but I've managed to read the entire stream. This occured because the CA wasn't trustworthy and you trusted it anyway.

      You keep focusing on the stream after it's been established. I agree, any cert, signed or not by any CA is sufficient to encrypt a channel. It is not, however, enough to *secure* a channel. For that you need to better identify the holder, which is were trusting the CA comes in.

    16. Re:This is important, but... by vadim_t · · Score: 1

      It doesn't completely exclude a man in the middle attack. Here's an example:
      seerver.com (notice the second e) gets a Verisign cert. You mistakenly connect to it. Your client happily says "Trusted cert found, okay?". If you don't look very well and say "okay", then seerver.com can start a connection to server.com, and read all the data in between. This isn't hard to do, after all, what's the server? jabberserver.com? maybe .net or .org? It's quite possible to catch at least a few people this way. For an example of this, see whitehouse.org. Verisign would sign their cert just fine.

      A second option is that you break into my jabber server, take the cert, and use that for your attack. This should work as long as the Common Name matches your domain name. Then, the program might be brain damaged and not check that at all.

      A self-signed cert isn't completely vulnerable to man in the middle either. There's nothing that stops me from remembering what cert was used by the server. If you get in the middle, the cert will be different, signed or not, and I will be warned. This is how SSH works, for example, if I connect to a system whose key changed I will get warned. Knowing the fingerprint of the cert can be good enough as well to determine that you're connecting to the right server.

      While I finally understood what you were saying, I still think that a signed cert doesn't offer an absolute guarantee everything is fine, and a self-signed cert isn't completely insecure either.

    17. Re:This is important, but... by rw2 · · Score: 1

      It doesn't completely exclude a man in the middle attack. Here's an example:
      seerver.com (notice the second e) gets a Verisign cert. You mistakenly connect to it. Your client happily says "Trusted cert found, okay?". If you don't look very well and say "okay", then seerver.com can start a connection to server.com, and read all the data in between. This isn't hard to do, after all, what's the server? jabberserver.com? maybe .net or .org? It's quite possible to catch at least a few people this way. For an example of this, see whitehouse.org. Verisign would sign their cert just fine.

      While this is all true, it doesn't for a moment have anything to do with the issue at hand, whether or not you the CA signing a cert must be trusted. I never asserted that the signing CA was the *only* thing that must be trusted. It is, however, part of the chain.

      In your example, the user must also be trusted to connect to who they want to. seerver.com was correctly identified and the user errored in his typing. The user can still trust that seerver.com is who versign says it is.

      A second option is that you break into my jabber server, take the cert, and use that for your attack.

      Yes, this is a point where PKI is weaker than some other approaches. It too, however, is orthogonal to whether or not the CA must be trusted.

      A self-signed cert isn't completely vulnerable to man in the middle either. There's nothing that stops me from remembering what cert was used by the server.

      Strictly speaking I claim that the CA must be trusted. I've also argued that there should be a system by which people can more easily gage whether or not to trust a CA. I've not said that a signed cert was, a priori, untrustable. In fact, as in one of you examples I think, a self-signed cert *can* be better because you know that no one spoofed verisign. If they spoof you, however, then the issue remains the same. The CA must be trusted.

      While I finally understood what you were saying, I still think that a signed cert doesn't offer an absolute guarantee everything is fine

      Agreed. It is, as I say above, an essential building block. Without faith in the CA the entire foundation crumbles.

    18. Re:This is important, but... by Anonymous Coward · · Score: 0

      If you log into your SSL IMAP server, it accepts your password, and that's actually not your server and somebody managed to set up an alternate server with a copy of all your mail in it, then trust isn't going to help

      This is untrue. SSL negotiation takes place *before* the password is sent. If the mail client validates the certificate (many don't), you would have avoided ever sending the password.

  3. Why? by Itsik · · Score: 4, Insightful

    The information that the article mentions above, has been readily available on line in various howto's.
    Just follow the instructions that come with OPEN SSL or MOD_SSL.

    Why is it that slashdot found it 'news' worthy?

    1. Re:Why? by Anonymous Coward · · Score: 0

      Maybe the fact that the various HOWTOs may not be as easy to understand (particularly mod_ssl's documentation) or are too filled with confusing TLA's and hackneyed terms.

      Why is it that people want choice but turn around, bitch and moan when someone writes an article that, although may have been written already many times, is geared towards people who need a wee bit more hand holding.

    2. Re:Why? by Itsik · · Score: 1

      With all due respect. There are some things that ought to be somewhat complex. When one deals with network security one might want to make sure that he/she actually knows what their doing.

      I find it hard to believe that the book 'Sappers for Dummies' would appear on the shelves any time soon.

  4. Weak by Breakerofthings · · Score: 4, Informative

    While I frequently find valuable information in Oreilly's articles, such as this one, this one is nothing but fluff; purely a plug for the author's book. The exact info is available in the docs that come with OpenSSL, as well as in the OpenSSL animal book.

  5. Howard? by CableModemSniper · · Score: 1

    Are you there Howard?

    Tekeli-li! Tekeli-li!

    All hail Discordia!

    Feh, sorry this was so lame, I couldn't think of anything really funny. I just couldn't resist after seeing the example names, locations, etc. he used.

    --
    Why not fork?
  6. Who can you trust? by dpilot · · Score: 1

    Let's face it, Grandma doesn't know squat about trust, in this context. She probably doesn't even know that the concept is important. We're doing well to make sure that Grandma looks for the little lock in the corner of the browser whenever she enters private information.

    As for trust, Grandma trusts whoever set up the computer for her, and it effectively means that she trusts Microsoft and/or Netscape (or maybe Opera) for putting those little locks on her browser.

    Are there any legal issues to violating the chain of trust implied by that little lock in the corner? Obviously if money is stolen, there are laws in place. But what about the trust, itself?

    --
    The living have better things to do than to continue hating the dead.
  7. I was hoping they went further by Gerry+Gleason · · Score: 2, Informative
    Pretty disappointing. Anyone at /. that is interested in CAs and such should already be aware that OpenSSL has all the functions for manipulating the various file formats involved if you have the time to grok the command line interface to all of this.

    I can give you more help right here and clear up some stuff they glossed over. First, a certificate is not a public key, but it includes the public key, and it is signed by the private key of the Certificate Authority (CA). In the example, a 'root' or self-signed certificate is created. The private key is typically password protected when it is stored (you can see it prompting for that password in the script).

    He doesn't show you what you have to do to create the '.csr' file that is used to create the actual site certificate, but this is what is called the Certificate Request. Also, the '.key' file should be created in a separate step. The process is that when someone wants a certificate, they generate a request on their computer that includes all the 'name' information (as displayed in article) and the public key. The private key is generated at the same time, but it should never leave the site generating the request, and additional steps should be taken to protect it from being exposed. The article implies that the key pair is generated by the command given, but I don't think it is (a separate step is needed to create the .csr file, and it should be created then).

    A few more notes: your new '.crt' (the certificate) file will show up in 'newcerts' (if not, then 'certs'), the 'serial' file is the serial number of the next (or last) cert issued, and the 'crl' subdir is for the "Certificate Revocation List" all CAs should have one, and it should list all the certificates issued by this authority that have been revoked (by serial number, I think). AFAIK, this is the biggest hole in the process. To correctly verify the validity of a cert, you should always check the cert's serial number against the CRL, but where to you get the CRL? There must be a standard way to get the current CRL from a CA, but does a browser or other client have any function to get it before validating a certificate? Nothing I've seen indicates that clients do this so I doubt whether revocation is ever effective in a practical sense.

    Now, what would be really cool is if someone wrapped the functions to create a certificate request with a few web pages and provided a howto describing how to set this up and really run your own CA. If I was doing it, I would keep the CAs private key on external media (a floppy or CD/R), and only put it in the system when I need it to sign certs and CRLs. Isolating the system you use for this is better, but you do still have to get the requests in and the certs or CRLs out.

    One final comment. It is just about impossible to actually protect the private key for a typical web server. Or at least protect it from root exploits. This is because you have to either not use a password so that your web server can restart without a password, or have some script that provides the password on startup of the web server. The only other choice is to have someone actually type it whenever a server needs to be restarted, and I don't have to point out here what a pain this would be for a big server farm.

  8. Rob Flickenger by larry+bagina · · Score: 0, Offtopic

    No offense, i've never met the man, but that name sounds like someone who puts his finger up his ass to pick it and shoot dingleberries at other people.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  9. Certificate Revocation by Anonymous Coward · · Score: 0

    Is there anywhere in all that documentation that it talks about a Certificate Revocation List? I would assume they would have included the ability to revoke a certificate, but I didn't see it listed.