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):
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
Created attachment 55384 [details]
anaconda-ks.cfg file for the workstation with the problem
Created attachment 55404 [details]
another attempt same error message new anaconda-ks.cfg
Tried out the following - no proxies were used
and got the following
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
Makes me think there isnt any problem with internet access at my side. Will give
it another try using the latest rhn_register.
Created attachment 55424 [details]
a very minimalistic installation which failed again
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
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?
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 ??
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.)
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
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
*** Bug 60826 has been marked as a duplicate of this bug. ***