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
