All of a sudden when I try and access either the admin page ... i get this message using EDGE or Google Chrome;
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
The client and server don't support a common SSL protocol version or cipher suite.
Plenty of other folks reporting this. Always a good idea to look for that before starting a new thread. Older ReadyNAS (including the Duo) only support TLS 1.0 for HTTPS connections. Most browsers have (very) recently dropped support for TLS 1.0 and TLS 1.1. So there isn't a common protocol version anymore - and therefore no connection is made.
For now, you can still use internet explorer. If you don't have that, you can alternatively install an old version of firefox (94.0.2) that will work. https://support.mozilla.org/en-US/kb/install-older-version-firefox Make sure you immediately change the settings to disable automatic updates.
Keep an eye out here, as there might be better options in the future.
That is due to your updated MS Edge and Google Chrome browsers where TLS 1.0/1.1 is not supported or disabled. Legacy NAS running OS4 or OS5 uses TLS1.0.
You need to try using IE or download and install an older version of Firefox as a workaround. You will also need to change a setting where it will not auto update.
Make sure you have access to your data and make backup for security,
All of a sudden when I try and access either the admin page ... i get this message using EDGE or Google Chrome;
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
The client and server don't support a common SSL protocol version or cipher suite.
Plenty of other folks reporting this. Always a good idea to look for that before starting a new thread. Older ReadyNAS (including the Duo) only support TLS 1.0 for HTTPS connections. Most browsers have (very) recently dropped support for TLS 1.0 and TLS 1.1. So there isn't a common protocol version anymore - and therefore no connection is made.
For now, you can still use internet explorer. If you don't have that, you can alternatively install an old version of firefox (94.0.2) that will work. https://support.mozilla.org/en-US/kb/install-older-version-firefox Make sure you immediately change the settings to disable automatic updates.
>Yes IE does work to some degree and if I try and change my "mapped drives" from //nas1/richard to //192.168.0.10/richard that too works for now
Keep an eye out here, as there might be better options in the future.
>Strangely though when I access the default shares ( 192.168.0.10/shares ) it loads both in Edge and Google Chrome
>I'm playing about with creating Certificates now to see if I can get round this issue that way
Re: Unable to connect using a browser ( ReadyNAS Duo )
@danesol wrote: Strangely though when I access the default shares ( 192.168.0.10/shares ) it loads both in Edge and Google Chrome Why does that work ???
That is connecting with http, not https. Since there is no encryption with http, TLS isn't being used.
The NAS is redirecting http to https when you connect to frontview, so at present you cannot work around the issue by explicitly browsing to http://nas-ip-address/admin. It looks like it is possible to eliminate the redirection by changing two configuration files in the NAS - something on my list to try, but I haven't gotten to it yet.
OK, I think that the browser companies should allow the user to select TLS1.0 for local LAN addresses. It is they that caused this problem, not Netgear. It's not a "bug", it's time marching on past a system that's well out of date. TLS1.0 was the standard at the time those units were developed and getting OS updates.
Since the OS for your NAS is based upon a very outdated version of Linux, that could be a lot easier said than done. But, as I pointed out, the browser developers, who are still updating their product and who are the cause of the situation, couild also offer a solution since it's not unique to ReadyNAS.
Just face up to the fact that your 15 year old NAS is obsolete. Do you still have a PC, cell phone, etc. that's that old and you still expect updates for it? That even still works so you could update it if one were available?
And, lastly, the forum has offered you a work-around, though it does currently require SSH access and a least some basic Linux knowledge.
However what is really strange is that EDGE works on the backup, temp and media volumes using https login admin or a user account !?
If you look, you'll see that when you are browsing a share, you are using http (no encryption) - not https. So that works, since TLS isn't being used at all.
Frontview access is redirected in the NAS Virtual.conf file to always use https - so that will always generate the SSL version error with your NAS.
There is an add-on that adds TLS 1.2 support for NAS running 4.2 or 5.3 firmware. People running 4.1 firmware can use the workaround I provided in the link (which removes the https redirection, so http://nas-ip-address/admin will connect to Frontview).
To clarify - it appears to be failing on systems that have atom cpus. Unfortunately, that includes Ultra - but not Ultra Plus or Pro.
Not true. The Ultra4Plus/Pro4 has an Atom D510 @ 1.66GHz and an Ultra2Plus/Pro2's has an Atom D525 @ 1.80GHz. The Ultra4 has a D410 @ 1.66GHz, and I've never had an Ultra2, so can't quickly check.
My 4.2.31 sandbox system is a Pro2, and the add-on fails. I've tried several times from a factory default and have had results where it just does nothing and others where the GUI is completely inaccessible, even with a browser that previously worked.
To clarify - it appears to be failing on systems that have atom cpus. Unfortunately, that includes Ultra - but not Ultra Plus or Pro.
Not true. The Ultra4Plus/Pro4 has an Atom D510 @ 1.66GHz and an Ultra2Plus/Pro2's has an Atom D525 @ 1.80GHz. The Ultra4 has a D410 @ 1.66GHz, and I've never had an Ultra2, so can't quickly check.
GTW - I didn't realize the 2-bay and 4-bay Pros and Ultra Pluses also used atom processors. My only Pro is the Pro-6.
Folks can easily identify the processor with ssh - this command will do the job:
cat /proc/cpuinfo
In any event, all these systems can be converted to OS-6, which I think we both agree is a better solution.
If I can unbrick my unit, I might just go with the remove the http redirect approach
An OS reinstall should restore the broken library (and change your admin password back to netgear1).
I couldn't test the change to virtual.conf for 4.2.x systems (as I no longer am running 4.2.x). It's be useful to know if it also works with 4.2.x. I suspect it will, but there might be some other changes needed in httpd.conf.
If I can unbrick my unit, I might just go with the remove the http redirect approach
An OS reinstall should restore the broken library (and change your admin password back to netgear1).
I couldn't test the change to virtual.conf for 4.2.x systems (as I no longer am running 4.2.x). It's be useful to know if it also works with 4.2.x. I suspect it will, but there might be some other changes needed in httpd.conf.
Okay that sounds promising, I wasn't sure how much of the files would be restored by the OS reinstall.
I'm familiar with apache configs, I can take a look assuming I get back to it.
I installed the new package on a freshly factory defaulted Pro2 running 4.2.31. Though, after an inordinately long period of time, it ultimately reported an error in the installation, it works.
