This tutorial shows you how to generate a CSR for FileZilla Server. Start with the part that saves the most time: FileZilla Server cannot create a Certificate Signing Request. There is no button for it anywhere in the administration interface, in any version. The server can generate a self-signed certificate, fetch one automatically from Let’s Encrypt, or load a certificate and private key that you supply, and that third option is the one a certificate from a commercial Certificate Authority goes into. So the request is built outside FileZilla Server, with OpenSSL or with an online generator, and only the finished key and certificate are handed to the server.
One note on versions before the commands, because it decides which terminal you open. FileZilla Server was rewritten for version 1.0 in September 2021, and the current release is 1.12.6, published in May 2026. Debian and macOS packages arrived with version 1.2.0 in December 2021; before that the server ran on Windows only, and Windows is still where most installations live. Older instructions that begin “log in over SSH” quietly assume a Linux host. The legacy 0.9.x line ended with 0.9.60.2 in February 2017 and has had no security updates since, so if you are still on it, plan the upgrade alongside the certificate.
What FileZilla Server does with certificates
It is worth seeing the destination before you build the request, because it tells you what shape the files need to be in. Open the FileZilla Server administration interface, connect to the server, then choose Server and Configure… from the menu bar (the keyboard shortcut is Ctrl+F). In the tree on the left, open Protocols settings, then FTP and FTP over TLS (FTPS), then the Connection Security tab.
That page holds two things: a Minimum allowed TLS version menu offering v1.2 and v1.3, and a TLS credentials selector with three choices and nothing else:
- Provide a X.509 certificate and private key. Two fields, Certificate and Private key, each of which accepts either raw PEM data pasted straight into the interface or a path to a file on the server’s filesystem. The key field additionally accepts a PKCS#11 URL if the key lives on a hardware token. Below them sits Private key password (stored in plaintext). This is where a CA-issued certificate ends up.
- Use a self-signed X.509 certificate. A Generate new button that creates a certificate the server signs itself. Useful for a closed test, but no client trusts it, so every connection produces a warning.
- Use a Let’s Encrypt® certificate. Built-in ACME support, added in FileZilla Server 1.0. The server requests and renews the certificate itself, with no CSR for you to handle.
None of the three produces a certificate signing request you can send to a Certificate Authority. FileZilla Server does build one internally as part of the Let’s Encrypt exchange, but it is never written to disk or shown in the interface, and it is tied to that automated order.
Two details from that screen are worth carrying into the next section. First, the path fields are resolved on the machine running the server engine, not on the machine running the administration interface, which matters because the two are often different computers. Second, because the interface also accepts the certificate and key as pasted text, you do not strictly have to copy files onto the server at all. Either way, the private key you are about to create has to reach that machine somehow, and generating it there is the simplest route.
Generate the CSR for FileZilla Server
If you already generated your CSR, skip this section and go straight to installing your SSL certificate on FileZilla Server once the certificate is issued. Otherwise, pick one of the two routes below. They produce the same pair of files.
Option 1: Use the SSL Dragon CSR Generator
Our CSR Generator builds the request and the matching private key from a single form, which avoids installing OpenSSL on a Windows server just to run one command. Save the private key it produces and keep it somewhere safe. The certificate the CA issues is worthless without it, and no one can send you a replacement.
Option 2: Generate the CSR with OpenSSL
Where you run the command depends on the operating system hosting FileZilla Server:
- Windows. Open Command Prompt or PowerShell. Windows does not ship OpenSSL, so you need one: Git for Windows includes a build that is on the path inside Git Bash, or you can install a standalone Windows OpenSSL package, or use the Windows Subsystem for Linux. Whichever you choose, run
openssl versionfirst and make sure it answers. - Linux. Open a terminal on the server, or connect over SSH. OpenSSL is installed by default on mainstream distributions.
- macOS. Open Terminal. The
opensslcommand on macOS is a LibreSSL build rather than OpenSSL, which matters for a couple of options noted below. Every command in this tutorial was run on both builds and works on both.
Change into a directory you can find again, then run this single command. It creates the private key and the request together:
openssl req -new -newkey rsa:2048 -nodes -keyout ftp.yourdomain.com.key -out ftp.yourdomain.com.csr -addext "subjectAltName=DNS:ftp.yourdomain.com"
What each part does:
req -newcreates a new certificate signing request.-newkey rsa:2048generates a fresh 2048-bit RSA key at the same time. That is the smallest key public CAs will sign. Usersa:4096if your security policy asks for it.-nodeswrites the private key without a passphrase, so FileZilla Server can read it unattended after a reboot. Use this spelling and not the newer-noencalias: OpenSSL 3.x accepts both, but the LibreSSL build macOS ships asopensslrejects-noencand prints its usage block instead of running.-keyoutand-outname the two output files. Naming them after the host beats server.key and server.csr, because a year from now you will have several.-addext "subjectAltName=..."puts the host name into the Subject Alternative Name extension. Do not skip it. The CA/Browser Forum Baseline Requirements now describe the Common Name as not recommended and require any value in it to be derived from the SAN entries, so the SAN list is the authoritative one.
For several host names, or for a wildcard, extend the same option with a comma-separated list. Repeat the Common Name inside it:
-addext "subjectAltName=DNS:ftp.yourdomain.com,DNS:files.yourdomain.com"
-addext "subjectAltName=DNS:*.yourdomain.com,DNS:yourdomain.com"
If you would rather use an elliptic-curve key, the equivalent command is below. Check first that your Certificate Authority issues ECDSA certificates for the product you are buying, since not every brand does.
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes -keyout ftp.yourdomain.com.key -out ftp.yourdomain.com.csr -addext "subjectAltName=DNS:ftp.yourdomain.com"
The second -pkeyopt is not decoration. On OpenSSL it changes nothing, because a named curve is already the default, but on the LibreSSL build shipped with macOS its absence makes the request describe the curve by writing out all of its parameters instead of naming it. RFC 5480 forbids that form in public certificates, and a request built that way identifies no curve at all.
Answer the prompts
OpenSSL now asks for the details that go into the request, in this order:
- Country Name (2 letter code): the two-letter code for your country, for example US. Here is the full list of country codes.
- State or Province Name (full name): spelled out in full. California, not CA.
- Locality Name (eg, city): the full name of the city, for example San Jose.
- Organization Name (eg, company): the exact legal name of your organization, for example Example Holding LLC. If you are buying a Domain Validation certificate, the CA does not verify or use this field, so it can be left out.
- Organizational Unit Name (eg, section): leave it out. Since 1 September 2022 the CA/Browser Forum Baseline Requirements have listed this attribute as one CAs must not include, so whatever you type is discarded.
- Common Name: the fully qualified host name your FTPS clients connect to, for example ftp.yourdomain.com, or the wildcard *.yourdomain.com. The wording of this prompt differs slightly between builds, but in the default configuration it is the sixth question.
- Email Address: optional, and normally left out.
- A challenge password: leave it out. It is a legacy attribute of the request itself, it never reaches the issued certificate, and certificate order forms do not ask for it.
- An optional company name: leave it out as well.
One trap worth knowing about before you start typing. “Leave it out” does not mean “press Enter”. Several fields carry a default value from OpenSSL’s configuration file, shown in square brackets at the end of the prompt, and pressing Enter accepts that default rather than leaving the field empty. On a stock OpenSSL configuration, pressing Enter through the first few questions produced a request that said C=AU, ST=Some-State and O=Internet Widgits Pty Ltd, which is not what anyone wants sent to a Certificate Authority. To leave a field genuinely blank, type a single period and press Enter. OpenSSL says as much in the preamble it prints just above the questions.
When the last question is answered, you have two new files in the current directory:
- ftp.yourdomain.com.csr: the certificate signing request. This is the one you paste into your order form.
- ftp.yourdomain.com.key: the private key. It never goes to the Certificate Authority and never leaves your control. Anyone holding it can impersonate your server, so restrict who can read it and back it up somewhere you will still have access to in three years. Lose it and the issued certificate becomes unusable: you have to generate a new request and ask for a reissue.
Check the CSR before you order
A typo in the request means the CA issues a certificate you cannot use, and fixing it costs another validation round. Read the request back before you submit it:
openssl req -noout -text -verify -in ftp.yourdomain.com.csr
Check three things in the output: the Subject line carries the details you meant to enter, the Subject Alternative Name section lists every host name clients will use, and the signature check passes. OpenSSL 3.x reports the last one as Certificate request self-signature verify OK, while the LibreSSL build on macOS shortens it to verify OK. Both mean the same thing. If you prefer not to work at the command line, paste the request into our CSR Decoder instead.
It is also worth confirming that the key on disk really is the one this request was built from, especially if you generated several. Comparing the public keys works on any key type and on both OpenSSL and LibreSSL:
openssl req -noout -pubkey -in ftp.yourdomain.com.csr
openssl pkey -pubout -in ftp.yourdomain.com.key
The two blocks must be identical, character for character. This is the portable version of the more familiar modulus-and-md5 comparison, which only works for RSA keys and reports a healthy elliptic-curve pair as a mismatch.
Finally, open the .csr file in a plain text editor such as Notepad or TextEdit and copy the whole block, including the first and last lines:
-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
... (many lines of base64) ...
-----END CERTIFICATE REQUEST-----
Each marker line is exactly five hyphens, the words, then five more hyphens. Do not retype them by hand and do not paste through a word processor, which may convert runs of hyphens into dashes and produce a request the CA rejects as malformed.
When you do not need a CSR at all
Since version 1.0, FileZilla Server can obtain and renew a free Let’s Encrypt certificate on its own, with no request for you to generate and no files to import. The same settings dialog carries a top-level Let’s Encrypt® page, below Logging in the tree. Tick Enable Let’s Encrypt® certificate generation, click Create new account and accept the terms of service, then choose under How to perform the challenges whether FileZilla Server should answer them with its own internal web server (it proposes port 80 by default) or whether you will point it at the folder an existing web server uses to answer requests under /.well-known/acme-challenge/. After that, pick Use a Let’s Encrypt® certificate on the Connection Security tab and leave Automatically try to renew the certificate in due time ticked.
Two limits decide whether this is realistic for you. The server answers HTTP validation challenges only, so the host name has to be reachable from the internet on the challenge port while the certificate is being issued and every time it renews. And because wildcard certificates from Let’s Encrypt require DNS-based validation, which FileZilla Server does not perform, you cannot get a wildcard this way.
The CSR route above is therefore still the one to take if you need a wildcard, an Organization Validation or Extended Validation certificate, or a certificate for a server that is not exposed to the internet. Our ACME tutorials cover automated issuance in more depth. The remaining option, the Generate new button under Use a self-signed X.509 certificate, is for testing only: it gets FTPS running in seconds, and it makes every client display a warning that users quickly learn to click past.
Frequently Asked Questions
No. The administration interface offers three ways to give the server a certificate, and none of them produces a request you can send to a Certificate Authority: provide a certificate and private key you already have, generate a self-signed certificate, or obtain one automatically from Let’s Encrypt. Generate the CSR with OpenSSL or with our CSR Generator, then load the resulting key and the issued certificate through the first of those three options.
Run this on the machine hosting FileZilla Server, replacing the host name with your own:openssl req -new -newkey rsa:2048 -nodes -keyout ftp.yourdomain.com.key -out ftp.yourdomain.com.csr -addext "subjectAltName=DNS:ftp.yourdomain.com"
It writes the request and the private key side by side and then asks for your organization details.
In Command Prompt, PowerShell or Git Bash on the server itself. Windows has no built-in OpenSSL, so install one first: Git for Windows bundles a suitable build, and standalone Windows packages exist too. Run openssl version to confirm the command is available before you continue. Instructions that tell you to connect over SSH assume a Linux host, which FileZilla Server has only supported since version 1.2.0.
No. A .pfx or .p12 bundle already contains a certificate and its private key, so there is nothing left to request. It is in the wrong container, though: FileZilla Server’s certificate and key fields are documented as PEM, and the paste box is labelled as expecting PEM. Split the bundle into the two PEM files the server asks for, entering the bundle’s password when prompted:openssl pkcs12 -in bundle.pfx -nokeys -out certificate.pemopenssl pkcs12 -in bundle.pfx -nocerts -nodes -out privatekey.pem
Both files come out with a few Bag Attributes lines above each block, which are harmless and can be left in place or deleted.
No. Creating a request only writes two files on disk and changes nothing the server is doing. FileZilla Server does not know the request exists until you load the issued certificate, and it applies that from the Connection Security tab without a reinstall.
The request itself is identical, because you build it with OpenSSL either way. What changed is where the finished files go. The 0.9.x administration interface put the certificate settings under Edit and Settings, while 1.x uses Server, Configure… and the Connection Security tab described above. The 0.9.x line last saw a release in February 2017 and receives no security updates, so treat any work on it as temporary.
Save 10% on SSL Certificates when ordering from SSL Dragon today!
Fast issuance, strong encryption, 99.99% browser trust, dedicated support, and 25-day money-back guarantee. Coupon code: SAVE10


