Lately I have had a few users whose cert has expired(or is about to expire).
I have a clue, these users work from home and connect with VPN after they login. presumably certmonger tries to renew cert shortly after network is available but before user has logged in and that will fail and certmonger will not retry when vpn comes up later.
certmonger is unaware of network connections. It renews on the schedule defined by enroll_ttls. See certmonger.conf(5). If the connection is not available when certmonger wants to do the renewal it will wait until the next renewal time.
yes, which is 1 week? After that week the same happens, computer is turned on and certmonger tries again and fails, some time later user logs in and connect VPN but then it is too late.
So I think certmonger needs to be a bit more proactive to avoid this.
The renewal times by default are: 28d, 7d, 3d, 2d, 1d, 12h, 6h, 2h, 1h
You can configure the renewal times to be as aggressive as you need.
hmm, but will that work in my scenario?: turn on computer in the morning later connect vpn work some turn off computer when done for the day.
I think certmonger will try to renew when computer has booted but not yet connected to vpn
certmonger wasn't designed to handle intermittent connections like this. It works on a timer alone. Your use-case is not something directly supported and is unlikely to be.
How does enroll_ttls work if enroll_ttls = 2419200 and computer is off when this time is met and then the computer is turned on the day after? does it just skip the renewal as one missed the 28 day window?
That is correct. The value is basically a timer prior to when the certificate expires.
Now if all chances are missed while a machine is down and it comes back up certmonger should notice that the cert is expired and attempt to renew it.
Metadata Update from @rcritten: - Issue close_status updated to: invalid - Issue status updated to: Closed (was: Open)
I forgot about this one ... I don't thing my use case odd/invalid. Seems like certmonger only support one use case: long running servers which are always connected to CA server. That is a bit thin and could be improved upon.
It isn't about being connected to the CA server. No persistent connection exists. It is a reachability problem. certmonger isn't triggered by network events. I'm not even sure it if can detect them, or be able to know for example that a VPN is now up. The result could be a LOT of churn on systems with certmonger aggressively trying to renew certs.
I know and that is the problem. There is no retry if certmonger is not running or cannot reach the CA when timer fires.
Surely something can be done to improve this? Perhaps add some monitoring of new networks and/or retry a few times every few ours ? Such mechanism would not impose much extra load I think and would only add work when renewal has failed.
certmonger does exactly as you describe. By default it tries renewal a configurable number of seconds prior to the not-after date of the certificate using the enroll_ttls in certmonger.conf(5). By default it is 2419200, 604800, 259200, 172800, 86400, 43200, 21600, 7200, 3600.
yes, but this is somewhat static, it is one try X sec from Not after date. if the computer is off or cannot reach CA at those exact times it will fail.
Depends very much on that the Not After time matches work hours and computer is used every day(including week ends)
Can certmonger renew a cert with has expired automatically?