[SERVER-2441] Return 200 when server already has agent's CSR Created: 2019/01/25  Updated: 2019/03/25  Resolved: 2019/03/25

Status: Closed
Project: Puppet Server
Component/s: None
Affects Version/s: None
Fix Version/s: SERVER 6.y

Type: Improvement Priority: Normal
Reporter: Maggie Dreyer Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Acceptance Criteria:

Server returns 200 when it receives an agent CSR request that exactly matches the CSR it already has saved for that certname.

Epic Link: Simplify agent SSL initialization
Team: Froyo
QA Risk Assessment: Needs Assessment


Currently, if a server has a CSR on file for a given certname, and the agent submits a second one, the server will respond with a 400, regardless of whether the two CSRs are the same or different. This means that the agent can't tell whether the CSR the server has matches its current private keys or not, and therefore doesn't know whether it should continue waiting for a cert matching its keys, or clear state and start over, as it should if the server has a CSR that doesn't match the current state (because in this case the cert the server would sign would not be valid for the agent).

We should update the way the server responds to CSR requests to distinguish these two cases:
1) if the CSRs match exactly, return 200 as a no-op server-side, and the agent can just proceed as if no previous CSR had been submitted.
2) if the CSRs do not match, return 409 Conflict, to allow the agent to tell the user that the server has an invalid CSR that needs to be cleaned out before cert bootstrapping can continue.

This change should be backwards compatible, because the agent currently proceeds on a 200 and raises the server's error on anything else. This change would essentially mean we are just returning 200 in more cases than previously.

Comment by Maggie Dreyer [ 2019/01/25 ]

Josh Cooper what branches would you like us to target for this? And does this need to be done urgently (as in, is it blocking other work?) or just "for the next release"?

Comment by Josh Cooper [ 2019/01/25 ]

I think next release is fine

Comment by Josh Cooper [ 2019/01/25 ]

From Charlie Sharpsteen, "Should we return fingerprints in the error message to indicate which CSRs are involved in the conflict?"

Comment by Josh Cooper [ 2019/03/21 ]

Feel free to close this if you want, or file it away for future improvement. We ended up not needing it for 6.4.

Generated at Fri Jul 03 20:28:24 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.