Hackviking He killed Chuck Norris, he ruled dancing so he took up a new hobby…



Sending unencrypted FTP across the internet is a bad idea! You send your credentials in plain text compromising access security as well as the data your sending. My book live duo has, as most NAS products, support for unencrypted FTP. Since it's based on vsftpd it's only a matter of configuration to make it a much more secure FTPS implementation instead. In this post I'm using my Western Digital My Book Live Duo but this is applicable to most Western Digital NAS products and many other brands as well.

Enable SSH

First of all we need to enable SSH to be able to get access more configuration options for the FTP service. By accessing http://{WD IP-address}/UI/ssh you will see a screen where you can enable SSH access and get the root password.

Enable SSH

After this we can connect to the Live Duo via SSH. I recommend that you change the root password the first thing you do, use the passwd command to accomplish this.

Create certificate

The My Book Live Duo, and probably most of the other models as well (since the share much of the firmware), already have openssl installed which we can use to create the certificate. First we need to create a folder for the certificates and generate them. I generate both 2048bit and 4096bit certificates since I want to test the performance difference (see below). You should not use the 1024bit key length since that has been proven to be weak and can be broken.

mkdir /etc/ssl/ftp
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/ftp/vsftpd_2048.key -out /etc/ssl/ftp/vsftpd_2048.pem
openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout /etc/ssl/ftp/vsftpd_4096.key -out /etc/ssl/ftp/vsftpd_4096.pem

You will be asked a bunch of questions about location and other stuff. You can more or less put in whatever you like since this is a self signed certificate it will never automatically be trusted by clients anyway so the information is pretty much irrelevant.

Configure FTP (vsftpd)

The My Book Live Duo already have an FTP service that you can enable from the UI. It use vsftpd which supports SSL and TLS, which we want to use for this, as long as OpenSSL is available on the box and apparently it is since we generated the certificates. First we make a copy of the original conf file for save keeping and then open it for editing.

cp /etc/vsftpd.conf /etc/vsftpd.conf.bak
nano /etc/vsftpd.conf

At the end of the file we add:





Then CTRL + O to save and then CTRL + X to exit nano. Then we restart the FTP service.

/etc/init.d/vsftpd restart


Now you can try it from Filezilla, or what ever client software you like that supports ftps. In Filezilla you will get this certificate warning where you can see the additional information you put in when you created the certificate.

Performance - 2048 vs 4096

First run with the configuration above gave me around 8.9MiB/s transfer speeds and the CPU of the Live Book Duo was around 89%. I change the certificates to the 4096bit ones, restart the service and try again. More or less got the same numbers with the higher encryption so the CPU is not the bottleneck for the throughput. At the same time I'm not running any other services besides the SMB shares on this device.

Make backup of the config file

cp /etc/vsftpd.conf* /shares/Backup/

The backup is good to have if a firmware update changes the config file back. I have tried to enable and disable the FTP service and that doesn't effect the configuration at least.


SSL Error: Cannot verify server identity

Phone browsers have less trusted root and intermediate certificates than many desktop browsers. This can make your https site look good on the web but fail on mobile devices. Errors like "unable to verify the identity of the server" and others along those lines can show up. This is because the certification chain  can not be verified. Doesn't matter what supplier of SSL certificates you use they all end up in a few root certificates that are shipped with browsers and operating system as trusted certificates.

Many certificate re-sellers have their root certificates further down that chain than others. If the chain can't be traced back to a trusted certificate the warnings will show up. That will not effect the actual encryption of your website, self signed certificates for example still encrypts the traffic, but it will look bad. People can interpret that as a security risk, like a man in the middle attack, or as just low quality.

In this example I have setup a website on a Apache server with a certificate bought from GoDaddy. I haven't installed the intermediate  certificate. Any desktop browser can follow the chain, since it has a different set of trusted certificates, but the iPhone or Android devices can not since they don't have this certificate. There is a hole in the chain between our website certificate and the trusted one that the device have. By plugging that hole with a valid certificate that our certificate references and in turn references the trusted certificate that the device have we can complete the chain and get rid of the problem.

As mentioned above this example uses a Apache web server running on Linux and a GoDaddy certificate. The procedure will be different with other web servers and certificate suppliers but the principal is the same. When your certificate is delivered always check if there is intermediate certificates included.

So in the zip file that your GoDaddy certificate comes in there is a file named dg_bundle-g2-g1.crt, this is the certificate that your web site certificate is derived from and sits between that and the trusted certificate higher up in the chain.

So on my Apache server I bring up the file /etc/httpd/conf.d/vhost.conf

    ServerAdmin webmaster@somesite.com
    DocumentRoot /var/www/html/somesite.com
    ServerName www.somesite.com
    ServerAlias somesite.com
    ErrorLog logs/somesite.com-error_log
    CustomLog logs/somesite.com-access_log common
    ServerAdmin webmaster@somesite.com
    DocumentRoot /var/www/html/somesite.com
    ServerName www.somesite.com
    ServerAlias somesite.com
    ErrorLog logs/somesite.com_ssl-error_log
    CustomLog logs/somesite.com_ssl-access_log common
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/somesite.com.pem
    SSLCertificateKeyFile /etc/pki/tls/certs/somesite.com.key

As you can see we have two ports open, standard port 80 for http and https on port 443. The 443 have certificate along with it's private key configured. Upload the intermediate certificate to the server and copy it into the same folder (/etc/pki/tls/certs) as the other certificate files. Make sure that the apache server have access to it.

sudo chown -R root:www /var/www

Then add the bundle file in the ssl config in vhost.conf by adding this line just below the SSLCertificateKeyFile line.

SSLCertificateChainFile /etc/pki/tls/certs/gd_bundle-g2-g1.crt

Restart Apache

sudo service httpd restart

Now the certificate chain can be completed on the other devices as well and the error/warning will be gone!


Unable to connect Jetpack – SSL error

Your website needs to be publicly accessible to use Jetpack: site_inaccessible
Error Details: The Jetpack server was unable to communicate with your site https://www.hackviking.com [IXR -32300: transport error: http_request_failed SSL certificate problem: unable to get local issuer certificate]

If you receive the error message above when trying to connect jetpack for you WordPress site there is a small problem with your SSL certificate. This is because the wordpress.com server are unable to verify your SSL certificate chain. Your certificate is signed with an intermediate certificate from your supplier. Your server should supply that intermediate  certificate but if it doesn't your browser already have the mayor intermediate certificates and can solve this issue it self. However wordpress.com can not take care of this if your server doesn't supply the intermediate certificate package.

To solve this you should install the intermediate certificate package supplied by your CA on the server. If you don't have that kind of access to the server there is a work around to get jetpack up and running.

In your wp-config.php find

define('FORCE_SSL_ADMIN', true);

and replace it with

define('FORCE_SSL_ADMIN', false);

Make sure you log in to the /wp-admin without https and then connect jetpack to wordpress.com. Now you can change the FORCE_SSL_ADMIN line back to true and it will all work.