4 ms·

> I just checked the certificate of networthiness page and they don't have a valid SSL certificate. I recall that being the case years ago too. I wonder if it's

> I just checked the certificate of networthiness page and they don't have a valid SSL certificate. I recall that being the case years ago too. I wonder if it's been that way for the last 7 years? That's a cute little terrarium of the whole biome I remember. That's not quite true. Internal use sites don't have a valid cart issued by a "default" external vendor. Public sites use existing CAs that are in use by the public. E.g., the Marines public facing site[0] is signed by DigiCert. If you go to a site that's public facing but for internal use like MoL[1], you'll see that the cert is issue by an internal DoD CA. This is intentional. The DoD has an internal CA already set up. These internal use sites are a gateway to sensitive information, so the DoD doesn't want to rely on an external CA for HTTPS. What I never understood was why these internal CAs weren't marked as trusted on the internal machines. That would avoid the browser warnings when accessing one of these site from DoD hardware, and it would (in theory) force the user to double check when accessing the site from an external device. [0]: https://www.marines.com/ https://www.marines.com/ [1]: https://mol.tfs.usmc.mil/mol https://mol.tfs.usmc.mil/mol

rkeene2 8y ago
They are trusted by internal machines -- since a lot of internal authentication relies on these certificates. The DOD long ago moved away from password-based authentication mechanisms to certificate-based authentication (GSC-IS initially (CAC), now NIST SP 800-73 (PIV; CAC II)) and so the system will have the correct certificates or the user generally won't be able to login. What I find as the most common error is that users setup an alternate browser (such as Firefox) that does not use the system certificate store and then lack the system's local certificate authorities. Additionally, DOD PKI is now cross-signed with Federal PKI (FPKI), so it's larger than the DOD now and other agencies also use the same smartcards (PIV).
- noxToken 8y ago
  This bit is curious. I was issued a CAC while I was in, and as you said, it eliminated the need for passwords. But the internal sites (no matter if it was a laptop from the comm section, a hardwired desktop in a unit's building, or a desktop in a base facility) always failed the check for the certificate store. I always got the security warning (or insecure message) regardless of browser.
  - MrLeap 8y ago
    That's my recollection as well.
  - rkeene2 8y ago
    What happens in some cases is that new intermediate CAs are introduced and older client's certificate stores are not updated. In this case it is a TLS server error as the TLS server should be sending you all the intermediate certs to chain you to "DoD Root CA 2" (the root of DOD PKI -- which is also where smartcards are issued from, via different intermediate certificate authorities, prior to FPKI).
  - breatheoften 8y ago
    Slightly off-topic - but its semi-relevant here as this conversation involves the requirement of knowing (1) the state of the system security store (2) the state of an application's security store ... and maybe in some cases (3) understanding how an application modifies any trusted stores. It seems we end up with a lot of possibilities for the states of these stores to diverge from our expectations ... I've been wondering how to verify a sane state for all these stores for even a use as simple as my own personally owned/controlled notebook ... I'd really like a way to audit the system trust store in macOS and enforce that is in alignment with whatever the current 'blessed by apple' certificate trust relationships are and that any trust relationships I ever manually added by mistake/debugging have been removed... I asked a question about this on stackoverflow but no one has responded ... https://stackoverflow.com/questions/52527886/revert-all-certificate-trust-relationships-to-system-default-on-macos-10-mojave https://stackoverflow.com/questions/52527886/revert-all-cert...
    - rkeene2 8y ago
      I don't know the answer to your StackOverflow question as I don't use macOS/Mac OS X. What I ended up doing to help this process along is including the relevant certificates inside my DOD Smartcard PKCS#11 module as certificate objects (with, of course, no corresponding private key objects). For applications that use PKCS#11 (such as Firefox, via NSS), this means that when the module is loaded the appropriate certificates are also made available automatically. This was also (I believe) supported by the "TokenD" driver used to support macOS/Mac OS X so that enabling this driver made those certificates available and provided by the token, so no modifications to the local macOS system trust store were needed.
MrLeap 8y ago
Ah thanks for educating me. My island at TRADOC didn't have anyone who knew those details. :P

rkeene2 8y ago

They are trusted by internal machines -- since a lot of internal authentication relies on these certificates. The DOD long ago moved away from password-based authentication mechanisms to certificate-based authentication (GSC-IS initially (CAC), now NIST SP 800-73 (PIV; CAC II)) and so the system will have the correct certificates or the user generally won't be able to login. What I find as the most common error is that users setup an alternate browser (such as Firefox) that does not use the system certificate store and then lack the system's local certificate authorities. Additionally, DOD PKI is now cross-signed with Federal PKI (FPKI), so it's larger than the DOD now and other agencies also use the same smartcards (PIV).

noxToken 8y ago
This bit is curious. I was issued a CAC while I was in, and as you said, it eliminated the need for passwords. But the internal sites (no matter if it was a laptop from the comm section, a hardwired desktop in a unit's building, or a desktop in a base facility) always failed the check for the certificate store. I always got the security warning (or insecure message) regardless of browser.
- MrLeap 8y ago
  That's my recollection as well.
- rkeene2 8y ago
  What happens in some cases is that new intermediate CAs are introduced and older client's certificate stores are not updated. In this case it is a TLS server error as the TLS server should be sending you all the intermediate certs to chain you to "DoD Root CA 2" (the root of DOD PKI -- which is also where smartcards are issued from, via different intermediate certificate authorities, prior to FPKI).
- breatheoften 8y ago
  Slightly off-topic - but its semi-relevant here as this conversation involves the requirement of knowing (1) the state of the system security store (2) the state of an application's security store ... and maybe in some cases (3) understanding how an application modifies any trusted stores. It seems we end up with a lot of possibilities for the states of these stores to diverge from our expectations ... I've been wondering how to verify a sane state for all these stores for even a use as simple as my own personally owned/controlled notebook ... I'd really like a way to audit the system trust store in macOS and enforce that is in alignment with whatever the current 'blessed by apple' certificate trust relationships are and that any trust relationships I ever manually added by mistake/debugging have been removed... I asked a question about this on stackoverflow but no one has responded ... https://stackoverflow.com/questions/52527886/revert-all-certificate-trust-relationships-to-system-default-on-macos-10-mojave https://stackoverflow.com/questions/52527886/revert-all-cert...
  - rkeene2 8y ago
    I don't know the answer to your StackOverflow question as I don't use macOS/Mac OS X. What I ended up doing to help this process along is including the relevant certificates inside my DOD Smartcard PKCS#11 module as certificate objects (with, of course, no corresponding private key objects). For applications that use PKCS#11 (such as Firefox, via NSS), this means that when the module is loaded the appropriate certificates are also made available automatically. This was also (I believe) supported by the "TokenD" driver used to support macOS/Mac OS X so that enabling this driver made those certificates available and provided by the token, so no modifications to the local macOS system trust store were needed.

MrLeap 8y ago

Ah thanks for educating me. My island at TRADOC didn't have anyone who knew those details. :P