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.)"
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.
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."
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.
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.
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>
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.
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.
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.
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.
Slashdot Mirror
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.
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?
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.
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.