On Oct 2, 3:53 pm, "Matthews, Tim R" <[EMAIL PROTECTED]> wrote: > 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:
Any luck resolving this? I'm running into the exact same issue. Small test environment using server 2k3 as CA and RHEL5/apache/mod_nss _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto