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 On 03/03/2015 05:57 AM, Jason Pyeron wrote: > [ 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. > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
