Can't retrive keys

[slayer1ss]

Hi, sorry to bother you guys...

I have a Centos 6.5 server with plesk 12.0.18 installed and today when i tried to access panel it showed me license install page and doesnt let me move forward... My license is still valid i am sure of it but when i press "Retrieve Keys" i am getting below error...

Unable to connect to license server https://ka.odin.com:5224/xmlrpc.
cURL error description: SSL connect error(35)

i checked http://kb.odin.com/en/6096 but it explains that there is a bug on libcurl and i should downgrade it and says that connection is correct if specifying version 3 manually but when i try to that to check if that really works i get same error below

curl -k https://ka.odin.com:5224 --sslv3
curl: (35) SSL connect error

that is why i didnt want to downgrade before asking if there is another way of fixing this issue...

 

[IgorG]

On my test server I see:

# plesk version
Product version: 12.0.18 Update #69
Update date: 2015/10/13 05:12
Build date: 2015/08/17 13:00
Build target: CentOS 6

# rpm -q curl
curl-7.19.7-46.el6.i686

and command

# curl -k https://ka.odin.com:5224 --sslv3

works correctly. Check version of your curl and try to re-install it at least.

 

[slayer1ss]

this is wierd...

Plesk version: 12.0.18 cant be sure about the exact mu but it should be close to #69 since it was auto updating
Curl version: curl-7.19.7-46.el6.x86_64
and
#curl -k https://ka.odin.com:5224 --sslv3
curl: (35) SSL connect error

i tried to reinstall it but nothing changed...

Edit 1:
Since reinstall didnt work i tried to update curl to latest version possible from their website;
Now curl version is: curl-7.45.0-1.0.cf.rhel6.x86_64

but i am still getting same error code with different message
# curl -k https://ka.odin.com:5224 --sslv3
curl: (35) Unknown SSL protocol error in connection to ka.odin.com:5224

Edit 2:
Btw i dont know if it is important but this error only shows it self when there is :5224 on the url... if i just pass ka.odin.com i dont get any errors...

Edit 3:
Since -ipv4 option gives me more detailed information i am using below query and getting same results...

curl -k -ipv4 https://ka.odin.com:5224 --sslv3
* Rebuilt URL to: https://ka.odin.com:5224/
* Trying 195.214.233.80...
* Connected to ka.odin.com (195.214.233.80) port 5224 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSLv3 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to ka.odin.com:5224
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to ka.odin.com:5224

 

[mizar]

Hello,

Did you try to yum update ? Might be problems with system libraries such nss or openssl, due to centos 6.5 is quite old

 

[slayer1ss]

Hello,

Did you try to yum update ? Might be problems with system libraries such nss or openssl, due to centos 6.5 is quite old

Hi, thank you for response... System is fully updated and yum doesnt return any new updates or dependency problems etc...

 

[mizar]

Hi, thank you for response... System is fully updated and yum doesnt return any new updates or dependency problems etc...

It's quite strange ... couild you show output of openssl s_client -connect ka.odin.com:5224 and openssl s_client -ssl3 -connect ka.odin.com:5224 ( or private if you consider this information sensible)

 

[slayer1ss]

That is alright, here are results of what you asked...

# openssl s_client -connect ka.odin.com:5224
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

# openssl s_client -ssl3 -connect ka.odin.com:5224
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1444758071
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

 

[mizar]

And what about modern cipher protocols? openssl s_client -connect ka.odin.com:5224 -tls1_2 -cipher ECDHE-RSA-AES256-SHA384

 

[slayer1ss]

And what about modern cipher protocols? openssl s_client -connect ka.odin.com:5224 -tls1_2 -cipher ECDHE-RSA-AES256-SHA384

# openssl s_client -connect ka.odin.com:5224 -tls1_2 -cipher ECDHE-RSA-AES256-SHA384
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1444810525
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

 

[mizar]

Very strange, may be problem between you and KA ? Firewall or something else read 0 bytes and written 0 bytes is suspicious

 

[slayer1ss]

Firewall on server is disabled but there is a Fortigate router to prevent outside attacks however plesks all required ports are added and forwarded to the server including 5224... Do you have any other ideas?

 

[slayer1ss]

Any help on this? I have also checked router and everything seem fine there...

 

[IgorG]

I suppose that it is difficult to say what is wrong there in scope of forum discussion. Investigation in detail directly on your server is required. Therefore I suggest you contact Odin Support Team.

 

[slayer1ss]

if i get paid support and error is not related to plesk but related to server, will they be able to solve this?

 

[slayer1ss]

Nevermind guys i finally fixed the problem, it was Fortigate's SSL Inspection function that was creating the problem...