CHEF_FIPS=1 causes bad_sig and 401 Unauthorized from erchef

This is here as a bread crumb trail..

When the environment variable CHEF_FIPS is set to 1 a restore operation will send WARNING messages in obtuse ways that are not immediately obvious, like (xxxxx == redacted):

Restoring users
Updating user record for xxxxx
WARNING: Wrong number of users to update for xxxxx. Skipping
Updating user record for xxxxx
WARNING: Wrong number of users to update for xxxxx. Skipping
Updating user record for xxxxx
WARNING: Wrong number of users to update for xxxxx. Skipping
Updating user record for xxxxx
WARNING: Wrong number of users to update for xxxxxx. Skipping
Updating user record for xxxxx
WARNING: Wrong number of users to update for xxxxx. Skipping
...

The errors log from the exception handler has more clues:

  "message": "401 \"Unauthorized\"",
...
  "exception": "Net::HTTPServerException",
  "req_path": "/users",
  "req_method": "POST"

Erchef has the actual reason (bad_sig):

2017-10-31T19:17:03Z erchef@127.0.0.1 method=POST; path=/organizations; status=401; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAOs2gCgAAEAAAAA; msg=bad_sig; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=2; rdbms_time=0; rdbms_count=1; user=pivotal; req_api_version=0;

The workaround for now is unsetting that environment variable then running the ec restore as normal :

export CHEF_FIPS=

No source file or test is named. Start by reproducing an ec restore with CHEF_FIPS=1 and trace the POST requests, especially /users and /organizations, alongside erchef's bad_sig log. Done means the restore completes without 401 Unauthorized or bad_sig failures while FIPS mode remains enabled.