Details
-
Story
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
Description
In Puppet Server 6.0.0 the puppet-ca/v1/certificate_revocation_list/ca endpoint will honor If-Modified-Since headers, serving the CRL content if modified since the time given and returning 204 and an empty body if not.
The Puppet Agent had no change of behavior in 6 and currently, and previously, does not send If-Modified-Since headers, or ever try to download a CRL if one exists on disk.
This ticket was originally for both the Server and the Agent side work, both landed, however the Agent work was reverted as it caused issues with PE's HA functionality that would require large-ish changes to how HA works.
PUP-9149 tracks updating the Agent to take advantage of this ability in Server once PE HA issues have been resolved.
While my agents are running, I expect them to check the CRL to see if it's been updated since the last download, and if so to get the latest one from the CA, so that they can correctly validate that the masters they are talking to are still valid.
This is mostly relevant for agents talking to compile masters, which also get certificates from the CA. We don't want agents to try to talk to compile masters whose certificates have been revoked.
See PUP-2310.
Q: Do CRLs have TTLs that we could respect?
A: Yes, but it's complicated and we probably should just check last modified.
Details:
So the plan going forward will be this (see https://github.com/puppetlabs/puppet/blob/76043d833f70d70fd2b5e3c43f13c5226223d8f9/lib/puppet/ssl/host.rb#L301):
1. From from `ssl_store` => `build_ssl_store`=> We will alter the `build_ssl_store` method to ALWAYS call the altered/renamed `download_and_save_crl_bundle` method.
2. That will continue to call the `Puppet::Rest::Routes.get_crls` method, but the `get_crls` method will send a header (ex If-Modified-Since)*containing the last_modified timestamp of the current crl. The /certificate_revocation_list/name* endpoint on puppetserver will then be altered to either accept a header with the timestamp and,
- If the If-Modified-Since header is present AND the timestamp is OLDER than the master's crl, will return the NEW crl to the agent in the response body and 200 response.
- If no If-Modified-Since header is included, the endpoint will function the same way as it currently functions.
- If the If-Modified-Since header is present AND the timestamp is EQUAL to or NEWER than the master's crl, will return an empty body and something like a 204 response.
We need to decide if a header or query param is more appropriate for our case. josh thoughts on this? See comment below.
Acceptance Criteria:
- The certificate_revocation_list/name endpoint on puppetserver continues to function as it always did if no If-Modified-Since header are received.
- If the If-Modified-Since header is passed to the above endpoint, it will return a crl if the timestamp provided is OLDER than the master crl file's timestamp.
- If the If-Modified-Since header is passed to the above endpoint, it will return an empty body (no crl) if the timestamp provided is EQUAL to or NEWER than the master crl file's timestamp.
- New endpoint behavior with headers are documented.
Attachments
Issue Links
- is blocked by
-
PUP-8999 Puppet failover breaks when additional requests are made during server list resolution
-
- Closed
-
- is cloned by
-
PUP-9152 Agents should re-download CRLs when they are newer than the local copy
-
- Closed
-
- relates to
-
PUP-2310 Puppet client does not update and does consult the crl during authentication
-
- Resolved
-
-
SERVER-2333 Take on puppet-ca endpoint docs
-
- Resolved
-