[SERVER-1914] Enable using FIPS Bouncy Castle crypto provider Created: 2017/07/25  Updated: 2019/09/03  Resolved: 2019/09/03

Status: Resolved
Project: Puppet Server
Component/s: None
Affects Version/s: None
Fix Version/s: SERVER 6.6.0

Type: Task Priority: Normal
Reporter: Jayant Sane Assignee: Justin Stoller
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by PDB-4357 Enable the Bouncy Castle FIPS provider Resolved
is blocked by PUP-9930 Do not necessarily load OpenSSL in JRuby Resolved
Relates
relates to SERVER-2523 Explore puppet-server FIPS compliance... Resolved
Template:
Epic Link: FIPS-Enabled Puppet Server Side
Team: Froyo
Release Notes: Not Needed
QA Risk Assessment: Needs Assessment

 Description   

As part of FIPS work, we want our java based services to be able to use appropriate FIPS compliant crypto providers. The FIPS Bouncy Castle provider will be the only supported provider for FIPS enabled PE:

This is now available in artifactory and ready for internal download and usage.

  • The FIPS bouncy castle provider should be selectable and pass all acceptance testing.

 



 Comments   
Comment by Jayant Sane [ 2017/08/01 ]

Interim update:

Attempts to switch over to Bouncy Castle JSSE and JCE providers (from the default Sun/Java providers) by just making configuration changes have not been successful. Based on the errors seen in puppet server logs & their investigation till, it appears some code changes would be required. That is WIP.

Comment by Jayant Sane [ 2017/08/03 ]

Documenting what has been attempted till.

Method1: Setup a PE instance using a recent PE 2017.3.x build and then tweaked java security configuration file to prefer Bouncy Castle Providers over Sun's counterpart versions. Relevant BC jars were installed properly. While this drop-in method should have had worked, based on the errors seen it pointed to how the SSLContext was being initialized within java server code and thus needed some changes.
That led to Method 2 of running Puppet Server from sources since otherwise it would have required doing the following: make the code changes in puppet server, do the packaging and an installable.

Method 2: There were some hiccups with getting Puppet Server to run from source per the documented steps. Apparently there were some (accidental) breaking changes introduced that had to be triaged and resolved. Once that in place however the same set of changes to switch to Bouncy Castle providers like done in Method 1 yield different symptoms - very different exception trace than seen in Method1. So that has thrown some wrench with the planned code changes approach identified in Method1.

Comment by Jayant Sane [ 2017/08/09 ]

Non-pertinent notes: Wrote a simple java application that initialized SSLContext while using BouncyCastle providers successfully.
However that could not be carried over to getting Puppet Server to start successfully. While it (some minor code change mimicing them from the sample app) took care of one issue (exception) seen during startup, there continue to be some more exceptions. And at this stage, we are at a point where we have done whatever we could by adjusting JRE configuration and resolving these issues would require further code changes to get our Java based services to use Bouncy Castle; at least the indications are pointing in that direction.

Comment by Past Haus [ 2018/02/07 ]

Jayant Sane Is this still in progress?

Comment by Past Haus [ 2018/02/08 ]

Moved back to "Ready for Engineering" for the moment since it hasn't seen updates since August.

Comment by Jayant Sane [ 2018/02/14 ]

No this got shelved a bit as enabling FIPS compliant agent became 1st priority although I was trying to work on it in parallel as much as I could. Now that FIPS agent work is almost wound up, we might revive it but need to see if there are other priorities. 

Comment by Trevor Vaughan [ 2019/04/26 ]

You may get some good reference material from https://github.com/RedHatGov/fips-compliant-vault

Comment by Justin Stoller [ 2019/07/01 ]

Updated this to be blocked on PDB-4357 because the first pass at refactoring our ssl-utils library is being down under that ticket. Once ssl-utils' current functionality works in FIPS we can look into bringing it into puppetserver and what additional extensions to ssl-utils we'll need for the CA (if we go that route).

Comment by Justin Stoller [ 2019/09/03 ]

Puppet Server has taken up all of the pre-requisite library changes and is testing FIPS and nonFIPS versions per commit in Travis, though we still only build packages for nonFIPS. PE-27100 is the ticket for finishing the PE build work.

Generated at Tue Jan 28 08:39:54 PST 2020 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.