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:
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 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.
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 python-xmlrpc-1.5.1-7.x.3 rhn_register-2.7.9-7.x.2 up2date-2.7.61-7.x.2
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 be fixed.
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...
*** Bug 60826 has been marked as a duplicate of this bug. ***