Also failed with m2crypto version...

[root@jsefler-63server ~]# rpm -q m2crypto
m2crypto-0.20.2-9.el6.x86_64

Also note that identity --regenerate will not work when in this state...

[root@jsefler-63server ~]# subscription-manager identity --regenerate
certificate verify failed

Reproduced with a modified local Candlepin, set to give just 2 months for the identity cert, regenerate my systems certificate, and I am immediately unable to verify my certificate. (no system date manipulation at all)

(root@redhat ~) $ subscription-manager identity                                                      
certificate verify failed
(root@redhat ~) $ openssl x509 -text -in /etc/pki/consumer/cert.pem| grep -A2 Validity
        Validity
            Not Before: Jun  5 15:01:33 2012 GMT
            Not After : Aug  5 15:01:33 2012 GMT
(root@redhat ~) $ date
Tue Jun  5 12:03:08 ADT 2012
(root@redhat ~) $

Good news, I think this may not be a bug after all. The reason is because the server's CA certificate we use to verify the signatures is expired. You can see the same error even if you go straight to openssl.

$ openssl verify -CAfile /etc/rhsm/ca/candlepin-ca.pem /etc/pki/consumer/cert.pem                  
/etc/pki/consumer/cert.pem: CN = localhost, C = US, L = Raleigh
error 10 at 1 depth lookup:certificate has expired
OK

This prompted me to look at my candlepin-ca.pem (which was very very old on my dev machine, I often use insecure=1 in rhsm.conf):

$ openssl x509 -text -in /etc/rhsm/ca/candlepin-ca.pem| grep -A2 Validity                          
        Validity
            Not Before: Apr  1 18:57:50 2011 GMT
            Not After : Mar 31 18:57:50 2012 GMT

So my CA cert was expired for a couple months now. 

I regenerated my server certificate, and did the following:

(root@redhat ~) $ cp /etc/candlepin/certs/candlepin-ca.crt /etc/rhsm/ca/candlepin-ca.pem
(root@redhat ~) $ subscription-manager clean                                                         
All local data removed
(root@redhat ~) $ subscription-manager register --username=admin --password=admin --force --org=admin
The system has been registered with id: 447ee2c3-6284-472f-84ac-bc68a980cd78 
(root@redhat ~) $ env PYTHONPATH=/home/dgoodwin/src/subscription-manager/src /home/dgoodwin/src/subscription-manage
r/src/subscription-manager identity
Current identity is: 447ee2c3-6284-472f-84ac-bc68a980cd78
name: redhat.local.rm-rf.ca
org name: Admin Owner
org id: ff80808137bd1eef0137bd1f06390009
(root@redhat ~) $ openssl x509 -text -in /etc/rhsm/ca/candlepin-ca.pem| grep -A2 Validity
        Validity
            Not Before: Jun  5 15:33:45 2012 GMT
            Not After : Jun  5 15:33:45 2013 GMT
(root@redhat ~) $ openssl verify -CAfile /etc/rhsm/ca/candlepin-ca.pem /etc/pki/consumer/cert.pem
/etc/pki/consumer/cert.pem: OK

Both m2crypto and openssl now think the certificate is valid.

Verified that both Katello and Headpin are generating this certificate for 25 years, so this is really only an issue for developer deployments (I will adjust this in deploy script and cpsetup today) and for QE when pushing the system date way into the future.

Hi Devan

By looking at Comment 6 - Comment 8, I don't quite understand that it is the same issue as reported in Comment 0.
 
Notice that in comment 0, that the bug was reported against stage or prod candlepin.

> [root@jsefler-63server ~]# subscription-manager config
> --server.hostname=subscription.rhn.stage.redhat.com

I checked that both candlepin-stage and redhat-uep.pem are valid through 2030.

# openssl x509 -text -in /etc/rhsm/ca/candlepin-stage.pem | grep Validity -A2
        Validity
            Not Before: Oct 26 20:12:21 2010 GMT
            Not After : Oct 21 20:12:21 2030 GMT

# openssl x509 -text -in /etc/rhsm/ca/redhat-uep.pem | grep Validity -A2
        Validity
            Not Before: Oct  4 13:27:48 2010 GMT
            Not After : Sep 29 13:27:48 2030 GMT

Could you explain it a bit more?

Very good catch Keqin, my apologies, I had a reproducer, but mistakenly assumed it was the same issue. It does not appear to be. Re-opening.

Ok so we have traced down this issue as well, the result is quite similar to the previous reason.

redhat-uep.pem is not used to verify the identity certificates, actually we trust them but instead verify the certificate the server returns during the SSL handshake. This can be extracted from the output of: 

openssl s_client -connect subscription.rhn.redhat.com:443

Save the certificate portion into a separate file, and view with:

openssl x509 -text -in servercert.pem

In here you will see the server cert's expiry date:

        Validity
            Not Before: Feb  4 06:19:59 2011 GMT
            Not After : Feb  3 06:19:59 2013 GMT

So any time we bump the client system date beyond Feb 3 2013, the certificate validation will start to fail because the server's certificate has expired.

I have been informed this is ok and normal, the server cert is regenerated yearly and this does not require any client changes.

You can see the results:

(root@rhel6 /etc/rhsm/ca) $ date 020100002013
Fri Feb  1 00:00:00 AST 2013
(root@rhel6 /etc/rhsm/ca) $ subscription-manager identity
Current identity is: 128b7f48-a1e5-41d0-b94c-25c0dc3869bd
name: rhel6.local.rm-rf.ca
org name: 5894300
org id: 8a85f9812f035407012f273805c3284a
(root@rhel6 /etc/rhsm/ca) $ date 020400002013            
Mon Feb  4 00:00:00 AST 2013
(root@rhel6 /etc/rhsm/ca) $ subscription-manager identity
certificate verify failed

In short everything is behaving ok, it's just caused by pushing the system date beyond the server's date, which causes validation to fail.

Re-closing.