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
