2.26 KB, application/octet-stream
2.81 KB, application/octet-stream
624 bytes, application/x-x509-ca-cert
1) Go to https://cpolwapp.belvoir.army.mil/public/vabSelfNom/index.jsp 2) You will get the "This connection is untrusted message" 3) Click "I understand the risks" 4) Click "Add exception" 5) Wait for the certificate to load or click the "Get certificate" button 6) Make sure the "Permanently store this exception" box is checked 7) Click the "Confirm security exception" button The page will now load. Close Firefox or wait a day or two and come back to this site and you have to go through all the steps again. The exception is not permanently stored.
As an aside, I would think that anyone having business with the DOD would think "I shouldn't need to add an exception for genuine DOD certs. The DOD's certs ought to work!" and would look into WHY its happening, rather than merely trying to bypass the security measures with an "exception". It's a huge risk for the DOD (and those who are part of the DOD and its contractors) if its relying parties are routinely using "exceptions" to visit DOD sites! Have you installed the DOD root CA certificates?
DoD Root CA certs and intermediate CA certs are available in PEM form at http://www.hropensacola.navy.mil/modern/certdb.txt
The primary complaint of this bug is that the "exception" doesn't seem to be remembered. That's a PSM problem, not NSS. But investigation of this problem reveals that the OCSP responder for the CA that issued this server certs sends back different OCSP repsonses for the same server cert at different times (it seems to be random). Looking at the responses in a debugger, I can see that some of the responses are signed with a self-signed OCSP responder cert, and of course, a self-signed responder cert does not meet the requirements of the OCSP RFC for being a qualified responder. I wish I could capture all the evidence of those problems, so that it could be given to the DoD CA operator, but presently NSS has no tools that are up to that task. :( That's an NSS problem, which is not covered by NSS bug 418644.
Component: CA Certificates → Security: PSM
Product: NSS → Core
QA Contact: root-certs → psm
Created attachment 368475 [details] The shorter one of two common DER OCSP responses. I'm going to continue to document in this bug the OCSP repsonses obtained for this server. I am attaching here one of the two common responses received when querying about the server cert at the URL named above. Both responses are very similar, having been issued 1 day apart. Each one covers 20 serial numbers. However, the first one identifies the responder by name, and does NOT include a copy of the responder's cert. That response says, in part, when decoded: Response Data: Version: DEFAULT Responder ID (byName): Name: "CN="dod ocsp ss ",OU="PKI, OU=DoD",O=U.S. Government,C=us" Produced At: Thu Mar 19 16:48:00 2009 Here is one such response.
Created attachment 368476 [details] The longer one of the two common DER OCSP responses. This is the other of the two responses I commonly see. (I was seeing a third, but no longer.) It is similar to the first, but it identified the signer by a hash of the responder's public key, and includes a cert bearing that public key. Response Data: Version: DEFAULT Responder ID (byKey): Key Hash: 29:0f:a7:e6:10:53:e8:76:3c:60:55:e6:33:3a:99:ef: b8:3e:ca:cb Produced At: Fri Mar 20 00:37:09 2009 Here is a dump of the cert in that response: Certificate (1): Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN="dod ocsp ss ",OU="PKI, OU=DoD",O=U.S. Govern ment,C=us" Validity: Not Before: Thu Jan 10 16:18:38 2008 Not After : Mon Feb 28 16:18:38 2011 Subject: "CN="dod ocsp ss ",OU="PKI, OU=DoD",O=U.S. Gover nment,C=us" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: e0:56:0c:2d:74:2e:9d:af:d0:ee:1d:10:a4:e8:59: dd:a3:92:25:10:62:9f:85:08:ec:bb:50:a0:56:33: b9:d5:66:bd:8d:66:b6:55:10:de:04:98:01:fa:ae: ce:85:3d:af:19:c7:7d:c5:39:dc:35:0f:42:df:6d: d1:2c:a9:06:68:b5:37:8a:18:ad:f6:df:30:f1:45: 91:11:96:85:44:c3:26:e3:0a:e3:df:97:08:c8:57: 16:fb:6e:ac:5a:c6:5a:eb:f1:cd:72:6b:3f:39:d5: f7:75:bc:7e:06:d2:82:65:43:12:ac:06:d5:11:ee: 61:0f:d2:d3:80:80:ab:df Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Basic Constraints Data: Is not a CA. Name: Extended Key Usage Critical: True TLS Web Server Authentication Certificate OCSP Responder Certificate Name: Certificate Subject Key ID Data: 29:0f:a7:e6:10:53:e8:76:3c:60:55:e6:33:3a:99:ef: b8:3e:ca:cb Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 6d:bc:c5:ee:93:6e:45:e7:ae:b7:92:34:c4:01:94:a6: ee:c5:8c:a4:ef:a6:39:68:3f:c9:74:5a:e0:37:1b:61: 86:36:6d:c5:e4:8a:3a:95:bd:d1:e7:0c:e1:e3:1f:a3: 7c:33:c5:24:70:3f:db:e8:1a:82:39:a5:7c:fc:06:98: b1:20:89:81:3d:db:95:fb:2a:a9:c0:aa:b3:0d:4a:e3: e8:0f:3f:a8:7f:75:d8:41:6e:a8:70:58:48:7b:66:70: d2:fb:70:b1:55:45:e0:f8:dc:a8:d4:11:2a:e2:e8:88: 6c:21:57:c5:f1:36:4d:be:06:3a:65:8a:63:05:1d:d6 As you can see, it identifies itself as self signed (ss).
Created attachment 368478 [details] The self-signed OCSP responder's DER cert Here is the self-signed DER OCSP responder's cert, extracted from the above OCSP response using dd. I'm going to test it to see if it works as a "default" or "trusted" (user delegated) OCSP responder cert.
Yes, when that self-signed OCSP responder cert is imported, and is used as a user-delegated ("default") OCSP responder, the OCSP response is deemed to be valid. Since the designation of a "default" OCSP responder affects ALL OCSP checks done for the browser profile, the implication of this design is that users of the SSL server certs issued by that issuer must be used by browsers with profiles specifically configured to use that OCSP responder. One imagines that a browser profile configured in that way would basically be useful ONLY for accessing DOD SSL sites.
Maybe someone can "evangelize" the operator of that CA to issue and use an OCSP responder cert that is issued by the CA that issues the certs whose status it reports. That would obviate any user-delegated "default" responder configuration, and would obviate special profiles for DOD (although, maybe they WANT their users to use special profiles).
Not blocking, suggest INVALID, WFM or --> Tech Evangelism.
Flags: blocking1.9.1? → blocking1.9.1-
Is (a) NSS rejecting the cert despite having stored an exception (related to the OCSP trouble)? Or is (b) there indeed a bug in PSM and we fail to store an exception?
reassign bug owner. mass-update-kaie-20120918
Assignee: kaie → nobody
When TB opens up, I get all these Certificate warnings, I can tick "[ ] Permanently store this exception" but they come back again. In Security/View Certificates/Add Exception, I can enter the Server Location and Get Certificate, but "[ ] Permanently store this exception" remains greyed out. This is on Linux/Kubuntu. Could it be a rights issue, some file somewhere needs to be chmod'ed?
I can't connect to the original site. Frank - it would be best if you filed a new bug on the behavior you're seeing.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
Porblem went away. Resolved, thanks.
You need to log in before you can comment on or make changes to this bug.