Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide Method to install DoD Root Certs for Server and Client OS #755

Closed
erjenkin opened this issue Oct 14, 2020 · 4 comments
Closed

Provide Method to install DoD Root Certs for Server and Client OS #755

erjenkin opened this issue Oct 14, 2020 · 4 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@erjenkin
Copy link
Member

Is your feature request related to a problem? Please describe.
There are several vulnerabilities that exist involving DOD Root certificates. PowerSTIG should have the ability to install the latest version to provide a more complete configuration.

Describe the solution you'd like
Create an org setting for Server and Client OS that will have a blank path variable. Users will specify a location for the dodrootcert.msi to install with PowerSTIG

@erjenkin erjenkin added the enhancement New feature or request label Oct 14, 2020
@erjenkin erjenkin added this to the 4.6.0 milestone Oct 14, 2020
@erjenkin erjenkin self-assigned this Oct 14, 2020
@erjenkin
Copy link
Member Author

Also need to use the Cross-Site Removal tool

@EngThis
Copy link

EngThis commented Nov 3, 2020

Why would you want to do this with PowerSTIG? Im usually using PowerSTIG as the last resource in a DSC configuration, I would use the DSC Package resource prior to PowerSTIG to install the DOD root application from DISA. Or at the very least maybe the Package resource can become part of the resources PowerSTIG uses to do this?

@erjenkin
Copy link
Member Author

erjenkin commented Nov 3, 2020

@EngThis

PowerSTIG has rules for each OS that call out specific versions of these certificates with Thumbprints represented.
Example of 2019 - Member Server STGS
V-93487-

If an expired certificate ("NotAfter" date) is not listed in the results, this is not a finding.

Subject: CN=DoD Root CA 2, OU=PKI, OU=DoD, O=U.S. Government, C=US
Thumbprint: 8C941B34EA1EA6ED9AE2BC54CF687252B4C9B561
NotAfter: 12/5/2029

Subject: CN=DoD Root CA 3, OU=PKI, OU=DoD, O=U.S. Government, C=US
Thumbprint: D73CA91102A2204A36459ED32213B467D7CE97FB
NotAfter: 12/30/2029

Subject: CN=DoD Root CA 4, OU=PKI, OU=DoD, O=U.S. Government, C=US
Thumbprint: B8269F25DBD937ECAFD4C35A9838571723F2D026
NotAfter: 7/25/2032

Subject: CN=DoD Root CA 5, OU=PKI, OU=DoD, O=U.S. Government, C=US
Thumbprint: 4ECB5CC3095670454DA1CBD410FC921F46B8564B
NotAfter: 6/14/2041

Your method just uses a package resource to install the root cert application, not actually confirm the certificates exist.
How do you use DSC to determine if each certificate exists where it should be?

I am using the CertificateDSC resource that will ensure each certificate, based on thumbprint is in the Localmachine\root or Localmachine\disallowed depending on interoperability or root CA cert.

If you choose not to use these you can always skip them in your config.

Thanks,
Eric

@EngThis
Copy link

EngThis commented Nov 3, 2020

This makes sense, I wasnt sure exactly why you were doing this and in my experience after running the DOD root application and then running a SCAP scan the certs have always been reported as being where they were supposed to be. I was just curious, thanks for the quick response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants