Bug 64126

Summary: rhn_register aborts with message saying SSL_connect error
Product: Red Hat Satellite 5 Reporter: Mithun Bhattacharya <inzoik>
Component: RegistrationAssignee: Cristian Gafton <gafton>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: alikins, cturner, mihai.ibanescu, pjones, taw
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-04-28 10:33:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
anaconda-ks.cfg file for the workstation with the problem
none
another attempt same error message new anaconda-ks.cfg
none
a very minimalistic installation which failed again none

Description Mithun Bhattacharya 2002-04-26 05:59:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311

Description of problem:
To the best of my knowledge there is nothing blocking TCP IP connections from
the workstation to the internet as such. Yet on running rhn_register and opting
not to use any proxy I get the following message.
"A socket error occured: SSL_connect error, attempt #1"
This message is repeated 4 times with the attempt # increasing everytime and
finally it pops up a window saying Fatal Error with the message "SSL_connect error"

Version-Release number of selected component (if applicable):


How reproducible:
Didn't try

Steps to Reproduce:
1. Using RedHat 7.2 ISO as distributed through the ftp server.
2. Opted to do a custom install.
3. I have attached my anaconda-ks.cfg file without the password values.

Actual Results:  Running rhn_register throws up 4 failed attempts with error
message saying SSL_connect error.

Expected Results:  Should register me to RHN

Additional info:

Comment 1 Mithun Bhattacharya 2002-04-26 06:02:51 UTC
Created attachment 55384 [details]
anaconda-ks.cfg file for the workstation with the problem

Comment 2 Mithun Bhattacharya 2002-04-26 09:30:34 UTC
Created attachment 55404 [details]
another attempt same error message new anaconda-ks.cfg

Comment 3 Mithun Bhattacharya 2002-04-26 09:35:55 UTC
Tried out the following - no proxies were used

links https://www.rhns.redhat.com/XMLRPC

and got the following

<quote>
                                                         405 Method Not Allowed
                               Method Not Allowed                              
                                                                               
   The requested method GET is not allowed for the URL /XMLRPC.                
                                                                               
     ----------------------------------------------------------------------    
                                                                               
    Apache/1.3.22 Server at rhnapp-1.rwc-colo.redhat.com Port 80                

</quote>

Makes me think there isnt any problem with internet access at my side. Will give
it another try using the latest rhn_register.

Comment 4 Mithun Bhattacharya 2002-04-26 11:25:55 UTC
Created attachment 55424 [details]
a very minimalistic installation which failed again

Comment 5 Mithun Bhattacharya 2002-04-26 11:28:59 UTC
This is in reference to my third attempt. I did a minimalistic installation and
also upgraded rhn_register, python-xmlrpc and up2date to the latest version as
shown below. The problem persists. I made sure https://rhn.redhat.com was
opening fine using links from that workstation.

------------------------
rpm -q python-xmlrpc rhn_register up2date
python-xmlrpc-1.5.1-7.x.3
rhn_register-2.7.9-7.x.2
up2date-2.7.61-7.x.2

Comment 6 Chip Turner 2002-04-26 12:29:46 UTC
SSL connect errors sometimes stem from the time on the client system being far
in the future or in the past.  Can you confirm the time is correct?

Comment 7 Mithun Bhattacharya 2002-04-26 14:06:12 UTC
I didnt get to check the second workstation but the first one is 10 min behind
time. That couldnt possible be a issue could it ??

Comment 8 Adrian Likins 2002-04-26 17:54:43 UTC
times in the past should be fine, usually only times very far in
the future on the clients cause problems.

Typically, ssl_connect errors are either a proxy issue (misconfigured
proxy values, or some cases transparent proxies that dont support
ssl) or time issues causing the ssl certs to expire immediadetly.

The error you get going to that url via a browser seems to
indicate you are able to properly connect to the servers
via ssl in general.

I assume the default version of openssl is installed on those machines?

Could you attach a copy of /etc/sysconfig/rhn/rhn_register ?

The only thing slightly unusual I see is it looks like these boxes
are behind a NAT of some sort, but that shouldnt be an issue. Does the
NAT forward port 443? (ssl seems to work from a browser [I assume the
`links` was ran from the same machine as rhn_register?] but I dont
really see anything obvious that should be preventing this from working.)



Comment 9 Mithun Bhattacharya 2002-04-28 10:33:25 UTC
Ok guys thanks a lot for your feedback - I guess time was the issue. I
reformatted one of the workstations did a fresh install and configured ntpd on
it. guess what rhn_register worked fine on it. Mind you the workstation was 10
min behind on one and 5 behind on the other I dont think it is a good thing for
rhn_register to do for such minor lags. After all you cant expect guys to sync
their PC Clock to a time server before running rhn_register ...

My verdict on this issue time was the problem but it shouldnt have been - so you
might want to close this ticket but rhn_register or python_xmlrpc still needs to
be fixed.

Comment 10 Cristian Gafton 2002-08-15 05:21:28 UTC
Thanks for the update - We're still trying to detect a saner patern for the time
issues. it's not only how minutes off you are, looks like timezone also plays a
role...


Comment 11 Cristian Gafton 2002-08-15 05:25:33 UTC
*** Bug 60826 has been marked as a duplicate of this bug. ***