Hi All. I hope this is an acceptable question for this list; I've searched google and the archives and not found an answer.
We use Remedy ARS (helpdesk ticketing system) and are migrating to Microsoft ADAM (LDAP) using TLS for encryption. I am responsible for getting Remedy to talk LDAPS which is secured using an internal CA :( I have it working in dev but the solution seems a cludge to me. First some details: NSS 3.6 & NSPR 4.3 on Linux x32. Using this version as Remedy only understands cert7 databases. Remedy is running on Win32. My current working system has both the CA *and* client certificate included in cert7. I have established that only the client cert is needed - the system works irrespective of whether or not CA cert is included. Clearly this is wrong and suboptimal - my final LDAPS solution is a load-balanced set of servers; I don't want to include all client certs in the cert7. I should just be able to add a trusted CA and have it work as one would expect. I added the client cert with the command line: # certutil -d . -A -t "P" -n client -i clientcert.pem # certutil -d . -L -n client shows: [SNIP] Certificate Trust Flags: SSL Flags: Valid Peer Trusted I added the CA cert with the command line: # certutil -d . -A -t "Tc" -n centralct -i centralct.pem # certutil -d . -L -n centralct shows: [SNIP] Certificate Trust Flags: SSL Flags: Valid CA Trusted CA Trusted Client CA I've also tried -t "PpCcTu" :-) just in case. With the client cert - success. With just the CA cert - nada! The certutil -L all show the proper information wrt certificate data so I'm happy they're being imported OK. They've not expired and are valid. The CA cert works with both Java and CryptoAPI code. I have tried certutil -d . -V -n centralct -u C and get: certutil: certificate is invalid: Certificate key usage inadequate for attempted operation. I am wondering whether I've caused this with improper -t settings during import. Certainly Java and CryptoAPI seem happy for the cert to be used as a trusted CA. I setup wireshark to sniff the TLS connection and get Alert (Fatal: Unknown CA) when only the CA cert is present. *So*, question time. Can anybody show me what I'm doing wrong? Is there a restriction on the key usage that only NSS is aware of? The CA directly issued the client cert - no intermediate levels that I've forgotten to add. I can make the certs available if required. Full dump of the CA cert below. Thanks, Tim Certificate: Data: Version: 3 (0x2) Serial Number: 1193748693 (0x472728d5) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: OU=CentralCT, OU=PKI, OU=Services, O=XXXX, C=GB Validity: Not Before: Tue Oct 30 12:21:32 2007 Not After: Sat Oct 30 12:51:32 2027 Subject: OU=CentralCT, OU=PKI, OU=Services, O=XXXX, C=GB Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: 00:dd:c0:95:7d:28:f3:fd:83:88:a2:83:38:b9:31: a7:a6:39:b2:92:fb:61:bd:6e:4d:d7:25:0a:32:72: 39:60:c9:48:31:53:f5:f4:1c:bb:96:f6:6a:e5:ee: a9:b5:7e:f8:58:10:8c:21:73:32:51:4e:ce:2f:07: 2c:a7:53:ef:bc:a1:42:80:db:b0:3d:3b:2d:7d:c6: 2a:0a:1c:c0:d3:9a:63:b5:03:78:da:2b:3c:42:ef: 67:ef:d2:d9:65:45:84:65:0c:57:cf:05:1d:91:6f: 66:ec:cf:1e:9f:81:2a:8c:d1:af:ad:bf:39:80:bc: 7c:fd:0d:4b:70:78:4d:6d:2b Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Type Data: <SSL CA,S/MIME CA,ObjectSigning CA> Name: CRL Distribution Points Data: Sequence { Sequence { Option 0 a0:68:a4:66:30:64:31:0b:30:09:06:03:55:04: 06:13:02:47:42:31:11:30:0f:06:03:55:04:0a: 13:08:55:6e:69:6c:65:76:65:72:31:11:30:0f: 06:03:55:04:0b:13:08:53:65:72:76:69:63:65: 73:31:0c:30:0a:06:03:55:04:0b:13:03:50:4b: 49:31:12:30:10:06:03:55:04:0b:13:09:43:65: 6e:74:72:61:6c:43:54:31:0d:30:0b:06:03:55: 04:03:13:04:43:52:4c:31 } } Name: Certificate Private Key Usage Period Data: Sequence { Option 0 32:30:30:37:31:30:33:30:31:32:32:31:33:32:5a 20071030122132Z Option 1 32:30:32:37:31:30:33:30:31:32:35:31:33:32:5a 20271030125132Z } Name: Certificate Key Usage Data: 03:02:01:06 Name: Certificate Authority Key Identifier Data: Sequence { Option 0 a9:6c:23:bc:f7:af:37:a0:1b:8b:a4:c5:09:fe:75: f3:24:ca:ed:7d } Name: Certificate Subject Key ID Data: 04:14:a9:6c:23:bc:f7:af:37:a0:1b:8b:a4:c5:09:fe: 75:f3:24:ca:ed:7d Name: Certificate Basic Constraints Data: Is a CA with a maximum path length of -2. Name: 2a:86:48:86:f6:7d:07:41:00 Data: Sequence { 1b:08:56:37:2e:31:3a:34:2e:30 03:02:04:90 } Fingerprint (MD5): D4:1D:8C:D9:8F:00:B2:04:E9:80:09:98:EC:F8:42:7E Fingerprint (SHA1): DA:39:A3:EE:5E:6B:4B:0D:32:55:BF:EF:95:60:18:90:AF:D8:07:09 Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 30:49:4c:18:2c:97:0e:d0:a6:50:2f:be:bd:a7:8b:0d:82:6a: 3c:c6:51:ec:83:ba:2a:98:20:83:fd:3c:b9:04:81:f3:88:2c: bf:2d:30:b9:4d:bd:70:84:79:ea:10:9f:be:7b:8d:b1:86:ab: 6e:d7:e1:b1:fa:bb:eb:d6:a5:33:19:89:9a:03:70:03:58:a1: 78:92:ed:87:64:dc:1f:9b:fd:13:90:2f:ee:9a:a5:99:a7:69: b4:59:a5:67:33:cf:1b:47:fd:2f:b5:a7:2d:04:39:f4:dd:20: 98:64:75:76:af:9f:de:d4:53:57:1e:9a:55:7b:96:76:45:2c: 6c:2f Certificate Trust Flags: SSL Flags: Valid CA Trusted CA Trusted Client CA Email Flags: Object Signing Flags:
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto