NSS 3.13.1 error -8172 -- openldap

[Antonio Lobato]

Hey everyone,

I've run into an issue using nss 3.13.1 when attempting to use
ldapsearch to connect to a TLS openldap server and get the following errors:

TLS: certificate [XXXXXXXXXX] is not valid - CA cert is not valid
TLS: certificate [XXXXXXXXXX] is not valid - error -8172:Peer's
certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 21 - moznss error -8157

This only happens on 3.13.x (nss-3.13.1-7.el6_2.x86_64), and does not
happen (no errors) on 3.12.x (nss-3.12.10-2.el6_1.x86_64).

I went ahead and did two ssltap's. One is from a working version, the
other on a non working version, pasted below. Does anyone have any idea
what is going on? My current running theory is an invalid server cert
that, in some manner, was accepted in previous versions of NSS.

Thoughts?


WORKING SSLTAP:

--> [
recordLen = 121 bytes
(121 bytes of 121)
[Fri May 25 17:46:16 2012] [ssl2] ClientHelloV2 {
version = {0x03, 0x01}
cipher-specs-length = 78 (0x4e)
sid-length = 0 (0x00)
challenge-length = 32 (0x20)
cipher-suites = {
(0x000039) TLS/DHE-RSA/AES256-CBC/SHA
(0x000038) TLS/DHE-DSS/AES256-CBC/SHA
(0x000035) TLS/RSA/AES256-CBC/SHA
(0x000016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0x000013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA
(0x0700c0) SSL2/RSA/3DES192EDE-CBC/MD5
(0x000033) TLS/DHE-RSA/AES128-CBC/SHA
(0x000032) TLS/DHE-DSS/AES128-CBC/SHA
(0x00002f) TLS/RSA/AES128-CBC/SHA
(0x030080) SSL2/RSA/RC2CBC128/MD5
(0x000005) SSL3/RSA/RC4-128/SHA
(0x000004) SSL3/RSA/RC4-128/MD5
(0x010080) SSL2/RSA/RC4-128/MD5
(0x000015) SSL3/DHE-RSA/DES56-CBC/SHA
(0x000012) SSL3/DHE-DSS/DES56-CBC/SHA
(0x000009) SSL3/RSA/DES56-CBC/SHA
(0x060040) SSL2/RSA/DES56-CBC/MD5
(0x000014) SSL3/DHE-RSA/DES40-CBC/SHA
(0x000011) SSL3/DHE-DSS/DES40-CBC/SHA
(0x000008) SSL3/RSA/DES40-CBC/SHA
(0x000006) SSL3/RSA/RC2CBC40/MD5
(0x040080) SSL2/RSA/RC2CBC40/MD5
(0x000003) SSL3/RSA/RC4-40/MD5
(0x020080) SSL2/RSA/RC4-40/MD5
(0x0000ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV
}
session-id = { }
challenge = { 0x58c9 0x3b41 0xd1c0 0x7ee9 0x3363 0xb169
0xff3d 0x28b6 0x88ce 0x101c 0x8052 0xe5ed 0xe591 0xa83c 0x3088 0xec25 }
}
]
<-- [
(797 bytes of 74, with 718 left over)
SSLRecord { [Fri May 25 17:46:16 2012]
0: 16 03 01 00 4a | ....J
type = 22 (handshake)
version = { 3,1 }
length = 74 (0x4a)
handshake {
0: 02 00 00 46 | ...F
type = 2 (server_hello)
length = 70 (0x000046)
ServerHello {
server_version = {3, 1}
random = {...}
0: f1 f7 6f 1a 52 8f e8 e9 aa 4a 7c 7e e2 b9 56 90 |
...o.R....J|~..V.
10: c9 b7 ae 0e 00 17 2d 58 9d 1d 1a 00 2e a8 89 f6 |
.......-X........
session ID = {
length = 32
contents = {...}
0: 53 48 1f 18 f6 3b e9 79 d6 54 7f 73 3a 95 e9 5e | SH...;.y.s:..^
10: 4f d1 69 a3 76 75 a6 1f a0 22 2c ab d0 22 ee 9e |
O.i.vu...",.."..
}
cipher_suite = (0x0004) SSL3/RSA/RC4-128/MD5
compression method = (00) NULL
}
}
}
(797 bytes of 704, with 9 left over)
SSLRecord { [Fri May 25 17:46:16 2012]
0: 16 03 01 02 c0 | .....
type = 22 (handshake)
version = { 3,1 }
length = 704 (0x2c0)
handshake {
0: 0b 00 02 bc | ....
type = 11 (certificate)
length = 700 (0x0002bc)
CertificateChain {
chainlength = 697 (0x02b9)
Certificate {
size = 694 (0x02b6)
data = { saved in file 'cert.001' }
}
}
}
}
(797 bytes of 4)
SSLRecord { [Fri May 25 17:46:16 2012]
0: 16 03 01 00 04 | .....
type = 22 (handshake)
version = { 3,1 }
length = 4 (0x4)
handshake {
0: 0e 00 00 00 | ....
type = 14 (server_hello_done)
length = 0 (0x000000)
}
}
]
--> [
(182 bytes of 134, with 43 left over)
SSLRecord { [Fri May 25 17:46:16 2012]
0: 16 03 01 00 86 | .....
type = 22 (handshake)
version = { 3,1 }
length = 134 (0x86)
handshake {
0: 10 00 00 82 | ....
type = 16 (client_key_exchange)
length = 130 (0x000082)
ClientKeyExchange {
message = {...}
}
}
}
(182 bytes of 1, with 37 left over)
SSLRecord { [Fri May 25 17:46:16 2012]
0: 14 03 01 00 01 | .....
type = 20 (change_cipher_spec)
version = { 3,1 }
length = 1 (0x1)
0: 01 | .
}
(182 bytes of 32)
SSLRecord { [Fri May 25 17:46:16 2012]
0: 16 03 01 00 20 | ....
type = 22 (handshake)
version = { 3,1 }
length = 32 (0x20)
< encrypted >
}
]
<-- [
(43 bytes of 1, with 37 left over)
SSLRecord { [Fri May 25 17:46:16 2012]
0: 14 03 01 00 01 | .....
type = 20 (change_cipher_spec)
version = { 3,1 }
length = 1 (0x1)
0: 01 | .
}
(43 bytes of 32)
SSLRecord { [Fri May 25 17:46:16 2012]
0: 16 03 01 00 20 | ....
type = 22 (handshake)
version = { 3,1 }
length = 32 (0x20)
< encrypted >
}
]
....
<snip>



******************NON-WORKING SSLTAP***********************


--> [
(70 bytes of 65)
SSLRecord { [Fri May 25 17:42:35 2012]
0: 16 03 01 00 41 | ....A
type = 22 (handshake)
version = { 3,1 }
length = 65 (0x41)
handshake {
0: 01 00 00 3d | ...=
type = 1 (client_hello)
length = 61 (0x00003d)
ClientHelloV3 {
client_version = {3, 1}
random = {...}
0: 4f bf fc ca f7 be b5 e8 f4 93 3c 8e a4 fc ea ac |
O.........<.....
10: 40 5c fd f4 8c 20 ef f1 6b 36 1e a5 af 5a 42 c0 | @\...
...k6...ZB.
session ID = {
length = 0
contents = {...}
}
cipher_suites[11] = {
(0x00ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV
(0x0035) TLS/RSA/AES256-CBC/SHA
(0x0004) SSL3/RSA/RC4-128/MD5
(0x0005) SSL3/RSA/RC4-128/SHA
(0x002f) TLS/RSA/AES128-CBC/SHA
(0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
(0x0009) SSL3/RSA/DES56-CBC/SHA
(0x0064) TLS/RSA-EXPORT1024/RC4-56/SHA
(0x0062) TLS/RSA-EXPORT1024/DES56-CBC/SHA
(0x0003) SSL3/RSA/RC4-40/MD5
(0x0006) SSL3/RSA/RC2CBC40/MD5
}
compression[1] = {
(00) NULL
}
}
}
}
]
<-- [
(797 bytes of 74, with 718 left over)
SSLRecord { [Fri May 25 17:42:35 2012]
0: 16 03 01 00 4a | ....J
type = 22 (handshake)
version = { 3,1 }
length = 74 (0x4a)
handshake {
0: 02 00 00 46 | ...F
type = 2 (server_hello)
length = 70 (0x000046)
ServerHello {
server_version = {3, 1}
random = {...}
0: 2f b8 ce b2 dd f3 95 c3 c7 cc 97 56 18 8d 0c f7 |
/..........V....
10: 63 2f f4 a0 33 ed dc be e9 1f e2 30 9b 31 cb 1e |
c/..3......0.1..
session ID = {
length = 32
contents = {...}
0: 53 48 1f 18 f6 3b ef 7b d6 54 7f 73 3a 95 ef 5c | SH...;.{.s:..\
10: 4f d1 69 a3 76 75 a6 1f a0 22 2c ab d0 22 ef fd |
O.i.vu...",.."..
}
cipher_suite = (0x0004) SSL3/RSA/RC4-128/MD5
compression method = (00) NULL
}
}
}
(797 bytes of 704, with 9 left over)
SSLRecord { [Fri May 25 17:42:35 2012]
0: 16 03 01 02 c0 | .....
type = 22 (handshake)
version = { 3,1 }
length = 704 (0x2c0)
handshake {
0: 0b 00 02 bc | ....
type = 11 (certificate)
length = 700 (0x0002bc)
CertificateChain {
chainlength = 697 (0x02b9)
Certificate {
size = 694 (0x02b6)
data = { saved in file 'cert.001' }
}
}
}
}
(797 bytes of 4)
SSLRecord { [Fri May 25 17:42:35 2012]
0: 16 03 01 00 04 | .....
type = 22 (handshake)
version = { 3,1 }
length = 4 (0x4)
handshake {
0: 0e 00 00 00 | ....
type = 14 (server_hello_done)
length = 0 (0x000000)
}
}
]
--> [
(7 bytes of 2)
SSLRecord { [Fri May 25 17:42:35 2012]
0: 15 03 01 00 02 | .....
type = 21 (alert)
version = { 3,1 }
length = 2 (0x2)
fatal: bad_certificate
0: 02 2a | .*
}
]
ssltap: Error -5961: TCP connection reset by peer: Client socket read
failed.

[Robert Relyea]

On 05/25/2012 02:52 PM, Antonio Lobato wrote:
> Hey everyone,
>
> I've run into an issue using nss 3.13.1 when attempting to use
> ldapsearch to connect to a TLS openldap server and get the following
> errors:
>
> TLS: certificate [XXXXXXXXXX] is not valid - CA cert is not valid
> TLS: certificate [XXXXXXXXXX] is not valid - error -8172:Peer's
> certificate issuer has been marked as not trusted by the user..
> TLS: error: connect - force handshake failure: errno 21 - moznss error
> -8157

Just looking at the error message, I would normally guess that the trust
chain is no longer trusted. That is you are chaining to a CA that we've
taken out of the trust list (probably because the CA was compromised).

Since this is an ldap server, I think it's only 20% likely (people do
get globally trusted certs for ldap servers, but it's more common they
they use a cert in their own infrastructure.

The next most likely cause would be that one of the certs in your cert
chain matches a compromised certificate in the builtin trust store
(matches by issuer and serial number).

Finally, check your nss database. If you have a intermediate cert with
the 'peer' bit on 'p', that actually marks the intermediate as
untrusted. In NSS 3.12 the 'p==untrusted' only applied to leaf certs, it
was ignored otherwise. In NSS 3.13 it also applies to intermediate
certs. If it's on (and no other trust bits are on), then the certificate
is explictly distrusted. My guess is this is your problem.

bob

[Antonio Lobato]

On 5/29/2012 1:28 PM, Robert Relyea wrote:
> Just looking at the error message, I would normally guess that the trust
> chain is no longer trusted. That is you are chaining to a CA that we've
> taken out of the trust list (probably because the CA was compromised).
>
> Since this is an ldap server, I think it's only 20% likely (people do
> get globally trusted certs for ldap servers, but it's more common they
> they use a cert in their own infrastructure.
>

You're right -- these are self-signed certs that a client is using.

> The next most likely cause would be that one of the certs in your cert
> chain matches a compromised certificate in the builtin trust store
> (matches by issuer and serial number).
>

This shouldn't apply as these are self-signed certs.

> Finally, check your nss database. If you have a intermediate cert with
> the 'peer' bit on 'p', that actually marks the intermediate as
> untrusted. In NSS 3.12 the 'p==untrusted' only applied to leaf certs, it
> was ignored otherwise. In NSS 3.13 it also applies to intermediate
> certs. If it's on (and no other trust bits are on), then the certificate
> is explictly distrusted. My guess is this is your problem.

The nssdb is empty.

Any other ideas?

[Antonio Lobato]

Oh, just checked the serial number of the cert: 00

That would do it. Thanks all.