On Mon, Dec 21, 2020 at 7:57 AM Илья Шипицин <chipits...@gmail.com> wrote:
> that's interesting point. > being dependent on whether users logs or not does not look very good. > We only go to their logs when they come to us with issues. When we can head the users off ahead of time, it's easier. > I'd say it is identity management related thing to renew user cert when it > is about to expire. > i.e. notify user in proper way and tell him to renew. > > as a side question, how do you inform users ? i.e. is it some self service > portal ? > It's definitely "an IAM problem" to begin with... but it becomes "a VPN problem" eventually. (abstractly speaking). We have a cron that, every day, looks at the CA's VPN certs. If you are at 14, 7, 3, 2, or 1 days left, you get an email warning of the impending expiration and links to the login portal + docs so you can renew (or revoke the cert and stop being nagged). At 2 days expired you get a final mail explaining that it's expired and you won't be nagged anymore and what to do if you need back in. This helps tickets a lot, but when people filter their mail and never read it, the lack of access falls through to being "a VPN problem." We did what we could to head off the issue ahead of time from the IAM side, and it becomes a situation where, as the support personnel, "well, there MUST be something vastly wrong because surely nobody would miss 6 emails and end up here asking me to look at a problem." ... except, they do. My contention is, a VPN client has enough information from its own certs to know when its certs are expired and thus not going to work (Yes, there's plenty of OTHER reasons a connection can fail, but in a well designed setup, the user's certs will go stale long before the server). It tells you this problem in the logs, which folks never read. If the software were to contain a mechanism to make certain failure cases automatically more prominent, particularly for 'simple' users who have GUI clients, it'll be a big win for supportability on larger installs. And I realize this is getting into advocacy and away from what's right for a -devel list, so I'll stop here on this thread.
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
