Bug 1805385

Could you please elaborate on the nature of the bug? AIUI, you're describing the case where /root/.rhui/RHUA_HOSTNAME/user.crt expires, in which case the full output is:

"""
Existing certificate for server rhua.example.com was found but has expired.

Previous authentication credentials could not be found. Logging into
the RHUI.

If this is the first time using the RHUI, it is recommended to change
the user's password in the User Management section of RHUI Tools.

RHUI Username:
"""

The cert has expired and you're asked to enter your RHUI username (and later also the RHUI password) so that you can get a fresh certificate, which will, BTW, be valid for another week, at which point you'll need to get a fresh cert again.

Are you not asked to enter the RHUI username? Or do you find the warning itself annoying? Or would you expect the cert to be refreshed automatically?

Thanks for asking for clarification Radek and apologies for the confusion. I *am* prompted for the RHUI username and password. As a relatively new administrator of a RHUI infrastructure I found the warning both confusing and misleading. Aside from the output showing up at the same time as the message regarding the previous authentication credentials being found, there is no other way to associate the certificate warning as written as having anything to do with user authentication and instead implies that there is something wrong with a certificate tied to the running RHUI infrastructure itself. From my perspective when using other Red Hat tools and rpm-based software I would treat this warning as its own entry, sort of a flag that shows up if certain conditions are met and not necessarily related to any prompting information I might receive.

At minimum I'd advise rewording the warning to give more detail on *which* certificate is expiring as to not confuse the user. If there is a need to go beyond this I suppose you could possibly allow the user to store the credentials to some sort of keyring if present on the system. As far as renewing the certificate automatically I don't see how you'd do it without having the credentials stored or cached somewhere within the application itself(not a keyring) which considering the nature of this software might not be the best idea.

On the other end of the spectrum you could have this act as a hard failure when running the command where the user is not prompted for credentials but it instead exits with an error message and instructs the user to renew the certificate manually by passing some sort of dedicated command line flag. I feel a more descriptive warning and/or the keyring method would be more user friendly but I have seen other tools take this sort of hard-failure approach to clearly communicate to the user there is an issue.

I see, thanks. That's a good point and I agree the user experience could be improved. We'll think about this. Thanks again.

I appreciate taking the feedback. Is there a way I can track whether this is implemented down the road? Thank you for the assistance.

It should be sufficient to watch the status of this bug. It's still NEW, but we've been looking into the issue and will likely resolve it in the very next RHUI update. RHUI updates are released every second month, the latest version went out in January.

Sam,

The next update will remove the warning. If it's impossible to use the user certificate -- either because it doesn't exist or because it has expired -- one will simply be informed about the fact that they're now logging in to RHUI and prompted to do so. Also, rhui-manager will keep track of password changes, so the recommendation to change the password will only be printed if that hasn't happened yet. 

Does that sound reasonable to you?

Thank you for the excellent support and communication Radek. Your resolution sounds great, we'll await the targeted release. Thanks!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:0791

The status is now closed/errata, but I wanted to follow up on this bug anyway: Sam, you should now be able to update to rh-rhui-tools version 3.1.5, which removes the confusing messages. Thanks again for your bug report and the detailed explanation of the issue.