[RESOLVED] ssl_error_no_cypher_overlap

[teracow]

My understanding from the QNAP forum is that Sab runs inside a wrapper but essentially runs as it normally would, upgrades apply correctly, and all that jazz.

However, I don't know what goes on behind-the-scenes here to determine what the wrapper configures in the NAS (firewalls and such). I suspect that the selected port needs to be opened as it's not reachable:

Code: Select all

$ nmap talia. -p8085

Starting Nmap 6.00 ( http://nmap.org ) at 2013-01-28 09:38 EST
Nmap scan report for talia. (10.0.0.2)
Host is up (0.00011s latency).
PORT     STATE  SERVICE
8085/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds

Since the port is closed, it won't be reachable from any machine using HTTP, HTTPS or anything else.

This was only the case using the temporarily installed Sab that I downloaded as per your sugestion. The original Sab is accessible from any machine, as long as I use HTTP.

[sander]

We're not getting further. Is it because there is a misunderstanding between us?

[teracow]

perhaps I misunderstood your request...

Make sure SAB is accessible from other systems, make sure HTTPS is running and try it from your webbrowser.

You asked me to check accessibility from other systems - yet I have mentioned that the port that is used to access the Sab server is closed - therefore, (it would seem that) I am not going to be able to access it via ANY machine. Can you confirm for me that this is what you would like me to check?

[sander]

I thought I asked you to make SAB accessible from other systems using 0.0.0.0, otherwise sslscan and nmap will report it is not accessible (which would be stating the obvious).

I you can't access the temp SABnzbd with your webbrowser (getting the webinterface or getting the SSL error), proceeding with sslscan is useless.

[teracow]

As I have previously explained, I have not been able to enter 0.0.0.0 as a listening host as I am not presented with a HTTP interface (hence, no wizard). Perhaps you missed that bit.

Can this be done by editing files directly instead?

[sander]

As I have previously explained, I have not been able to enter 0.0.0.0 as a listening host as I am not presented with a HTTP interface (hence, no wizard). Perhaps you missed that bit.

Can this be done by editing files directly instead?

No, I didn't miss that at all.

And yes, you can.

[teracow]

...and that would be done how?

[sander]

...and that would be done how?

Stop SABnzbd, edit sabnzbd.ini on the system running SABnzbd (which is your NAS?), find first occurence of 'host', which will say localhost or 127.0.0.1, change it to 0.0.0.0, and start SAB again.

[teracow]

Hi all,

Managed to fix this. I did this by deleting the server.cert and server.key files in Config/admin/ suspecting that the fault was with them. (Odd because SickBeard used the same certificate file(s) and established a HTTPS connection correctly.)

They have now been recreated and HTTPS works properly in Sab again.

Thanks to sander for your assistance.

[sander]

Cool that it works again. Thanks for the feedback.

[teracow]

"just when you thought it was safe to restart your NAS..."

erm... so, I restarted my NAS... and went back to square one... same fault as before... unable to login to Sab using HTTPS.

So I thought I should add what I found next in case someone else sees the same thing.

---

I started looking at the certificate files. They didn't appear to have been modified...

Code: Select all

[/share/MD0_DATA/.qpkg/SABnzbdplus/Config/admin] # ll ser*
-rw-------    1 admin    administ      631 Feb  2 09:44 server.cert
-rw-------    1 admin    administ      631 Feb  2 10:20 server.crt
-rw-------    1 admin    administ      887 Feb  2 10:20 server.key

(at first I didn't know why there were 3 files - I thought a certificate should only be 2 - public and private)

then I noticed that Sab was looking at:

• server.cert
• server.key

and SickBeard was looking at:

• server.crt
• server.key

So, I changed Sab to look at server.crt and "saved changes".

Since then, I've done 2 cold-boots of the NAS and everything starts correctly. HTTPS login works on both again.

---

My theory is that Sab created the server.cert and server.key files first.

Then when I (incorrectly) configured and restarted SickBeard, it couldn't find server.crt so it created this and a NEW server.key

At this point, HTTPS login to Sab was no longer possible with an old server.crt and a new server.key but these are (possibly?) only loaded when the program starts - so the old server.key was effectively 'cached'. I could login and out as required until Sab was shutdown. Once the NAS was restarted, Sab attempted to load the certificate files again, but was now dealing with a mis-matched file pair. Hence - no HTTPS transaction possible.

Can anyone confirm this?

[sander]

I checked, and I only have:

Code: Select all

sander@R540:~/.sabnzbd/admin$ ll ser*
-rw-r--r-- 1 sander sander 631 May 29  2011 server.cert
-rw-r--r-- 1 sander sander 891 May 29  2011 server.key
sander@R540:~/.sabnzbd/admin$ 

... so dated 2011.

On another system:

Code: Select all

sander@toverdoos:~/.sabnzbd/admin$ ll ser*
-rw------- 1 sander sander 631 2012-04-09 23:25 server.cert
-rw------- 1 sander sander 916 2012-04-09 23:25 server.key
sander@toverdoos:~/.sabnzbd/admin$ 

... so dated April 2012

Maybe the files are dated the moment the initial SABnzbd install runs? If so, it is 'interesting' that your files are dated so recently ...