Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS) file transfers are two of the most user-friendly methods for carrying out user-initiated file uploads and downloads. Users only need a web browser like Chrome, Firefox, Microsoft Edge or Safari to perform these actions. In a previous tutorial, we outlined the steps for setting up an HTTP file transfer. So, in this post, we’ll focus more on HTTPS.
Why set up an HTTPS file transfer?
When introducing a technical solution into your organization to meet a business need, it’s important to consider the solution’s usability and manageability. You want your users to be onboarded as seamlessly as possible. At the same time, you don’t want your IT teams to be overburdened by that new technology. An HTTPS file transfer solution fulfills both objectives while also meeting the need for secure, user-initiated data transfers.
HTTPS has all the functionality of HTTP but with added security. That means HTTPS is also capable of supporting various user-initiated file transfer and file sharing activities, multiple concurrent file transfers, and small or large file transfers.
The front end of an HTTPS file transfer solution is essentially a webpage. Thus, you can load it using any web browser. Since this solution is browser-based, users don’t have to install additional software to upload, download or share files. They can simply use the browser that’s pre-installed on their device’s operating system.
Would you prefer to observe an expert demonstrate the HTTPS file transfer set up process? Book a quick demo now.
Given that virtually all users are familiar with web browsers, your users won’t encounter the same level of difficulty associated with other file transfer solutions like File Transfer Protocol (FTP) and Secure File Transfer Protocol (SFTP). Those solutions require specialized standalone client software that need to be installed separately. Not only do these qualities simplify user onboarding, but they also reduce your IT team’s software deployment, management and maintenance responsibilities.
Although HTTPS has the same file transfer capabilities as HTTP, it has one major advantage. HTTPS is substantially more secure. In fact, one can argue that HTTP isn’t secure at all. If your business handles sensitive data, the presence of security features in HTTPS is a key reason why you should consider using it for your file transfers.
Recommended reads:
What is an SFTP client & how do I use one?
How HTTPS enables secure file transfers
HTTPS derives its security capabilities from Secure Sockets Layer/Transport Layer Security (SSL/TLS), a family of cryptographic protocols designed to establish secure connections in otherwise untrusted networks.
SSL/TLS provides the following security capabilities through cryptographic algorithms:
- Client and host authentication via digital certificates
- Data-in-transit encryption through a combination of symmetric and asymmetric encryption
- Data integrity checks through hashing
I encourage you to open those links on separate tabs if you’re not familiar with the terms mentioned above. You can read those later. In the meantime, let’s proceed with the tutorial.
For this tutorial, we’ll be using JSCAPE MFT Server by Redwood. JSCAPE MFT Server is a managed file transfer solution that supports multiple secure file transfer protocols, including HTTPS. While JSCAPE MFT Server makes it easy to set up an HTTPS file transfer service that allows users to manually upload and download files from a web browser, it also comes with a low-code/no-code automation platform.
This platform enables you to build automated file transfer workflows for:
- Fully-automated server-to-server file transfers
- Time or event-driven trigger actions
- Email notifications about relevant server events
- And many others
JSCAPE MFT Server can be installed on all major operating systems, including Microsoft Windows, Linux, macOS, UNIX, Solaris and AIX.
Note: The HTTPS protocol is defined in RFC 2818, so if you want a more technical discussion on HTTPS, you may read that.
I suggest you browse through the steps below first, just to see how easy and effortless the entire process can be. Then if you decide to try it out yourself, you can request a free trial.
Or, if you want an expert to demo the set up process for you, request a demo.
Alright, here are the steps to setting up an HTTPS file transfer using JSCAPE MFT Server. I’m assuming you already have a JSCAPE MFT Server instance up and running.
1. Enable the HTTPS file transfer service
JSCAPE MFT Server uses a web-based administrative interface. So you can simply launch your favorite web browser and enter your server’s listening IP address/hostname and port number. Once you’re logged-in, click the Settings menu at the top of the screen.
Expand the MISCELLANEOUS drop-down menu in the left sidebar and then click Web > Web tab. Tick the “HTTPS on host” checkbox to enable the HTTPS service. As soon as you do that, JSCAPE MFT will automatically assign 0.0.0.0 as the listening IP address and port 443 as the listening port for the HTTPS service. A 0.0.0.0 IP assignment means the server will be listening for HTTPS requests on all available network interfaces. 443 is the default port number for HTTPS.
Since you’ll want your users to connect to your HTTPS service even if they don’t specify the HTTPS protocol on their web browser, scroll down a bit and then tick the “Redirect HTTP requests on HTTPS” checkbox.
Let’s leave the other settings as is for now, but don’t forget to click the Apply button at the bottom-right corner of the screen to apply your recent changes.
At this point, the HTTPS service should already be enabled on your server. However, you’re not yet done. You still have to specify the domain(s) you want the service to be available on. You might have some domains that don’t require the HTTPS service, so you don’t need to add the HTTPS service to those domains.
2. Add the HTTPS service to a domain
To add the HTTPS service to a domain, expand the Domains drop-down menu at the top of the screen and then click View domains.
Double-click the domain you wish to add the HTTPS service to.
Once the chosen domain’s webpage loads up, expand the SERVICES drop-down menu in the left sidebar and then click the Listeners submenu. Next, click the Add button at the lower-right corner of the page.
Once the Service Protocol dialog box appears, expand the Protocol drop-down list and then select “HTTP/S”. Click OK to proceed.
The HTTPS checkbox should already be selected by default, so you don’t need to do anything. If somehow it’s not selected, select it. Click OK to proceed.
You should then see the newly added HTTPS listener under the Listeners tab.
Since you’ll need a user account to test your HTTPS service, verify that you already have an existing user account by navigating to ACCOUNTS > USERS. In our example, we already have a user account with the user ID “user1’.
We’re now ready to test our newly activated HTTP file transfer service.
3. Test HTTPS file server download or upload
Since we just want to test if the HTTPS service works as expected, I suggest you just use a web browser installed on the same system where your JSCAPE MFT Server instance is running on. That way, you can minimize unforeseen circumstances. Of course, if your JSCAPE MFT Server instance is running on a headless server, you’ll have to connect remotely.
Launch your web browser and enter your MFT server’s IP address/hostname and port number on the URL box. If you’re doing this on the same system, you can simply replace the IP address with “localhost”.
Since your HTTPS service is still using a self-signed certificate, you should see a warning that looks like this:
That’s perfectly fine. Self-signed certificates are safe to use in a testing environment. Just click the Advanced button (or any equivalent link, which depends on your browser of choice) shown in the screenshot above to proceed. If you have to click another link to proceed further, please do so.
You should then see your HTTPS service’s login screen. Enter the domain you picked earlier, the username of an existing user account and the corresponding password of that user account. Click the LOGIN button to logon.
If everything goes well, you should see a graphical web user interface that resembles the one below. You can perform several file transfer-related tasks here. For instance, aside from uploading and downloading files, you can also create a new directory, rename a file’s filename, delete a file, perform a zipped download, change your current directory, view your account details and so on. For now, let’s just test a file upload. To do that, click the Upload button.
Select the file you wish to upload, and then click the Open button.
As soon as the upload completes, you should see the uploaded file in your current directory.
At this point, you would have already configured a basic HTTPS file transfer service, which you can run tests with in a controlled environment. That being said, this basic setup isn’t suited for a production environment yet. For that, we need to go over the succeeding sections.
4. Replace the default server key
During our initial set up earlier, particularly the part where we first enabled the HTTPS service on our JSCAPE MFT instance, we encountered a screen that showed a drop-down list labeled “Private key”. In the drop-down list beside it, you should have seen a selected item named example_rsa. This particular private key is only intended for testing purposes. You shouldn’t use it in a production environment.
Each private key in that drop-down list is representative of what’s known as a server key. In the context of JSCAPE MFT, a server key is a cryptographic artifact that consists of three (3) elements: a private key, a digital certificate and a public key. Here's how these three elements come into play.
When an end user's Web browser first connects to your server via HTTPS, your server looks up which private key/server key was assigned for the service and then sends a copy of the corresponding digital certificate, along with the corresponding public key, back to the browser.
The digital certificate functions as your server's credentials. It enables the user's browser to determine whether your HTTPS file server can be trusted. In order for the browser to trust your server's digital certificate, the certificate should bear a Certificate Authority's (CA's) digital signature.
Theoretically speaking, a CA is a reputable entity that’s supposed to verify whether the certificate holder actually owns the domain or service in question. The CA’s digital signature is an attestation that the CA has already completed the verification process and that the certificate holder can be trusted.
Without that CA signature, the browser would alert the user like so, which explains why you also see this alert if you use a self-signed certificate.
The end user may disregard that warning and proceed to log on to your server, but at least an appropriate warning has already been displayed.
As for the public and private keys, these cryptographic elements are used to encrypt and decrypt sensitive information that are exchanged during what is known as the SSL handshake. The SSL handshake is the procedure at the start of an HTTPS file transfer session wherein a web browser and the HTTPS server agree on which set of algorithms (collectively known as cipher suites) are to be used during the session.
An SSL handshake culminates with the creation of a session key, a symmetric key used for encrypting whatever files are uploaded and downloaded during the HTTPS file transfer session.
Here's what you must do to replace the default server key, i.e., example_rsa.
In your JSCAPE MFT administrative web interface, click the Keys menu at the top of the screen, and then click the Generate button in the lower-left corner of the screen.
When the Generate Server Key dialog appears, enter a key alias. You’ll use this alias to identify this particular server key in your JSCAPE MFT environment.
You’ll also need to select your desired:
- Key algorithm: The algorithm used in generating this key. Valid options are Rivest-Shamir-Adleman(RSA), Digital Signature Algorithm (DSA), Elliptic Curve (EC) and Edwards Curve (ED).
- Key length: The length of the key in bytes. The length options depend on the chosen algorithm. For instance, valid options for RSA include 1024, 2048, 3072 and 4096. Although longer key lengths naturally translate to stronger encryption, they can also be more computationally demanding. Read the article "Choosing Key Lengths for Encrypted File Transfers" for more details on this matter. Note, for key lengths greater than 1024, you must install the JCE Unlimited Jurisdiction Policy Files.
In the Parameters tab, specify the following:
- Validity: The number of days this key is supposed to be valid.
- Common name (CN): The name you wish to assign this key. Typically the domain name this key will serve.
- Note: Some browsers have already deprecated the CN and recognize the Subject Alternative Name (SAN) instead.
- Subject Name Alternative or Subject Alternative Name (SAN): This host's domain name or, if you're generating this key for a multi-domain certificate, a comma-separated list of domains
- Organizational unit: The unit within your organization that this key will be used for e.g. IT.
- Organization: Your organization name.
- Locality: Your city.
- State/Province: Your state or province.
- Country: Your two character country code e.g. "US".
When you’re done, click OK to apply the changes.
You should then see your newly created server key under the Server Keys tab.
In order for that server key's corresponding certificate to be trusted by your end user's browsers, you would have to submit a Certificate Signing Request (CSR) for this particular server key to a Certificate Authority. This particular process is beyond the scope of this article, but you can find more details in our documentation for obtaining a trusted certificate.
Once your private key has been signed by the CA, you can then import it. Read the documentation for importing third-party certificates for details. Please pay attention to the "Note" on that page. Many future issues can be avoided by carefully following those instructions.
After importing, go back to Settings > MISCELLANEOUS > Web > Web tab, and then, in the HTTPS panel, select the alias of the newly imported private key. When you're done, click the Apply button at the bottom-right corner of that page.
5. (Advanced step) Select SSL/TLS cipher suites
Earlier, when we briefly touched on a process known as the "SSL Handshake", we mentioned the term "cipher suites". Let me now explain what they're for and how to configure them on JSCAPE MFT.
A cipher suite typically consists of four algorithms:
- An algorithm for key exchanges;
- An algorithm for implementing authentication;
- An algorithm for establishing confidentiality; and
- An algorithm for establishing data integrity
Here's an example of a cipher suite:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Here,
- ECDHE, which stands for Elliptic Curve Diffie-Hellman Ephemeral, is the algorithm for exchanging keys;
- ECDSA, which stands for Elliptic Curve Digital Signature Algorithm, is the algorithm for implementing authentication;
- AES_128 is the symmetric encryption key algorithm and is used for establishing confidentiality; and
- SHA256 is the secure hashing algorithm used for establishing data integrity
Before any HTTPS file transfer can occur, your end user's web browser and your secure web server must agree on a common set of algorithms. Basically, as soon as the browser first connects via what is known as a "Client Hello", it immediately informs your server which cipher suites it supports. Your server then checks which of those cipher suites are enabled on its side and chooses the most secure.
So, really, if you want to optimize your server for maximum interoperability, i.e., you want to make sure your server can serve as many types and versions (including legacy) of web browsers as possible, then you need to enable all supported cipher suites on your server. On the other hand, if you want to optimize for maximum security, then you'll have to restrict your HTTPS file transfers to only the most secure cipher suites.
To enable or disable SSL/TLS cipher suites, again go back into Settings > MISCELLANEOUS > Web > Web tab and click the SSL/TLS ciphers button.
You may then start selecting the SSL/TLS cipher suites you want to enable or disable for your HTTPS file transfers. Once you’re done, click the OK button.
That finally concludes our detailed tutorial. Now that you know how to set up an HTTPS file transfer using JSCAPE MFT, would you like to try this out yourself?
If so, you may request a free trial.
On the other hand, if you prefer an expert to demo the set up process for you,
FAQ
HTTPS vs. FTP: Which is better?
File Transfer Protocol (FTP) used to be the go-to solution for user-initiated file transfers. However, although both FTP servers and HTTPS servers can support those types of file transfers, HTTPS servers or secure web servers are substantially better. There are three major reasons for that:
- HTTPS file transfers only require a web browser on the client side
- HTTPS supports several security features, whereas FTP doesn’t have any
- HTTPS only uses one port number, port 443, and doesn’t operate in multiple modes the way FTP does. From a firewall configuration standpoint, HTTPS is much easier to handle
HTTPS vs. SFTP: Which is better?
SFTP, which also stands for SSH (Secure Shell) File Transfer Protocol, is another secure file transfer protocol (pun unintended). Like HTTPS connections, SFTP connections are also protected with data-in-transit encryption. And, like HTTPS, SFTP supports client and server authentication. It also performs data integrity checks. So, from a security standpoint, they’re quite equally matched.
In terms of firewall compatibility, they’re also equal. That’s because, like HTTPS, SFTP only uses one port number (22) and it doesn’t have the dual-mode and multi-port complexity of FTP.
SFTP has one disadvantage though. Unlike HTTPS, which only requires a web browser on the client side, SFTP requires dedicated file transfer clients. Meaning, users would have to install a separate piece of software to connect to an SFTP server.
That being said, SFTP is more suited for server-to-server file transfers compared to HTTPS. So, all in all, I would say they both have strong qualities. So, choosing one over the other would largely depend on your specific use case.