API Endpoints to update client certs not accessible PUT

[johnmccrae]

Chef Server Version

Stock version of Chef Server Core 14.12.21

Platform Details

Azure Ubuntu Linux 20.04, all patched up

Configuration

[Standalone, New install Ideally include your /etc/opscode/chef-server.rb or otherwise provide details of changes from the default]

Chef-Server.rb is zero bytes

Scenario

A standard user/node pem is being used to authenticate against a chef server

Chef-Client attempting a PUT against the endpoints of either
/clients/CLIENT - gets a response on the client of 400 and a message of - msg=key_management_not_supported on the server
/client/CLIENT/keys/KEY - gets a response of 403 on the client and a message - msg={update,forbidden} on the server

Steps to Reproduce

1. Use the whatever tool is handy to create a properly formatted chef-client that can properly construct the auth-headers. It's probably way simpler to pull a copy of the client up under a debugger.
2. Once you have that client constructed, issue a

        payload = {
          name: "default",
          public_key: new_public_key,
          expiration_date: end_date
        }
		client.put("/organizations/<your org>/clients", payload)
		client.put("/organizations/<your org>/clients/keys/<key to update>", payload)

Expected Result

Issuing a PUT to the /Clients endpoint should probably fail, per a conversation with @marcparadise. However, the PUT to the actual key endpoint should be working. The client team is moving certs off disk and needs access to that end point so that given clients can update themselves periodically.

Actual Result

Failure and despair! See above.

[marcparadise]

After discussion with @johnmccrae, we're closing this one. The flow that is tested in our system is:

1. add the new key using POST to the keys endpoint
2. delete the old key using DELETE

While PUT should work as well, it becomes difficult (maybe impossible) for the client to know which named key they are authenticating with (the key name on the client does not have to match that on the server); and if the caller tries to update the current in-use key, they will get a 403.