Come generare una CSR su FileZilla Server

Questo tutorial mostra come generare un CSR per FileZilla Server. Iniziamo dalla parte che fa risparmiare più tempo: FileZilla Server non può creare una Certificate Signing Request. Non esiste alcun pulsante per farlo nell’interfaccia di amministrazione, in nessuna versione. Il server può generare un certificato autofirmato, recuperarne uno automaticamente da Let’s Encrypt, oppure caricare un certificato e una chiave privata forniti da voi, ed è in quest’ultima opzione che va inserito un certificato rilasciato da una Certificate Authority commerciale. La richiesta va quindi creata al di fuori di FileZilla Server, con OpenSSL o con un generatore online, e solo la chiave e il certificato finiti vengono consegnati al server.

Una nota sulle versioni prima dei comandi, perché determina quale terminale aprire. FileZilla Server è stato riscritto per la versione 1.0 nel settembre 2021, e la versione attuale è 1.12.6, pubblicata a maggio 2026. I pacchetti per Debian e macOS sono arrivati con la versione 1.2.0 nel dicembre 2021; prima di allora il server funzionava solo su Windows, e Windows è ancora dove risiede la maggior parte delle installazioni. Le istruzioni più datate che iniziano con “accedi via SSH” presuppongono implicitamente un host Linux. Il ramo legacy 0.9.x si è concluso con la versione 0.9.60.2 nel febbraio 2017 e da allora non ha ricevuto aggiornamenti di sicurezza, quindi se lo state ancora usando, pianificate l’aggiornamento insieme al certificato.

Cosa fa FileZilla Server con i certificati

Vale la pena vedere la destinazione prima di costruire la richiesta, perché indica in che formato devono essere i file. Aprite l’interfaccia di amministrazione di FileZilla Server, connettetevi al server, quindi scegliete Server e Configure… dalla barra dei menu (la scorciatoia da tastiera è Ctrl+F). Nell’albero a sinistra, aprite Protocols settings, poi FTP and FTP over TLS (FTPS), quindi la scheda Connection Security.

Quella pagina contiene due cose: un menu Minimum allowed TLS version che offre v1.2 e v1.3, e un selettore TLS credentials con tre opzioni e nient’altro:

• Provide a X.509 certificate and private key. Due campi, Certificate e Private key, ciascuno dei quali accetta sia dati PEM grezzi incollati direttamente nell’interfaccia sia un percorso a un file sul filesystem del server. Il campo della chiave accetta inoltre un URL PKCS#11 se la chiave risiede su un token hardware. Sotto di essi si trova Private key password (stored in plaintext). È qui che finisce un certificato rilasciato da una CA.
• Use a self-signed X.509 certificate. Un pulsante Generate new che crea un certificato che il server firma da solo. Utile per un test chiuso, ma nessun client lo considera attendibile, quindi ogni connessione genera un avviso.
• Use a Let’s Encrypt® certificate. Supporto ACME integrato, aggiunto in FileZilla Server 1.0. Il server richiede e rinnova il certificato da solo, senza alcun CSR da gestire da parte vostra.

Nessuna delle tre opzioni produce una certificate signing request che possiate inviare a una Certificate Authority. FileZilla Server ne costruisce effettivamente una internamente come parte dello scambio con Let’s Encrypt, ma non viene mai scritta su disco né mostrata nell’interfaccia, ed è legata a quell’ordine automatizzato.

Due dettagli di quella schermata vanno tenuti presenti nella sezione successiva. Primo, i campi dei percorsi vengono risolti sulla macchina che esegue il motore del server, non su quella che esegue l’interfaccia di amministrazione, il che conta perché le due sono spesso computer diversi. Secondo, poiché l’interfaccia accetta anche il certificato e la chiave come testo incollato, non è strettamente necessario copiare i file sul server. In ogni caso, la chiave privata che state per creare deve raggiungere in qualche modo quella macchina, e generarla direttamente lì è il percorso più semplice.

Genera il CSR per FileZilla Server

Se avete già generato il vostro CSR, saltate questa sezione e passate direttamente a installare il certificato SSL su FileZilla Server una volta emesso il certificato. Altrimenti, scegliete una delle due strade qui sotto. Producono la stessa coppia di file.

Opzione 1: Usa il CSR Generator di SSL Dragon

Il nostro CSR Generator crea la richiesta e la chiave privata corrispondente da un unico modulo, evitando di dover installare OpenSSL su un server Windows solo per eseguire un comando. Salvate la chiave privata generata e conservatela in un luogo sicuro. Il certificato rilasciato dalla CA è inutile senza di essa, e nessuno può inviarvene una copia sostitutiva.

Opzione 2: Genera il CSR con OpenSSL

Dove eseguire il comando dipende dal sistema operativo che ospita FileZilla Server:

• Windows. Aprite il Prompt dei comandi o PowerShell. Windows non include OpenSSL, quindi ve ne serve uno: Git for Windows include una build disponibile nel path all’interno di Git Bash, oppure potete installare un pacchetto OpenSSL standalone per Windows, oppure usare il Windows Subsystem for Linux. Qualunque scegliate, eseguite prima openssl version e assicuratevi che risponda.
• Linux. Aprite un terminale sul server, oppure connettetevi via SSH. OpenSSL è installato per impostazione predefinita sulle distribuzioni principali.
• macOS. Aprite Terminale. Il comando openssl su macOS è in realtà una build di LibreSSL anziché di OpenSSL, il che conta per un paio di opzioni indicate più avanti. Ogni comando di questo tutorial è stato testato su entrambe le build e funziona su entrambe.

Spostatevi in una directory che riuscirete a ritrovare facilmente, quindi eseguite questo singolo comando. Crea insieme la chiave privata e la richiesta:

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

Cosa fa ogni parte:

• req -new crea una nuova certificate signing request.
• -newkey rsa:2048 genera contemporaneamente una nuova chiave RSA a 2048 bit. È la chiave più piccola che le CA pubbliche accettano di firmare. Usate rsa:4096 se la vostra politica di sicurezza lo richiede.
• -nodes scrive la chiave privata senza passphrase, in modo che FileZilla Server possa leggerla senza intervento dopo un riavvio. Usate questa dicitura e non il più recente alias -noenc: OpenSSL 3.x accetta entrambi, ma la build LibreSSL fornita da macOS come openssl rifiuta -noenc e stampa il messaggio di utilizzo invece di eseguire il comando.
• -keyout e -out nominano i due file di output. Nominarli in base all’host è meglio che chiamarli server.key e server.csr, perché tra un anno ne avrete diversi.
• -addext "subjectAltName=..." inserisce il nome host nell’estensione Subject Alternative Name. Non saltatelo. Le Baseline Requirements del CA/Browser Forum ora descrivono il Common Name come sconsigliato e richiedono che qualsiasi valore in esso sia derivato dalle voci SAN, quindi l’elenco SAN è quello autorevole.

Per più nomi host, o per un wildcard, estendete la stessa opzione con un elenco separato da virgole. Ripetete il Common Name al suo interno:

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

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

Se preferite usare una chiave a curva ellittica, il comando equivalente è qui sotto. Verificate prima che la vostra Certificate Authority emetta certificati ECDSA per il prodotto che state acquistando, poiché non tutti i marchi lo fanno.

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"

Il secondo -pkeyopt non è un dettaglio decorativo. Su OpenSSL non cambia nulla, perché una curva con nome è già l’impostazione predefinita, ma sulla build LibreSSL fornita con macOS la sua assenza fa sì che la richiesta descriva la curva scrivendone tutti i parametri invece di nominarla. La RFC 5480 vieta questa forma nei certificati pubblici, e una richiesta costruita in questo modo non identifica alcuna curva.

Rispondi alle domande

OpenSSL chiede ora i dettagli da inserire nella richiesta, in quest’ordine:

1. Country Name (2 letter code): il codice a due lettere del vostro paese, ad esempio US. Ecco l’elenco completo dei codici paese.
2. State or Province Name (full name): scritto per esteso. California, non CA.
3. Locality Name (eg, city): il nome completo della città, ad esempio San Jose.
4. Organization Name (eg, company): la ragione sociale esatta della vostra organizzazione, ad esempio Example Holding LLC. Se state acquistando un certificato Domain Validation, la CA non verifica né utilizza questo campo, quindi può essere omesso.
5. Organizational Unit Name (eg, section): omettetelo. Dal 1° settembre 2022 le Baseline Requirements del CA/Browser Forum elencano questo attributo tra quelli che le CA non devono includere, quindi qualsiasi cosa digitiate viene scartata.
6. Common Name: il nome host completo (fully qualified) a cui si connettono i vostri client FTPS, ad esempio ftp.yourdomain.com, oppure il wildcard *.yourdomain.com. Il testo di questa domanda varia leggermente tra le diverse build, ma nella configurazione predefinita è la sesta domanda.
7. Email Address: facoltativo, e di norma omesso.
8. A challenge password: omettetelo. È un attributo obsoleto della richiesta stessa, non arriva mai al certificato emesso, e i moduli d’ordine dei certificati non lo richiedono.
9. An optional company name: omettetelo anche questo.

Un tranello da conoscere prima di iniziare a digitare. “Omettetelo” non significa “premete Invio”. Diversi campi hanno un valore predefinito preso dal file di configurazione di OpenSSL, mostrato tra parentesi quadre alla fine della domanda, e premere Invio accetta quel valore predefinito invece di lasciare il campo vuoto. Su una configurazione OpenSSL standard, premere Invio alle prime domande ha prodotto una richiesta che diceva C=AU, ST=Some-State e O=Internet Widgits Pty Ltd, che non è ciò che nessuno vuole inviare a una Certificate Authority. Per lasciare un campo davvero vuoto, digitate un singolo punto e premete Invio. OpenSSL lo dice chiaramente nel testo introduttivo che stampa appena sopra le domande.

Una volta risposto all’ultima domanda, avrete due nuovi file nella directory corrente:

• ftp.yourdomain.com.csr: la certificate signing request. È quella che incollerete nel modulo d’ordine.
• ftp.yourdomain.com.key: la chiave privata. Non va mai alla Certificate Authority e non deve mai uscire dal vostro controllo. Chiunque la possieda può impersonare il vostro server, quindi limitate chi può leggerla e conservatene una copia di backup in un luogo a cui avrete ancora accesso tra tre anni. Se la perdete, il certificato emesso diventa inutilizzabile: dovrete generare una nuova richiesta e chiedere una riemissione.

Verifica il CSR prima di ordinare

Un errore di battitura nella richiesta significa che la CA emette un certificato che non potete usare, e correggerlo costa un altro giro di convalida. Rileggete la richiesta prima di inviarla:

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

Controllate tre cose nell’output: la riga Subject riporta i dettagli che intendevate inserire, la sezione Subject Alternative Name elenca ogni nome host che i client utilizzeranno, e il controllo della firma passa. OpenSSL 3.x riporta quest’ultimo esito come Certificate request self-signature verify OK, mentre la build LibreSSL su macOS lo abbrevia in verify OK. Entrambi significano la stessa cosa. Se preferite non lavorare da riga di comando, incollate la richiesta nel nostro CSR Decoder.

Vale anche la pena confermare che la chiave su disco sia effettivamente quella con cui è stata costruita questa richiesta, specialmente se ne avete generate diverse. Confrontare le chiavi pubbliche funziona con qualsiasi tipo di chiave e sia su OpenSSL che su LibreSSL:

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

I due blocchi devono essere identici, carattere per carattere. Questa è la versione portabile del più noto confronto modulus-e-md5, che funziona solo per chiavi RSA e segnala erroneamente una coppia a curva ellittica sana come non corrispondente.

Infine, aprite il file .csr in un editor di testo semplice come Blocco note o TextEdit e copiate l’intero blocco, comprese la prima e l’ultima riga:

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

Ogni riga marcatore è esattamente cinque trattini, le parole, poi altri cinque trattini. Non ridigitatele a mano e non incollate tramite un elaboratore di testi, che potrebbe convertire le sequenze di trattini in lineette e produrre una richiesta che la CA rifiuta come non valida.

Quando non serve affatto un CSR

Dalla versione 1.0, FileZilla Server può ottenere e rinnovare un certificato Let’s Encrypt gratuito da solo, senza alcuna richiesta da generare e nessun file da importare. La stessa finestra di dialogo delle impostazioni contiene una pagina di primo livello Let’s Encrypt®, sotto Logging nell’albero. Spuntate Enable Let’s Encrypt® certificate generation, cliccate su Create new account e accettate i termini di servizio, quindi scegliete sotto How to perform the challenges se FileZilla Server deve rispondere con il proprio server web interno (propone di default la porta 80) oppure se lo punterete alla cartella che un server web esistente usa per rispondere alle richieste sotto /.well-known/acme-challenge/. Dopodiché, selezionate Use a Let’s Encrypt® certificate nella scheda Connection Security e lasciate spuntata l’opzione Automatically try to renew the certificate in due time.

Due limiti determinano se questo approccio è realistico per voi. Il server risponde solo a sfide di convalida HTTP, quindi il nome host deve essere raggiungibile da internet sulla porta di sfida mentre il certificato viene emesso e ogni volta che si rinnova. E poiché i certificati wildcard di Let’s Encrypt richiedono una convalida basata su DNS, che FileZilla Server non esegue, non è possibile ottenere un wildcard in questo modo.

Il percorso del CSR descritto sopra è quindi ancora quello da seguire se avete bisogno di un wildcard, di un certificato Organization Validation o Extended Validation, oppure di un certificato per un server non esposto a internet. I nostri tutorial ACME trattano l’emissione automatizzata più in dettaglio. L’opzione rimanente, il pulsante Generate new sotto Use a self-signed X.509 certificate, serve solo per i test: consente di avviare FTPS in pochi secondi, ma fa comparire un avviso in ogni client che gli utenti imparano rapidamente a ignorare cliccando oltre.

Domande frequenti