undefined

points

[-]

Good write up. Not to mention the other big HR constraints on DoD engineers: they almost always have to be a “US person.”

Anyone who gets a CAC working on a personal computer deals with this all too much. The root certs DoD uses are not part of the public trusted sources that commonly come installed in browsers.

by stult2 hours ago|

parent|

[-]

lol I very nearly included a rant about that but decided it was too far off topic. Not being able to smoke weed may be more of an obstacle these days though.

by amluto1 hours ago|

prev|

[-]

> That requires the site to use the aforementioned non-standard DoD CA certs to validate the client cert from the CAC, which in turn requires that the server's TLS cert be issued by a CA in the same trust chain, which means the entire site will not work for anyone who hasn't jumped through the hoops to install the DoD CA certs. Meaning, any public-facing site has to be entirely segregated from the standard DoD PKI system. For now, that means using commercial certs, which in turn requires a vendor that meets DoD supply chain security requirements.

Is this actually all the way technically correct? As far as I know, there is no requirement that the trust chains for server certificates and client certificates are in any way related. It seems to me that it would be perfectly possible for the DoD to use its own entirely private client certificate infrastructure but to still have the server certificate use something resembling an ordinary root certificate.

This is not to say that this would actually be all that worthwhile.

by mpyne1 hours ago|

parent|

[-]

> Is this actually all the way technically correct? As far as I know, there is no requirement that the trust chains for server certificates and client certificates are in any way related. It seems to me that it would be perfectly possible for the DoD to use its own entirely private client certificate infrastructure but to still have the server certificate use something resembling an ordinary root certificate.

I think you're right that it's possible in principle for a Web server to enforce use of DoD CAC (enforcing the client cert being in the DoD PKI) without itself using a DoD PKI cert on the server side.

That said there's little benefit to it, users who haven't jumped through hoops to install DoD root CA certs won't typically be able to get their browsers to present them to the remote server in the first place, and if we're willing to jump through those hoops then there's no good reason for the DoD server not to have a DoD PKI cert.

by amluto1 hours ago|

parent|

[-]

I've never used one of the DoD smartcards, but I can certainly imagine the DoD wanting a user of one of these smartcards to be able to use it with a COTS client device to authenticate themselves.

by mpyne24 minutes ago|

parent|

[-]

Sure, people do that all the time. After they run "InstallRoot" to install DoD root certs on their COTS device, that is. I'm honestly not sure any major browser will allow you to use a client smartcard without having the smartcard's certificate chain to the trust store used by the browser so this part seems unavoidable.

FWIW I just tested it and yes you can run a web server using a commercial server cert that enforces client PKI tied to the client having a DoD PKI cert. It works just fine.

by robolange2 hours ago|

prev|

[-]

> engineers may have to log into a jump box via a VDI to then use Jenkins to run a Groovy script to use Terraform to deploy containers to a highly customized version of AWS.

This hits too close to home. I'm sending you my therapist's bill for this month.

by wbl1 hours ago|

prev|

[-]

A site can authenticate a client cert from a different PKI than one it has.

by notesinthefield2 hours ago|

prev|

[-]

I do lots of fed cloud work and im stealing this comment to use during the next conversation around why on-prem DoD PKI is now a huge PIA.