Matthews, Tim R wrote, On 2008-10-04 03:34: > Remedy is the client and the load balanced Adams are the servers. The > client cert is indeed for the adam server and references it by name.
Thanks for confirming what I suspected. I'll write more about it below. > In test I'm doing this with 1 client and one LDAPS server. In production > it will be 1 client and many LDAPS servers. Only 1 client, but many servers? > The servers will all have SSL certs issued by the same CA. Because the > number of servers *will* increase over time I need to do this properly by > trusting the CA, rather than trusting a load of server certs. Well, of course, if you only have one client, then it's not a big administrative burden to put each server's cert into it. But if you have tens or hundreds of clients, then of course using a CA is a big win. Your plan of using a CA sounds like the right plan to me. > Ps As an aside the Remedy docs suggesting installing Netscape browser, > connecting to an SSL website secured by the intended certificate, adding > it through the dialog box and then copying the cert7/key3 pair into the > Remedy folder. This must be some OLD documentation. Is it publicly available, as a web page, perhaps? Below, I will propose another diagnostic step for you to do to understand the problem with your certs, but first I will give some background explanation, and a discussion of the load balancing issue. The thing that you're calling a "client certificate" is actually known as a SERVER certificate in SSL specifications. It identifies the server, and with it, the client to be sure that the system at the other end of the connection really is the desired server system. (I wonder, does the Remedy documentation call it a client certificate?) There are also certificates that exist to identify the client to the server. They bear the client's (user's) name, not the server's. They are known as client certificates. With one of them, the server can be sure that the program at the other end of the connection really belongs to a particular certain client (user). I'm pretty sure that you don't have those, and are not using those. I think one of the replies you previously received was describing the things necessary to make a client certificate work, but since you are not using a client certificate, but rather a server certificate, that advice does not apply to your situation. Regarding load balancing: There are a number of different ways to achieve load balancing. Most of them try to make a bunch of servers appear to the client to be the same system, or more precisely, to have the same DNS name. Depending on the particular method used to do that load balancing, those different servers may appear to the client to all have the same IP address, or they may appear to have different IP addresses. But either way, they all appear to have the same DNS name, e.g. all appearing to be www.foo.com. The client attempts to connect to (e.g.) www.foo.com, and it may end up talking to any one of the servers, but as far as the client knows, it is talking to www.foo.com. In a configuration where all the servers appear to the client to all have the same DNS name AND the same IP address, the servers are configured to all have the same identical certificate and the same private key. In the case where they have the same DNS name but different IP addresses, they may all share a single certificate and private key, OR they may have separate certificates with separate public and private keys, but all of those certificates must bear that same exact single DNS name by which they appear to the client (e.g. www.foo.com in the example). If the servers all appear to the client as a single DNS name (say, www.foo.com) but they have certificates that do NOT bear that common name, so that the client will attempt to connect to www.foo.com, but gets a certificate from the server that identifies the server by another name, such as (say) server1.foo.com, and does not also bear the name www.foo.com, the client must REJECT such a certificate as having the wrong name. If the client does not do that, the client will be vulnerable to the pernicious "Man In The Middle" (MITM) attack. Server certificates may have multiple DNS names in them, but they MUST have a name that matches the name by which the client attempted to connect to the server. It might be a good idea to test your Remedy client, to see if it accepts or rejects a server certificate with the wrong DNS server name. Now, about that diagnostic step, please try the following series of certutil commands using the same cert DB that you used in your original message on this subject. These steps will start by setting the "trust" flags on the cert to be as they should be for a normal trusted-CA setup, then they will test the server cert as a server cert, and will tell us what (if anything) it doesn't like about that server cert. For now, we'll ignore the fact that the name of your server cert is "client". :) certutil –d . –M –t “,,” –n client certutil -d . -M -t "C,," -n centralct certutil -d . -V -e -u V -n client After doing the first two commands, the trust flags on your certificates will be just as they should be in a normal SSL client. The output of the third command will tell you exactly what, if anything, NSS dislikes about that server cert (named client). Once you know what that problem is, we can determine how to "remedy" it. :) _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
