Client auth only sending client certificate, not sending intermediate CA certificates

[Jason Pyeron]

[ moved to this list, per https://groups.google.com/d/msg/mozilla.support.firefox/Ba4MzFQxqP8/DbmDUCbJqxkJ ]

I was trying to figure why some of the uses were not having a chain sent to the server for their client certificate, and it turns out Firefox does not send (by default?) the chaining certs.

After reviewing https://wiki.mozilla.org/PSM:CertPrompt , it seems Firefox will 'validate' that the client cert can be chained, before allowing the user to select it.

Here is a snippet of a diff of the TLS Certificate, Client Key Exchange, and Certificate Verify packets of IE and FF. Full packets upon request.

$ diff -u firefox-client-TLS.txt internetExplorer-client-TLS.txt | less
--- firefox-client-TLS.txt 2015-03-02 16:13:05.918866100 -0500
+++ internetExplorer-client-TLS.txt 2015-03-02 16:05:01.332097100 -0500
@@ -1,18 +1,18 @@
No. Time Source Destination Port Protocol Length Info
- 3071 2015-03-02 16:09:59 192.168.4.12 67.90.184.200 443 TLSv1.2 565 Certificate, Client Key Exchange, Certificate Verify
+ 836 2015-03-02 16:01:42 192.168.4.12 67.90.184.200 443 TLSv1 634 Certificate, Client Key Exchange, Certificate Verify

-Frame 3071: 565 bytes on wire (4520 bits), 565 bytes captured (4520 bits) on interface 0
+Frame 836: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits) on interface 0
Interface id: 0 (\Device\NPF_{62C9E26B-6677-4CCF-82EC-CD288CDC77D1})
Encapsulation type: Ethernet (1)
- Arrival Time: Mar 2, 2015 16:09:59.702193000 Eastern Standard Time
+ Arrival Time: Mar 2, 2015 16:01:42.634780000 Eastern Standard Time
[Time shift for this packet: 0.000000000 seconds]
- Epoch Time: 1425330599.702193000 seconds
- [Time delta from previous captured frame: 0.000054000 seconds]
- [Time delta from previous displayed frame: 0.000054000 seconds]
- [Time since reference or first frame: 691.721761000 seconds]
- Frame Number: 3071
- Frame Length: 565 bytes (4520 bits)
- Capture Length: 565 bytes (4520 bits)
+ Epoch Time: 1425330102.634780000 seconds
+ [Time delta from previous captured frame: 0.000022000 seconds]
+ [Time delta from previous displayed frame: 0.000022000 seconds]
+ [Time since reference or first frame: 194.654348000 seconds]
+ Frame Number: 836
+ Frame Length: 634 bytes (5072 bits)
+ Capture Length: 634 bytes (5072 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame [truncated]: eth:ethertype:ip:tcp:ssl:pkcs-1:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:pkcs-1:x509ce:x509ce:x509ce:x509ce:x509ce:pkix1implicit:x509ce:x509sat:x509ce:x509sat:x]
<snip/>
Secure Sockets Layer
- TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages
+ TLSv1 Record Layer: Handshake Protocol: Multiple Handshake Messages
Content Type: Handshake (22)
- Version: TLS 1.2 (0x0303)
- Length: 1691
+ Version: TLS 1.0 (0x0301)
+ Length: 3052
Handshake Protocol: Certificate
Handshake Type: Certificate (11)
- Length: 1289
- Certificates Length: 1286
- Certificates (1286 bytes)
+ Length: 2652
+ Certificates Length: 2649
+ Certificates (2649 bytes)
Certificate Length: 1283
Certificate (id-at-commonName=PYERON.JASON.J.1291147719,id-at-organizationalUnitName=CONTRACTOR,id-at-organizationalUnitName=PKI,id-at-organizationalUnitName=DoD,id-at-organizationName=U.S. Government,id-at-countryName=US)
signedCertificate
@@ -250,69 +251,218 @@
Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)
Padding: 0
encrypted: 94d7842ef98ac9f4a525eef75e01a2d6fc739ca4310504db...
+ Certificate Length: 1360
+ Certificate (id-at-commonName=DOD CA-32,id-at-organizationalUnitName=PKI,id-at-organizationalUnitName=DoD,id-at-organizationName=U.S. Government,id-at-countryName=US)
+ signedCertificate
+ version: v3 (2)
+ serialNumber: 929
+ signature (shaWithRSAEncryption)
+ Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)
+ issuer: rdnSequence (0)
+ rdnSequence: 5 items (id-at-commonName=DoD Root CA 2,id-at-organizationalUnitName=PKI,id-at-organizationalUnitName=DoD,id-at-organizationName=U.S. Government,id-at-countryName=US)


Note the inclusion of the DOD CA-32 certificate on IE.

This is from FF 36.0.

If this is a bug, I will file a ticket on Bugzilla, but I am assuming it is a configuration issue, likely PEBKAC.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

[David Keeler]

If this was working before and stopped working, then it sounds like a
bug. I would file one against NSS:
https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=Libraries
(as far as I can tell, Firefox registers a callback that NSS calls to
get a certificate and private key; NSS determines what intermediates to
send along with the certificate).

One thing to try would be to not mark the DOD CA-32 as a trust anchor in
the certificate manager if possible (I have a hunch that if it is a
trust anchor, NSS won't send it because it assumes that the peer has the
same anchors as the client, so it would be wasted bytes on the wire to
do so).

Hope this helps,
David

[Jason Pyeron]

> -----Original Message-----
> From: David Keeler
> Sent: Tuesday, March 03, 2015 14:18
>
> If this was working before and stopped working, then it sounds like a
> bug. I would file one against NSS:
> https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&compone
nt=Libraries
> (as far as I can tell, Firefox registers a callback that NSS calls to
> get a certificate and private key; NSS determines what
> intermediates to
> send along with the certificate).

That is expected.

>
> One thing to try would be to not mark the DOD CA-32 as a
> trust anchor in

PEBKAC: CA32 was not in Firefox's store. Spoiled by auto enrolement for all the other stores.

> the certificate manager if possible (I have a hunch that if it is a
> trust anchor, NSS won't send it because it assumes that the

That would be a bug.

> peer has the
> same anchors as the client, so it would be wasted bytes on the wire to
> do so).

It can only assume what the server knows, by the server sending the list of what it knows, it is the client's responsibiltiy to send a verifiable chain.

> t:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:pkcs