Requesting x509_certificate and x509_private_key

[erenfro]

Description

ServerSpec supports x509_certificate and x509_private_key, which is very useful to validate servers are being deployed the right certificate and key in integration testing, and in routine inspection to insure sanity is maintained in the systems.

[chris-rock]

This is a great idea!

[erenfro]

Yeah, I had thought so. I was actually a bit surprised it was one of the few things that was specifically not included from the features of ServerSpec. I've just been getting into using InSpec with Chef a lot more lately, and anything I find that I used that was in ServerSpec, but not in InSpec, resource-wise at least, I've been requesting. :)

[chris-rock]

x509 resources have not been excluded specifically from InSpec. We just implemented the resources based on user needs. It is good to see the demand for those resources now.

@erenfro Could you share a specific use case? Are you verifying https certificates? Or something else?

[erenfro]

Sorry, excluded may not've been the right word. Not implemented yet is a better statement. :)

I've been using x509 tests for serverspec to check a number of things. For integration testing specifically, I've actually used be_certificate, be_valid, validity_in_days, subject, issuer, email, have_purpose, keylength, and subject_alternative_name. For both internal and externally signed certificates. Helping to cover every angle to insure a bad cert doesn't get deployed to the actual servers, and that the whole chain is verified, not just the cert itself.

Also with the x509_private_key, insuring should_not be_encrypted, be_valid, and having_matching_certificate, I have used on every single tls certificate deployment as well. I've actually had it one time catch an invalid key that had no matching certificate because it had been changed already.

I've also used serverspec to remote test current running sites to run a report for any inconsistencies, including as such, expiring certificates and the likes. And since inspec can also do ssh, I could easily factor in a way to do the same with it as well independently.

[adamleff]

I ❤️ these use cases.

[aaronlippold]

I would say this is a ## very key resource to get into place. At least with the the minimum ability to parse and compare the elements of the certificate or chain to test for values. This will be KEY to automating the validation and thusly deployment of production services that require certificate based authentication. ( i.e. for OS, web servers, databases, basically everything that a user would have to present a certificate for )

https://www.stigviewer.com/stig/apache_site_2.2unix/2015-08-27/finding/V-2263
https://www.stigviewer.com/stig/application_security_and_development/2014-04-03/finding/V-6129

This also brings up the point that - for web servers - that we would need to support both x509 format and PEM format certificates.

[aaronlippold]

Technically we will need it for the Chef Automate deployments, for setting up stacks ( i.e. a web server and db that must use ssl ) etc. etc.

[aaronlippold]

Another use case could be that I want to ensure that a root cert is installed in a certificate store, like firefox. i.e. ensure the dod root cert and intermediate cert - which are signed and valid are in the firefox certificate store, properly owned by root and are valid ( i.e. return a true from an OSCP response ). This may mean that a 'certificate_store' resource might make sense.

https://www.stigviewer.com/stig/mozilla_firefox/2011-05-21/finding/V-15768
https://www.stigviewer.com/stig/mozilla_firefox/2011-05-21/finding/V-6318

[trickyearlobe]

Hi @chris-rock I have some working code I can contribute that does a lot of this (with tests and docs)