Hi. Apologies for the poor use of client/server terminology. I've spent so long talking about the non-SSL part of this that I didn't do the context switch into SSL terms :)
You are right in that no client certificates are in use. In testing I just have the CA cert and the LDAPS server cert. > Only 1 client, but many servers? Yes. There will only be one Remedy instance but the LDAPS system is going to be back-ended by multiple LDAPS servers. Remedy is just one of a few hundred LDAP apps I've migrated. It's also the only one which is causing major problems :-( > > 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? I've asked for the source of this. I believe it's a .doc supplied with the Rem package. Tracking down a suitable version of Netscape that would work took some time... We are using Remedy 6.3 and latest is 7.1, so not *that* old. [Excellent description of SSL client/server snipped] Our *production* load-balancing is based on multiple LDAPS servers and a Foundry load balancer. Application access to LDAPS is via a series of CNAMES which point to Foundry virtual IPs. These CNAMES indicate a geographical preference to the Foundry. The connections are then redirected by the Foundry to the appropriate LDAPS server. I'm using subjectAlternateNames to cover the real hostname and CNAMEs for each LDAPS server. This is tested and working. In *test* I've got an LDAPS server with an SSL server certificate issued to its FQDN and inbound connections using that FQDN. This is also tested and working. > Now, about that diagnostic step, please try the following series of certutil > commands using the same cert DB that you used in your original trmatthe@:~/working$ certutil -d . -M -t ",," -n client trmatthe@:~/working$ certutil -d . -M -t "C,," -n centralCT trmatthe@:~/working$ certutil -d . -V -e -u V -n client certutil: certificate is valid Erk! So clearly from an SSL perspective the CA cert is valid and the trust flags are OK. Just to be sure I removed the centralCT CA cert and verifying the 'client' cert for SSL server purposes failed with: certutil: certificate is invalid: Peer's Certificate issuer is not recognized. Just to be sure, I tried a connection with a cert7 containing the CA cert (centralCT) with flags C,, This failed with an Alert: Unknown CA from my sniffer. Sooo, it's not looking (to me) to be a trust issue. It's as if Remedy is unwilling to use trust hierarchies and is expecting individual SSL server certs. Have I missed something or is this looking like a Remedy SSL bug? Thanks once again for all your help with this. I'd been going slowly mad! Cheers, Tim _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
