RE: Help adding private CA to cert7 file with NSS 3.6
> You bet. Welcome. Thank-you Nelson :) [Upgrade to cert8 snipped] That sounds like a much better option from a support point of view. I had to do some LD_ tweaking to get a system running versions of NSS/NSPR that still worked with cert7 formats and I was concerned that the normal app team may find this tricky in the future. I will raise this with the application owner. In the meantime I'll run strings on the executable just in case. > I think I know what's wrong, and it's pretty simple. But to be sure, > I want you to explain more about the clients and servers. In my defence I posted the cry for help at the end of a 15 hour work day :) I read it through twice thinking I'd included everything I needed but missed the architecture - doh! 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. In test I'm doing this with 1 client and one LDAPS server. In production it will be 1 client and many LDAPS 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. Thank you for your help so far; I've been battling this for a *long* time. Cheers, Tim 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. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
On 10/03/2008 12:43 AM, Frank Hecker: > * This CA is based in Hungary. Though it provides a lot of information > in English (including a helpful CA hierarchy diagram) unfortunately all > of its CPS documents are currently available in Hungarian only. Frank, I think we should buy some tool that helps us with translating such stuff. Apparently Google doesn't support Hungarian -> English yet, but I searched and found some useful tools on the net which can do that. Please get something that can translate the CP/CPS and publish it somewhere so we can read about it. Additionally I went to http://srv.e-szigno.hu/ and after accepting the security exception when browsing to https://srv.e-szigno.hu:/cgi-bin/editugyvedcsv.cgi I received first received ssl_error_handshake_failure_alert. I realized that I have to add their CA root, so I did that, but then I got sec_error_ocsp_malformed_request. The default settings of FF3 is to use OCSP and as you mentioned, this isn't going to work (as you mentioned already). Can you have a look into both issues above? I really would like to read the CP/CPS and a translation tool for a few bucks would help... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Assertation failure in my server test that no ciphers are present or enabled is zero
Hi,
I'm writing a test-case for the Perl bindings that basically is just
server from SSLsample. However when I try to connect to it I get an
assertation failure: PR_Assert (s=0x86d2c "numPresent > 0 ||
numEnabled == 0", file=0x86ced "ssl3con.c", ln=670). My NSS is 3.12
The code below shows what I'm doing
use Crypt::NSS config_dir => "db", cipher_suite => "US";
my $sock = Net::NSS::SSL->create_socket("tcp");
$sock->set_option(Blocking => 1);
$sock->bind("127.0.0.1", $port);
$sock->listen();
$sock->import_into_ssl_layer();
$sock->configure_as_server($private_cert, $private_key);
my $client = $sock->accept(); # <- does an automatic SSL_ImportFD
on the new fd
$client->set_option(Blocking => 1);
$client->set_option(SSL_SECURITY, SSL_OPTION_ENABLE);
$client->set_option(SSL_HANDSHAKE_AS_SERVER, SSL_OPTION_ENABLE);
$client->set_option(SSL_REQUEST_CERTIFICATE, SSL_OPTION_DISABLE);
$client->set_option(SSL_REQUIRE_CERTIFICATE, SSL_OPTION_DISABLE);
$client->set_pkcs11_pin_arg(DB_PASSWORD);
$client->reset_handshake(1);
my $buff;
while($client->read($buff) > 0) {
if ($buff eq "quit") {
$client->close();
}
$client->write(reverse $buff);
}
}
$sock->close();
The DB I'm using is created using the instructions on
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/gtstd.html#1012351
and works with the server app in SSLsample.
Any obvious things I'm doing wrong or missing?
oh, and sorry for the quite ugly API right now.. the "new" constructor
will hide the bind/listen stuff and accept take options to hide the
set_option etc calls for you.
Cheers,
Claes
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Assertation failure in my server test that no ciphers are present or enabled is zero
Claes Jakobsson wrote, On 2008-10-04 06:10: > Hi, > > I'm writing a test-case for the Perl bindings that basically is just > server from SSLsample. However when I try to connect to it I get an > assertation failure: PR_Assert (s=0x86d2c "numPresent > 0 || > numEnabled == 0", file=0x86ced "ssl3con.c", ln=670). My NSS is 3.12 That assertion means that there are NO SSL "cipher suites" that are able to be used, for one of the following reasons (in no particular order): a) No cipher suites have been enabled by (user) preference. b) No cipher suites have been enabled by application policy. c) No PKCS#11 module is available that supports all of the necessary ciphers for any one of the enabled cipher suites. Every cipher suite has two ways of being enabled/disabled by the application. They can be enabled/disabled by (user) preference, and they can be enabled/disabled by application policy. To actually be used, it must be enabled both ways. Typically, the "policy" controls are hard coded into the application, and the user preferences are user configurable. This system allows the user to express his choices and also allows the application to disallow certain cipher suites that may be disallowed by law or regulation in the country where the application is used. The defaults for the user preferences are that some cipher suites are enabled, but most are not. The set that is enabled by default is a set of quite old cipher suites. None of the new cipher suites that have been devised in the last 8 years is enabled by default in preferences. This is necessary to maintain backwards binary compatibility. The defaults for policy are that NO cipher suites are enabled until the application enables them. The c language APIs for controlling these flags allow each cipher suite to be configured separately, but there are also some functions that set all the cipher suites according to some preset configurations. One of those enables all cipher suites. I'd guess that the most likely explanation is that your code is not setting any policy flags on cipher suites, and so they're all disabled by policy. That's just a guess. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Help adding private CA to cert7 file with NSS 3.6
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 ce
