Bug 719954 - Expired user cert results in error instead of warning to log in
Summary: Expired user cert results in error instead of warning to log in
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Update Infrastructure for Cloud Providers
Classification: Red Hat
Component: Tools
Version: 2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Jay Dobies
QA Contact: wes hayutin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-08 14:00 UTC by Jay Dobies
Modified: 2012-05-31 12:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-31 12:58:12 UTC
Target Upstream Version:


Attachments (Terms of Use)
test outcome as per comment9 (274.86 KB, image/png)
2011-07-19 09:04 UTC, Sachin Ghai
no flags Details

Description Jay Dobies 2011-07-08 14:00:31 UTC
When a user logs into the RHUI, they get a local certificate that is used for subsequent communications. That certificate is good for 1 week.

Ideally, we should tell the user at RHUI Manager start up that their certificate is invalid and request they log in again.

Currently, we throw an error in rhui.log and tell the user in the UI it was an unexpected error. This needs to be cleaned up, especially since the error message isn't really indicative that it's an expired user session:

Unexpected error caught at the shell level
Traceback (most recent call last):
  File "/home/jdob/vault/code/cloude/rhui-2.0/tools/src/rhui/tools/shell.py", line 75, in safe_listen
    self.listen(clear=first_run)
  File "/home/jdob/vault/code/cloude/rhui-2.0/tools/src/rhui/tools/shell.py", line 94, in listen
    Shell.listen(self)
  File "/home/jdob/vault/code/cloude/rhui-2.0/tools/src/rhui/common/shell.py", line 191, in listen
    item.func(*args, **item.kwargs)
  File "/home/jdob/vault/code/cloude/rhui-2.0/tools/src/rhui/tools/screens/repo.py", line 55, in list
    redhat_repos = self.pulp.redhat_repo_list()
  File "/home/jdob/vault/code/cloude/rhui-2.0/tools/src/rhui/tools/pulp_api.py", line 164, in redhat_repo_list
    raise e
ServerRequestError: (None, 'sslv3 alert certificate expired', None)

Comment 1 Jay Dobies 2011-07-08 14:10:23 UTC
This is complicated in the case where the certificate expires in the middle of using RHUI Manager. I wanted to add a check on startup, but there's still the possibility of running into this midway through using RHUI Manager (or if the user leave it running for some reason).

I'll see if I can think through a different approach, but it may just end up being they see the error, restart RHUI Manager, and then are prompted to re-log in.

Comment 2 Jay Dobies 2011-07-08 17:30:53 UTC
commit 09853ee113e35acf7566384b8734cef4aad7528d
Author: Jay Dobies <jason.dobies>
Date:   Fri Jul 8 13:26:49 2011 -0400

    719954 - The shell loop will now inspect connection-related exceptions
    to see if it represents an expired certificate. If it does, RHUI will
    exit. On startup, the certificate is checked for expiration and will
    delete the certificate if it is expired, forcing the user to log in
    again.

rhui-2.0/tools/src/rhui/tools/auth.py
rhui-2.0/tools/src/rhui/tools/shell.py

Comment 3 Jay Dobies 2011-07-08 17:36:21 UTC
commit 0dc5653bbf6f26b2bc05ba6dbb557286d270d372
Author: Jay Dobies <jason.dobies>
Date:   Fri Jul 8 13:34:14 2011 -0400

    719954 - Need to delete the expired certificate on a failed server
    connection instead of just at startup in case the server's clock is
    different from the RHUI Manager's. In such a case, it's possible that
    RHUI will expect the certificate to be valid and thus not delete it and
    ask the user to log in again but the user will still be unable to
    perform any commands against the server.

rhui-2.0/tools/src/rhui/tools/shell.py

Comment 4 Jay Dobies 2011-07-08 17:41:47 UTC
Fixed in 2.0.36.

Comment 5 Sachin Ghai 2011-07-18 13:03:24 UTC
I verified in new build 2.0.40. 

I replaced the valid user.crt with  expired user.crt cert under ~/.rhui/<server_name>

Here user.crt cert expired on 18July at 14:27PM

<snippet>
   Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=RHUI User PKI
        Validity
            Not Before: Jul 11 14:27:31 2011 GMT
            Not After : Jul 18 14:27:31 2011 GMT
        Subject: CN=admin:admin:c36f0885-4381-4a44-ba3b-fefcd977b8ae
        Subject Public Key Info:
<snippet>



So here are two cases. Case1 is working fine. However case2 is not working as per the documentation bug(720019).

case1:
=====

So when I exit from already running rhui-manager, and again re-run the rhui-manager, I got the expiration message as below:

------------------------------------------------------------------------------
rhui (home) => exit
[root@dhcp201-133 ~]# rhui-manager 
Existing certificate for server dhcp201-175.englab.pnq.redhat.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: admin
RHUI Password:

Comment 6 Sachin Ghai 2011-07-18 13:05:01 UTC
Case2:
======
Assuming that I'm already logged-in when the user.crt get expired. In this case when I list the rhui-managed repo, its should through a message like below. This is as per the doc bug 720019.

------------------------------------------------------------------------------
rhui (repo) => l

The current user's certificate has expired. Restart RHUI Manager
to log in again and retrieve a new certificate.

[user returned to prompt]
------------------------------------------------------------------------

However currently, I can list the repo even after expiration of cert (user.crt).

------------------------------------------------------------------------------
rhui (repo) => l

Custom Repositories
  repo_01

Red Hat Repositories
  Red Hat Enterprise Linux 6 Server - Optional from RHUI (Source RPMs) (6Server-x86_64)
  Red Hat Update Infrastructure 1.2 (RPMs) (5Server-x86_64)
  Red Hat Update Infrastructure 1.2 (RPMs) (5Server-i386)
  Red Hat Enterprise Linux Server 6 Optional Updates (RPMs) (6Server-x86_64)

Comment 7 Jay Dobies 2011-07-18 13:51:27 UTC
Can you double check this? It doesn't make sense.

The bug was around hiding an ugly error message from the user in the case where Pulp kicks them out because the certificate is expired. In this case, you weren't kicked out, you actually got data. So in a way, RHUI Manager is working correctly; Pulp didn't report the certificate as expired.

That expired certificate stuff has been in Pulp for a while now, so my first reaction is that this was a tester error. But it's always possible it's a bug. So please do the following:

- Repeat the test and verify that it still happens.
- Do the test using pulp-admin and an expired Pulp certificate. That will circumvent any of RHUI Manager's client-side checks and attempt to send an expired certificate.

Comment 8 Jay Dobies 2011-07-18 13:54:03 UTC
Just a heads up: while you're at it, when testing the pulp-admin side of things, you can easily verify this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=651867

I only mention it because I happened to get an e-mail about it being ON_QA and it's totally relates to this.

Comment 9 Sachin Ghai 2011-07-19 08:58:41 UTC
Yes, I checked this couple of times.

Here is what I'm trying to reproduce this issue.

1. Open two sessions of rhui-manager, lets say 'A' and 'B'
2. In session A, run the rhui-manager, make sure that you'r in "home" screen of rhui-manager.
3. In session B, copy the expired user.crt cert under ~/.rhui/<server_name> directory.

4. Now try to work in Session A, by listing rhui-managed repos or check the detailed info of a repo ( using i).

By all above steps, I can still work with rhui-manager in session 'A' with expired user.crt.

I'm attaching a screen shot in next comment.

Comment 10 Sachin Ghai 2011-07-19 09:04:42 UTC
Created attachment 513738 [details]
test outcome as per comment9

When you open the attachment, On the right side of screenshot, I'm running the rhui-manager and on left side I copied the expired certs. 

And after copying expired certs, I can still list the rhui-manged repos.

Comment 11 Sachin Ghai 2011-07-19 10:04:17 UTC
I'm not sure if I correctly understand this pulp-admin side test. 

But to verify this defect from pulp-admin side, I generated the user-cert.pem using auth login command.

pulp-admin -u admin -p admin auth login --username admin --password admin
User credentials successfully stored at [/root/.pulp/user-cert.pem]

This certs was valid for 7 days only. 

<snippet>

 Serial Number: 9 (0x9)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=RHUI User PKI
        Validity
            Not Before: Jul 19 09:38:22 2011 GMT
            Not After : Jul 26 09:38:22 2011 GMT
        Subject: CN=admin:admin:b244007c-1a1d-46ac-956b-6a6cfcb2dd52
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
</snippet>


Later, I copied the expired user.crt ( genearted by rhui-manager) under ~/.pulp.
and ran "cds list" command:

[root@dhcp201-175 .pulp]# pulp-admin cds list
error: operation failed: No valid authorization credentials found, please see: pulp-admin --help


To confirm the above mesage, I set the "user_expiration_cert" to 1 in pulp.conf and generated a cert. This will expire by tomorrow and then i'll test this again.

Comment 12 Jay Dobies 2011-07-19 13:40:35 UTC
Let's see what happens when you try with the Pulp test tomorrow. If that is successful, I'm not going to worry about the bug since it will show that Pulp successfully rejects expired certificates.

Case 2 may not be a valid test. It's possible that RHUI Manager is caching the certificate it starts with. So despite you copying the expired certificate to ~/.rhui/<server>, RHUI Manager may not be reloading it and may instead continue to use the original (valid) one.

If the pulp-admin test successfully rejects the expired certificate tomorrow, and since Case 1 was successful, I'd consider this bug verified.

Also, you should be able to set the number of valid days to a negative number to generate expiration dates in the past. I know it works from the openssl command line and should work within Pulp, but I've never tried it.

Comment 13 Sachin Ghai 2011-07-20 10:02:41 UTC
Yes, pulp-admin rejects the expired certs.  Here is the small snippet of expired certs:

<snippet>
 Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=RHUI User PKI
        Validity
            Not Before: Jul 19 09:38:53 2011 GMT
            Not After : Jul 20 09:38:53 2011 GMT
        Subject: CN=admin:admin:b244007c-1a1d-46ac-956b-6a6cfcb2dd52
        Subject Public Key Info:
       
</snippet>

And pulp-admin throws following error:

[root@dhcp201-175 .pulp]# pulp-admin cds list
error: operation failed: sslv3 alert certificate expired


Also, as you suggested I used -ve number as valid days to generate certs with expiration dates in past.

  Serial Number: 13 (0xd)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=RHUI User PKI
        Validity
            Not Before: Jul 20 09:30:19 2011 GMT
            Not After : Jul 19 09:30:19 2011 GMT
        Subject: CN=admin:admin:b244007c-1a1d-46ac-956b-6a6cfcb2dd52


And when I used pulp-admin, got the same error as above:
[root@dhcp201-175 .pulp]# pulp-admin repo list
error: operation failed: sslv3 alert certificate expired


I'm moving this to verified as per comment 12, since pulp-admin test successfully rejecting the expired certs and Case 1 is successfull.

Comment 14 wes hayutin 2011-08-01 21:40:57 UTC
moving to release pending

Comment 15 wes hayutin 2012-05-31 12:58:12 UTC
closing out, product released


Note You need to log in before you can comment on or make changes to this bug.