Configuring SSL/TLS security for the Web/REST Service

While SSL/TLS security configuration for the FTPS protocol is entirely self-contained, Server!’s Web/REST service relies on Windows’ HTTP.SYS subsystem, which is the same subsystem IIS is based on, and therefore its security configuration has to be made at operating system level.

In order to ease the process we recommend Natarc’s IISCrypto, a free and powerful utility that helps achieving the task with just a few mouse clicks. Continue reading

HTTPS “connection not private/secure” – what it is? Server! version: 4.0.0+

After installing Server! v4.0 you will be able to manage it securely via web interface over HTTPS.

Now, a very common choice is to use a self-signed certificate, because it saves money and if you know what you’re doing it doesn’t compromise security. This is, in fact, the most common choice among our users (according to our surveys).

But if you use a self-signed certificate, your browser will warn you that your connection may not be private or secure. That’s because self-signed certificates are often used for man-in-the-middle (MitM) attacks. But this is not the case, of course, if you can verify that this particular self-signed certificate was created by you and for you.

To get rid of this annoying message, you basically have 2 options:

  1. Spend some money to buy a trusted X.509 (SSL/TLS) certificate from a Certification Authority like DigiCert, Comodo, Thawte, and the like. It goes without saying that this is the recommended choice, as it takes advantage of the inherent trust chain provided by the Certification Authority.
  2. Verify and accept the self-signed certificate you have just created and add it to the trusted keychain of your browser. In this case you are advised to always verify the certificate’s fingerprint to make sure it’s really the one you created yourself, and that you’re not a victim of a Man-in-the-Middle (MitM) attack.

Continue reading

Can I run Server!’s HTTP REST API on port 443? Server! version: 4.0.0+

During the installation process of Server! v4.x (or greater) you will be asked the IP address and port to which the new HTTP REST API service should bind. While in most cases (all interfaces) is a safe choice for the IP address, it is important to carefully choose a port.

In order to help you choose, we have prepared a very easy diagram. Just answer the questions on the diagram, and you’ll know which port (not) to use.

HTTPS Port Choice

This said, in order to limit automatic probes (bots), choosing a non-standard port is probably always the safest way to go. Server!: No worries about POODLE SSLv3 bug.

By now, everyone has heard about the POODLE bug, that’s scaring every system administrator these days.

Unfortunately it is a design flaw in SSLv3, therefore the only thing you can do to go around it is to disable SSLv3 from all your servers (whatever they are, IIS, Apache, …, all SSL-capable servers).

Fortunately Server! has – by design – a very easy way to do that. As shown in the picture below, just make sure the SSLv3 option is unchecked, and save your configuration. There you go, you’re safe now.


FTPS Server Certificate: best practices

Upon installation, Server! auto-generates a self-signed X.509 (SSL/TLS) Server Certificate to be used for implicit and explicit FTP (aka FTPS and FTPES). However, such certificate carries the name of “Syncplify” in the organization field, and the common name (CN) field is only suitable for localhost ( Therefore you may want to generate your own certificate, or buy one from a trusted Certification Authority (CA).

If a self-signed certificate is enough for you (and for all clients that will connect to your server), then you can simply use Server!’s internal certificate generator as follows. Simply click the “gear” button on the FTP(S) tab of the Configuration manager. Continue reading

SSH Server Key ≠ FTPS (SSL/TLS) Server Certificate

From time to time our users ask how to use their X.509 (SSL/TLS) certificate for SFTP.

The one-line answer is: it’s not possible. But let’s dig into the topic and explain why, and above all how to implement server certificate and keys correctly.

First of all it is important to identify which protocol we intend to use, and what are its peculiarities: Continue reading Server! v2.0.7.27 hot-fix 1

If you have downloaded and installed Server! v2.0.7.27 in the past 6 days, and are experiencing problems with the X.509 certificate on your FTPS (or FTPES) connections, please download v2.0.7.27-hotfix-1 from our web site, and update your instance.

This is a pure hot-fix release, nothing else has been changed, no improvements were made, and no features were altered. Therefore, if you are not experiencing any trouble, you won’t need this update. Thank you.

Issues connecting to Server! using FileZilla Client?

Seems like recent updates to the FileZilla Client have created some issues regarding secure (SSL and TLS) connections to Server!

First of all we would like to inform our users that the issue is not caused by Server!, in fact it is very well documented in two bug-reports of the FileZilla project (# 7873 and #9441) and it affects secure connections to several other servers, not just ours.

Anyhow… until a fixed version of the FileZilla Client is made available, we do recommend to download and use their version, which is the latest stable version before they broke compatibility. You can download it from SourceForge here.

OpenSSL bug: our customers are safe (cause we don’t use it)!

heartbleedBreaking news: a terrifying (to say the least) bug in OpenSSL has been discovered and publicly disclosed. This serious security flaw affects OpenSSL’s heartbeat feature, and it’s therefore been named “heartbleed”.

We, at Syncplify, want to reassure all of our users and customers: none of our products uses or has ever used OpenSSL or any of its components. Server!, FTP!, and FTP Scrip!, all include a SSL/TLS stack that is not based on OpenSSL, and therefore is not affected by the recently discovered bug.

Once again, users of Syncplify software products are safe.