Comment générer une CSR sur FileZilla Server

Ce tutoriel vous montre comment générer une CSR pour FileZilla Server. Commençons par la partie qui vous fera gagner le plus de temps : FileZilla Server ne peut pas créer de demande de signature de certificat. Il n’existe aucun bouton pour cela dans l’interface d’administration, quelle que soit la version. Le serveur peut générer un certificat auto-signé, en récupérer un automatiquement auprès de Let’s Encrypt, ou charger un certificat et une clé privée que vous fournissez vous-même, et c’est cette troisième option qui accueille un certificat émis par une autorité de certification commerciale. La demande est donc construite en dehors de FileZilla Server, avec OpenSSL ou avec un générateur en ligne, et seuls la clé et le certificat finalisés sont transmis au serveur.

Une remarque sur les versions avant d’aborder les commandes, car cela détermine quel terminal vous devez ouvrir. FileZilla Server a été réécrit pour la version 1.0 en septembre 2021, et la version actuelle est la 1.12.6, publiée en mai 2026. Les paquets Debian et macOS sont arrivés avec la version 1.2.0 en décembre 2021 ; avant cela, le serveur ne fonctionnait que sous Windows, et c’est encore là que se trouvent la plupart des installations. Les anciennes instructions commençant par « connectez-vous via SSH » supposent implicitement un hôte Linux. La branche héritée 0.9.x s’est arrêtée à la version 0.9.60.2 en février 2017 et n’a reçu aucune mise à jour de sécurité depuis, donc si vous en êtes encore là, prévoyez la mise à niveau en même temps que le certificat.

Ce que FileZilla Server fait avec les certificats

Il est utile de voir la destination finale avant de construire la demande, car cela indique le format que doivent avoir les fichiers. Ouvrez l’interface d’administration de FileZilla Server, connectez-vous au serveur, puis choisissez Server et Configure… dans la barre de menus (le raccourci clavier est Ctrl+F). Dans l’arborescence à gauche, ouvrez Protocols settings, puis FTP and FTP over TLS (FTPS), puis l’onglet Connection Security.

Cette page contient deux éléments : un menu Minimum allowed TLS version proposant v1.2 et v1.3, et un sélecteur TLS credentials avec trois choix et rien d’autre :

• Provide a X.509 certificate and private key. Deux champs, Certificate et Private key, dont chacun accepte soit des données PEM brutes collées directement dans l’interface, soit un chemin vers un fichier sur le système de fichiers du serveur. Le champ de la clé accepte également une URL PKCS#11 si la clé se trouve sur un jeton matériel. En dessous se trouve Private key password (stored in plaintext). C’est là qu’aboutit un certificat émis par une CA.
• Use a self-signed X.509 certificate. Un bouton Generate new qui crée un certificat que le serveur signe lui-même. Utile pour un test fermé, mais aucun client ne lui fait confiance, donc chaque connexion produit un avertissement.
• Use a Let’s Encrypt® certificate. Prise en charge d’ACME intégrée, ajoutée dans FileZilla Server 1.0. Le serveur demande et renouvelle le certificat lui-même, sans qu’aucune CSR ne soit à gérer de votre côté.

Aucune des trois options ne produit de demande de signature de certificat que vous pourriez envoyer à une autorité de certification. FileZilla Server en construit bien une en interne dans le cadre de l’échange avec Let’s Encrypt, mais elle n’est jamais écrite sur le disque ni affichée dans l’interface, et elle est liée à cette commande automatisée.

Deux détails de cet écran méritent d’être retenus pour la suite. D’abord, les champs de chemin sont résolus sur la machine qui exécute le moteur du serveur, et non sur la machine qui exécute l’interface d’administration, ce qui compte car les deux sont souvent des ordinateurs différents. Ensuite, comme l’interface accepte aussi le certificat et la clé sous forme de texte collé, vous n’êtes pas strictement obligé de copier des fichiers sur le serveur. Dans tous les cas, la clé privée que vous êtes sur le point de créer doit atteindre cette machine d’une manière ou d’une autre, et la générer directement dessus reste le chemin le plus simple.

Générer la CSR pour FileZilla Server

Si vous avez déjà généré votre CSR, passez cette section et allez directement à l’installation de votre certificat SSL sur FileZilla Server une fois le certificat émis. Sinon, choisissez l’une des deux méthodes ci-dessous. Elles produisent la même paire de fichiers.

Option 1 : utiliser le générateur de CSR SSL Dragon

Notre générateur de CSR construit la demande et la clé privée correspondante à partir d’un seul formulaire, ce qui évite d’installer OpenSSL sur un serveur Windows juste pour exécuter une commande. Sauvegardez la clé privée qu’il produit et conservez-la en lieu sûr. Le certificat émis par la CA est inutilisable sans elle, et personne ne peut vous en envoyer une nouvelle copie.

Option 2 : générer la CSR avec OpenSSL

L’endroit où exécuter la commande dépend du système d’exploitation hébergeant FileZilla Server :

• Windows. Ouvrez l’invite de commandes ou PowerShell. Windows ne fournit pas OpenSSL par défaut, il vous en faut donc un : Git for Windows inclut une version accessible dans le path à l’intérieur de Git Bash, vous pouvez aussi installer un paquet OpenSSL autonome pour Windows, ou utiliser le sous-système Windows pour Linux. Quel que soit votre choix, exécutez d’abord openssl version et vérifiez qu’il répond.
• Linux. Ouvrez un terminal sur le serveur, ou connectez-vous via SSH. OpenSSL est installé par défaut sur les distributions courantes.
• macOS. Ouvrez Terminal. La commande openssl sur macOS correspond à une version de LibreSSL plutôt qu’à OpenSSL, ce qui a de l’importance pour certaines options mentionnées plus loin. Chaque commande de ce tutoriel a été testée sur les deux versions et fonctionne sur les deux.

Placez-vous dans un répertoire que vous pourrez retrouver facilement, puis exécutez cette commande unique. Elle crée à la fois la clé privée et la demande :

openssl req -new -newkey rsa:2048 -nodes -keyout ftp.yourdomain.com.key -out ftp.yourdomain.com.csr -addext "subjectAltName=DNS:ftp.yourdomain.com"

Ce que fait chaque partie :

• req -new crée une nouvelle demande de signature de certificat.
• -newkey rsa:2048 génère en même temps une nouvelle clé RSA de 2048 bits. C’est la plus petite taille de clé que les CA publiques accepteront de signer. Utilisez rsa:4096 si votre politique de sécurité l’exige.
• -nodes écrit la clé privée sans phrase de passe, afin que FileZilla Server puisse la lire sans intervention après un redémarrage. Utilisez bien cette orthographe et non le nouvel alias -noenc : OpenSSL 3.x accepte les deux, mais la version LibreSSL fournie par macOS en tant que openssl rejette -noenc et affiche son message d’aide au lieu de s’exécuter.
• -keyout et -out nomment les deux fichiers de sortie. Les nommer d’après l’hôte plutôt que server.key et server.csr est préférable, car dans un an vous en aurez plusieurs.
• -addext "subjectAltName=..." place le nom d’hôte dans l’extension Subject Alternative Name. Ne l’omettez pas. Les Baseline Requirements du CA/Browser Forum décrivent désormais le Common Name comme non recommandé et exigent que toute valeur qui y figure soit dérivée des entrées SAN, c’est donc la liste SAN qui fait foi.

Pour plusieurs noms d’hôte, ou pour un wildcard, étendez la même option avec une liste séparée par des virgules. Répétez le Common Name à l’intérieur :

-addext "subjectAltName=DNS:ftp.yourdomain.com,DNS:files.yourdomain.com"

-addext "subjectAltName=DNS:*.yourdomain.com,DNS:yourdomain.com"

Si vous préférez utiliser une clé à courbe elliptique, la commande équivalente figure ci-dessous. Vérifiez d’abord que votre autorité de certification émet des certificats ECDSA pour le produit que vous achetez, car ce n’est pas le cas de toutes les marques.

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"

Le second -pkeyopt n’est pas une simple décoration. Sur OpenSSL, il ne change rien, car une courbe nommée est déjà la valeur par défaut, mais sur la version LibreSSL fournie avec macOS, son absence fait que la demande décrit la courbe en écrivant l’ensemble de ses paramètres plutôt qu’en la nommant. La RFC 5480 interdit cette forme dans les certificats publics, et une demande construite de cette manière n’identifie aucune courbe du tout.

Répondre aux questions

OpenSSL demande maintenant les informations qui figureront dans la demande, dans cet ordre :

1. Country Name (2 letter code): le code à deux lettres de votre pays, par exemple US. Voici la liste complète des codes pays.
2. State or Province Name (full name): écrit en toutes lettres. California, et non CA.
3. Locality Name (eg, city): le nom complet de la ville, par exemple San Jose.
4. Organization Name (eg, company): le nom légal exact de votre organisation, par exemple Example Holding LLC. Si vous achetez un certificat à validation de domaine, la CA ne vérifie ni n’utilise ce champ, il peut donc être laissé vide.
5. Organizational Unit Name (eg, section): laissez ce champ vide. Depuis le 1er septembre 2022, les Baseline Requirements du CA/Browser Forum indiquent que cet attribut est un de ceux que les CA ne doivent pas inclure, donc tout ce que vous y saisissez est ignoré.
6. Common Name: le nom d’hôte pleinement qualifié auquel se connectent vos clients FTPS, par exemple ftp.yourdomain.com, ou le wildcard *.yourdomain.com. Le libellé de cette question diffère légèrement selon les versions, mais dans la configuration par défaut, il s’agit de la sixième question.
7. Email Address: facultatif, et généralement laissé vide.
8. A challenge password: laissez ce champ vide. C’est un attribut hérité propre à la demande elle-même, il ne figure jamais dans le certificat émis, et les formulaires de commande de certificat ne le demandent pas.
9. An optional company name: laissez également ce champ vide.

Un piège à connaître avant de commencer à saisir des données. « Laisser vide » ne signifie pas « appuyer sur Entrée ». Plusieurs champs portent une valeur par défaut issue du fichier de configuration d’OpenSSL, indiquée entre crochets à la fin de la question, et appuyer sur Entrée accepte cette valeur par défaut au lieu de laisser le champ vide. Sur une configuration OpenSSL standard, appuyer sur Entrée aux premières questions a produit une demande indiquant C=AU, ST=Some-State et O=Internet Widgits Pty Ltd, ce qui n’est pas ce que quiconque souhaite envoyer à une autorité de certification. Pour laisser un champ réellement vide, tapez un simple point puis appuyez sur Entrée. OpenSSL le précise d’ailleurs dans le préambule qu’il affiche juste au-dessus des questions.

Une fois la dernière question répondue, vous obtenez deux nouveaux fichiers dans le répertoire courant :

• ftp.yourdomain.com.csr : la demande de signature de certificat. C’est celle que vous collez dans votre formulaire de commande.
• ftp.yourdomain.com.key : la clé privée. Elle ne va jamais à l’autorité de certification et ne quitte jamais votre contrôle. Quiconque la détient peut usurper l’identité de votre serveur, donc restreignez qui peut la lire et sauvegardez-la quelque part où vous y aurez encore accès dans trois ans. Si vous la perdez, le certificat émis devient inutilisable : il faut générer une nouvelle demande et demander une réémission.

Vérifier la CSR avant de commander

Une faute de frappe dans la demande signifie que la CA émet un certificat que vous ne pourrez pas utiliser, et corriger l’erreur nécessite un nouveau cycle de validation. Relisez la demande avant de la soumettre :

openssl req -noout -text -verify -in ftp.yourdomain.com.csr

Vérifiez trois choses dans le résultat : la ligne Subject contient bien les informations que vous vouliez saisir, la section Subject Alternative Name liste tous les noms d’hôte que les clients utiliseront, et la vérification de signature réussit. OpenSSL 3.x indique ce dernier point par Certificate request self-signature verify OK, tandis que la version LibreSSL sur macOS l’abrège en verify OK. Les deux signifient la même chose. Si vous préférez ne pas travailler en ligne de commande, collez la demande dans notre décodeur de CSR à la place.

Il vaut également la peine de confirmer que la clé présente sur le disque est bien celle à partir de laquelle cette demande a été construite, surtout si vous en avez généré plusieurs. La comparaison des clés publiques fonctionne quel que soit le type de clé, et aussi bien sur OpenSSL que sur LibreSSL :

openssl req -noout -pubkey -in ftp.yourdomain.com.csr
openssl pkey -pubout -in ftp.yourdomain.com.key

Les deux blocs doivent être identiques, caractère pour caractère. Il s’agit de la version portable de la comparaison plus connue par modulus et md5, qui ne fonctionne que pour les clés RSA et signale à tort une paire de clés à courbe elliptique pourtant saine comme non correspondante.

Enfin, ouvrez le fichier .csr dans un éditeur de texte brut tel que Notepad ou TextEdit et copiez tout le bloc, y compris la première et la dernière ligne :

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
... (many lines of base64) ...
-----END CERTIFICATE REQUEST-----

Chaque ligne de marquage est composée d’exactement cinq tirets, des mots, puis de cinq autres tirets. Ne les retapez pas à la main et ne les collez pas via un traitement de texte, qui pourrait convertir des suites de tirets en tirets cadratins et produire une demande que la CA rejettera comme mal formée.

Quand vous n’avez pas du tout besoin de CSR

Depuis la version 1.0, FileZilla Server peut obtenir et renouveler seul un certificat gratuit Let’s Encrypt, sans demande à générer ni fichiers à importer. La même boîte de dialogue des paramètres comporte une page de premier niveau Let’s Encrypt®, sous Logging dans l’arborescence. Cochez Enable Let’s Encrypt® certificate generation, cliquez sur Create new account et acceptez les conditions d’utilisation, puis choisissez sous How to perform the challenges si FileZilla Server doit répondre aux défis avec son propre serveur web interne (il propose le port 80 par défaut) ou si vous allez le pointer vers le dossier qu’un serveur web existant utilise pour répondre aux requêtes sous /.well-known/acme-challenge/. Ensuite, choisissez Use a Let’s Encrypt® certificate dans l’onglet Connection Security et laissez cochée l’option Automatically try to renew the certificate in due time.

Deux limites déterminent si cela est réaliste pour vous. Le serveur ne répond qu’aux défis de validation HTTP, donc le nom d’hôte doit être accessible depuis internet sur le port de défi pendant toute la durée de l’émission du certificat et à chaque renouvellement. Et comme les certificats wildcard de Let’s Encrypt exigent une validation basée sur le DNS, que FileZilla Server n’effectue pas, vous ne pouvez pas obtenir de wildcard de cette manière.

La méthode par CSR décrite plus haut reste donc à privilégier si vous avez besoin d’un wildcard, d’un certificat à validation d’organisation ou à validation étendue, ou d’un certificat pour un serveur qui n’est pas exposé à internet. Nos tutoriels ACME traitent l’émission automatisée plus en détail. L’option restante, le bouton Generate new sous Use a self-signed X.509 certificate, est réservée aux tests : elle permet de faire fonctionner FTPS en quelques secondes, mais fait apparaître chez chaque client un avertissement que les utilisateurs apprennent vite à ignorer.

Questions fréquemment posées