Hi Jakob On Fri, May 24, 2013 at 11:57 AM, Jakob Bohm <[email protected]> wrote: > On 5/24/2013 9:47 AM, keshava jm wrote: >> > [snip] > The intended and proper way to do things is: > > 1. The CA creates its own private key, which is kept in a very secure > place (like a computer with no network connections, rigged with > dynamite to self-destruct if tampered with and placed in a deep > underground bunker surrounded by armed guards instructed to let > no one (not even each other) inside except for the designated CA > head signers, who must enter together to watch each other behaving > properly. > This is what VeriSign Inc (now part of Symantec) and GlobalSign Inc. > did years ago, including the live explosives! > For a private company CA, less extreme measures will do. > > 2. The CA (as the only "person") uses its private key to create a > self-signed certificate with the CA:TRUE attribute etc. This > certificate will have a very long lifetime (decades usually). > > 3. The CA publishes, in some very hard to falsify place, like a huge > stone monument, this certificate, or at least its strong check sum > (SHA-256 or stronger). In the real world, a copy is hand carried > to specific offices at Microsoft, Google and Mozilla who put the > CA certificate into their next software updates. > For a private company CA, the CA certificate is just installed on > all the computers by the head sysadmin, using his boss privileges. > > 4. Each client creates his own private key, which he tries to keep > secure as best he can. Then uses it to sign a "request" (e.g. > with "openssl req -new") specifying what he wants his certificate > to say his name etc. is. > > 5. The client sends this request to the CA front office. Clerks at > the CA front office then performs various checks to make sure the > client really is whom he claims (in the request) to be, and that > it is really him that requested this. If all is OK, they hand the > request over to the CA head signers. > For a private company CA, the clerks are just the regular IT or > HR staff, who know all the employees and servers personally. > > 6. The CA head signers carry a pile of already proven requests they > got from the clerks into the bunker and use commands such as > "openssl ca" to create matching certificates signed by the CA's > private key and listing the name of the CA's own certificate as > the "issuer", each certificate will also have a unique serial > number. While they are there, they also sign a long list of all > the certificates that have been cancelled until to date (a CRL). > > 7. The CA clerks send the signed certificates back to the clients. > They also publish the list of cancelled certificates on their > web site in a file format called a CRL. > > 8. The client now uses his certificate with his secret private key > to sign stuff such as e-mails and checks, each signature includes > a copy of his certificate. > > 9. Each person receiving the signed stuff has previously gone to the > big stone monument and copied the genuine CA certificate into his > computer. Once a day or so, they also download the latest list > of cancelled certificates and checks that it was signed by the CA, > and is dated today. When they receive the signed stuff, they > check that it was signed in a way that matches the public key in > the certificate, that the certificate itself was signed in a way > that matches the public key in the CA's certificate and that the > clients certificate is not on the cancelled list (there are other > checks too, but the computer does all the work). If all is well, > they believe that the stuff really came from the client and that > the client is who the certificate says he is (because they trust > the CA clerks to do this right). > > 10. If the clients private key is ever stolen, the client is required > (by contract and/or law) to tell the CA clerks, who will add the > certificate to the list of cancelled certificates so no one will > believe signatures made by the thief. > The same is done if the client loses his right to the certificate > in some other way, e.g. a company employee being fired from the > job position listed in the certificate, or a server being > uninstalled. > >
This is without question the best and clearest exlanation of all this. Thank you. Do you know of a web resource that explains this just as clearly and which adds information, such as what software is involved in each stage, and how it is used (yes, I have seen the Apache documentation for configuration to use client side certificates, but a reference manual is not the same as a textbook or tutorial). For example, I have seen, and am still investigating, the use of JavaScript in a client's browser to distribute client side certificates (obviously, involving a connection over HTTPS, to a site that requires single use credentials, issued by a RA, along with a series of challenge/responds question and answes to verify user identity), but I have yet to find a JavaScript solution that will work across all browsers (though I would not surprised if someone somewhere has written somethng to do this right). A tutorial that explains, in the framework you laid out so nicely, not only the role of openssl in this, and what the configuration file needs to contain to support not only establishing secure SSL or TLS connections, but also to suport document signing/encypting in order to be able to verify both the identity of the server and of the clientand that the document has not been altered since it was signed. I have, to date, relied largely on Google, but that always results in hits that deal only with tiny portions of what is needed, often mixing documents from many years ago with only a few current ones; there are few resources that deal with this is a clear, coherent and comprehensive manner suitable, e.g., for use in a classroom (or independant study). Thanks Ted ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
