> Here is my understanding about a real CA. > A real CA would be an agency or like, which would have the infrastructure > required to sign certificate requests (say openssl toolkit, its own key > pair, its own root certificate etc). In addition to this, it would have > capabilities / mechanism to verify the information provided by > the requester > (subject) in the certificate request. Once the CA verifies that the > information provided in the certificate request is correct, it would sign > the request, and provide the signed certificate to the requester > (subject). > > If I am missing anything that is important to know, I will be really happy > to learn about it.
What you're missing is the policies they employ to protect their private keys. If you don't employ anywhere near that level of security, you should definitely not be asking people to add your CA certificate to their browsers for Internet use. Whether your level of security is sufficient for non-browser programs or networks other than the Internet is a question only you can answer. But the expert consensus for browsers on the Internet is that this is not nearly sufficient security. > Hmm ... So are you suggesting that my clients would store the certificate > produced by the server, the first time they connect to the server, and > thereafter each time they connect to the server, they check if the > certificate has changed? It depends upon what the client needs to determine. If the clients needs to know if it's talking to the same server it was talking to before, then this is the perfect way to do that. > As I understand, a self signed certificate can be verified using > the public > key present in the certificate iteself. So how can my client detect the > change in the certificate unless they store the public key (or the > certificate itself) the first time they connect to the server, > and then for > every successive connection attempt, check the certificate presented with > this stored public key / certificate ? > Am I still missing something? If they don't care if it's the same server each time, then what do they care about? What's the point of this entire exercise? > > The problem is that anyone who has access to your installer can > > impersonate > > any server. > Absolutely true. > > Whether or not this is acceptable depends upon a few factors. I > > would submit that if your client is a traditional program like IE or > > Firefox > > and your target network is the Internet, this is absolutely > > unacceptable. > > If > > your client is custom software and/or your target network is > > private, this > > might be reasonable. > Right. Now, my clients are custom software and the target (as of now) is a > private network. Then you can choose any security model that accomplishes your implementation objectives. You aren't constrained by the potential issues of browsers on the Internet, credit card number theft, impersonating banks, and so on. > So, my server / client are custom s/w and the target network is a private > network. Please bear with me as I put down the purpose behind this whole > thinking, once again. > 1. I will be giving my server + clients to my customers. > 2. These servers will need to have their own distinct certificates. > 3. As part of shipping my s/w (server + client) to the customers, I burn > them on a CD and ship them. > 4. If I have to generate a unique certificate for every server, myself, I > would have to burn so many different CDs. In addition to that, I will have > to maintain almost a complete CA system. > 5. This is doable, when the number of customers is small, say 5 - > 10. But I > doubt how well this would scale with the increasing number of customers. > > So, I was thinking that embedding certificate generation capability in my > installer will be good, as it can scale well. > An admin at customer C1 would have complete access to the server (h/w + > s/w). > As it is , it would be this admin who would have prepared the > cert request, > if I would be issuing signed certificate. So why not allow him to create a > certificate for himself ? What are you trying to prevent? What is the point of this entire scheme? > Now the question was, how can I embed the root CA cert + > associated private > key in the installer, such that it can not be retrieved easily? > Has anyone ever done anything like this before? Does anyone have > any better > approach to suggest? It's hard to know without knowing what the threat model is. But I would say you could simply include several 100 certificates on the CD, each encrypted with a different key. You can then give a distinct certificate number and key to each customer and they can use that to decrypt their certificate. There is no need for the certificate to contain the server's name. That would only be needed if you needed the CA (that's you) to vouch for the server's name, which you can't do. If you only need the server to vouch for its own name, it can simply send that name. If desired, you can use a two-level scheme. It works like this: 1) You include a large number of certificates and private keys on your install CD, each encrypted with a different password. 2) You issue each customer a password so they can decrypt their certificate and key. 3) Each customer then generates a certificate for their server (your installer can help them do this) and a public/private key pair for their server. They sign their new certificate with the key you included on the CD. 4) They then bundle the certificate you included on the CD, the certificate they generated in step 3, and the private key they generated in step 3 for use with the software. 5) When the client receives the two certificates, they verify: A) That the first certificate is signed by the CA key. B) That the second certificate is signed by the key verified in the first certificate. C) That the server is using the key the second certificate authenticates. This meets your requirements (I think) while still keeping the CA key secure. A client can make sure it's always talking to the same server, if it wants to, by stashing the second certificate or the key in it. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
