Generate SSL certificate on ReadyNAS 100 Series RN10200

It changed on my RN102, but the security error doesn't go away. Instead it just changes to

"You attempted to reach rn102, but instead you actually reached a server identifying itself as nas-xx-xx-xx.local. "

There's a bug in 6.0.4, it is not using the currently configured host name (or letting you enter a host name). Instead it regenerates the certificate using the default factory host name.

Though honestly, it is usually not worth the trouble even if it did regenerate using the right host name and the IP address - especially if you access your NAS locally and also using a ddns name. Browser security tightens over time, and one aspect many browser folks are getting pickier about is warning users about self-signed certificates like the ReadyNAS uses. If you want the error to disappear, use firefox and enter a security exception - that is by far the simplest way. Otherwise, just click through the error with whatever browser you use.

The symptoms are as you describe and indeed the certificate is not signed by the IP/hostname of my server, which is my problem.

I hope a fix or workaround becomes available soon, because the messages is not just annoying, but it also blocks the use of the following: in IE when you drag the URL to your desktop, it creates a dedicated shortcut icon for this website using the favicon of the site. This allows for a quick and user friendly way to open the admin page as if it was an desktop application. Unfortunately if the certificate is not in order, it will not allow your to open the website this way, the only option is to close the browser sessien (i.e. no option to ignore and to continue to the website).

Having a selfsigned certificate, signed by the correct IP/hostname of my server, would allow me to resolve the problem, as I have successfully done in the past for all my other RedayNAS units.

For me it is worth the trouble, because the error in internet explorer (as with other browsers) can be fully resolved by exporting the selfsigned certificate as a PKCS7 certificate and then importing it as a trusted root certifaction authority. (I also imports it as a trusted publisher, just to be sure). Also include the server as part of your internet security zone, to eliminate further warning messages. (a detailed describtion is provided below)

For internet explorer this can be accomplished by clicking the lock icon next to the server url, then choose to display the certificate and then open the details tab, where your can use the "export to file" button. Next open the internet options, go to the content tab and use the certficates button. Select the tab voor the "trusted root certification authority" and use the import button, selecting the file you exported in the first step. Then repeat this step for the "trusted publisher" tab. (not sure if both are required, so I do both just to be sure)

Then to get rid of other warning messages being displayd, you have to add the server IP or hostname to the list of websites for your local internet zone in the security tab of the internet options.I.e. in internet options, select the security tab, select the local intranet and then press the websites button to enter your server IP or Hostname.

Mileage varies here, if its worth the trouble for you, then go for it. There is a bug in OS 6.0.4, it is on Netgear's fix list and hopefully will be in 6.0.5.

As I said the bigger picture is that solution has become more troublesome and troublesome as time as gone on. Only Firefox has the easy security exception mechanism, and it won't store those certificates - it just remembers that they are exceptions. Personally I think that is the best approach to the problem, having normal end-users messing with root certificate authorities is not a good way to achieve security overall. I wish other browser vendors would pick that mechanism up. It is simple, and avoids the man-in-the-middle attack threat if the users pay reasonable attention to the initial warning.

I access my ReadyNAS units remotely using a common ddns domain name and different ports. Manually installing certs tends to be more problematic there - as far as I know the browsers can't handle multiple certs for the same url. As far as admin shortcuts, I've always used bookmarks, so that's not something I care about.

Chrome uses the OS browser certificate store btw, so if you are trying to fix that on a Windows machine you need to essentially fix it in IE. On a Mac or iDevice you'd need to fix it in Safari. And Chrome won't export the certs either.

Fair enough, I agree IE is not the preferred browser on windows. Firefox used to be my preference to, however now a days I tend to use Chrome more often. Bookmarks also works fine for me, however for less experienced users, the desktop icon can be helpful (as it is for my father, who I'm helping to install and use this RN102 unit).

The solution of Fire Fox seems practicle and could be secure if you indeed are aware of what exception your are ignoring. I'd say it would work for me too, because like you, I understand the content of the exception and can identify a man in the middle attack. Though for me to feel comfortable ignoring the exception by default, I would like to know for sure that when the condition for this exception would change (hence a man in the middel attack is apllied for server with a previously ignored exception) and that firefox would come back to me, stating that something has changed and not just goes on ignoring it.

Assuming I understand your DDNS scenario, you could consider installing a reverse http proxy on the main IP with a name based virtual host to route the traffic. Allowing you to map different urls to a common main url using the different ports you assigneed. Then again, since you're happy with the firefox solution, it's probably not worth the trouble for you ;)

Here is how you can do it with apache, almost any http server can do it,

Listen IP_ADDR:80
NameVirtualHost IP_ADDR:80

<VirtualHost IP_ADDR:80>
ServerName yourname.yourdomain

ProxyPass / http://localhost:10000/
ProxyPassReverse / http://localhost:10000/

</VirtualHost>

I am using Chrome more often as well - when Mozilla picked up the pace on FireFox updates, I found that their stability went downhill.

I agree that the exception approach needs to check that the cert hasn't changed, and shouldn't just blindly ignore any exception from that URL forever. Most users won't understand the implications of the exception messages generally, which is one reason why the security issues are so nasty here.

The reverse proxy idea is a nice tip, thx.