The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Warn when a certificate approaches the expiration date
|Affected Puppet version:||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
It’s especially troublesome if the CA or master certificate expires without any real warning. We should be warning in the logs (possibly reports, too?) if any of the certificates (CA, master, agent) are approaching their expiration date.
#1 Updated by Jacob Helwig almost 4 years ago
First guess at how far out to warn about expiring certificates is 3 months, but I’m definitely open to suggestions.
Also, the target version of 2.6.x is just a suggestion. I haven’t looked at how involved it would be to check this to generate the warning, and am open to pushing it back to 2.7.x, or Telly (though I think we should try pretty hard to get it into 2.6.x).
#3 Updated by Jacob Helwig almost 4 years ago
- Priority changed from Normal to High
I don’t think it can hurt to warn about the agent certs expiring, and seems like a reasonable thing to include in the report sent back to the master. The agent cert expiring isn’t anywhere near the same scale of problem, but it seems like a safety net worth having (even if it doesn’t warn to the same degree or start as far out).
#7 Updated by Steven Lindberg almost 3 years ago
Greetings, I’ve been working on this issue in my fork. I haven’t created a pull request yet since all of the issues in the feature haven’t been addressed.
I’ve implemented a method for logging a warning when certificates approach their expiration date, but currently it is only called in
Puppet::SSL::Host#certificate when initializing the cert. This means (I believe) that the warning will only ever be displayed when starting puppet, so it is useless for daemons on machines with long uptimes. I’ve been looking into how the daemons work, and it doesn’t seem like a big deal to add a host-related call to the agent or application, but the master is a different thing. As far as I can tell, puppet master only spawns a web server, and doesn’t have an agent that can perform the check. It seems overkill to add an agent just for this purpose… It also seems pointless to add this feature if it can’t inform the admin the the CA is going to expire (although warn on restart is better than nothing). Any guidance would be appreciated.
I haven’t looked into reporting yet, but I’m hoping that
Puppet::SSL::Host#check_expiration method can be used or slightly tweaked to accomodate. Thanks!
(PS I decided to target 3.x after reading the contributing readme, and I haven’t tried to merge to see how difficult it would be to backport it.)
#8 Updated by Deepak Giridharagopal almost 3 years ago
- Category changed from Doh! to logging
I haven’t looked into this in great detail or anything, but my initial thought is that a good place to do this validation is when the agent talks to the master…we log on the master when an agent presents a cert that’s N days away from expiring. That way it’ll show up in the master logs. Regarding reports, I think you could include this info as part of the Puppet::Transaction::Report object.
This of course only covers agents' certificates…the master’s cert and the CA cert are a different matter. Though I suppose that when an agent checks in, you could look at the expiration of those certs as well and start complaining…
#9 Updated by Steven Lindberg over 2 years ago
- Status changed from Accepted to In Topic Branch Pending Review
- Target version changed from 2.7.x to 3.x
- % Done changed from 0 to 100
Thanks Deepak, I took your advice and implemented the check when the agent communicates with the master. I attempted to limit the number of warnings as much a possible without having some kind of timeout, but it still might get a bit noisy. Maybe that’s a good thing though :) More details in the pull request/commit messages. Note that I created a new branch since there were comments on some of the other commits, but I felt it was better to rebase them off of the up-to-date 3.x (and not have a jillion of them).
#10 Updated by Anonymous over 2 years ago
- Status changed from In Topic Branch Pending Review to Merged - Pending Release