Como Gerar um CSR no FileZilla Server

Este tutorial mostra como gerar um CSR para o FileZilla Server. Comecemos pela parte que poupa mais tempo: o FileZilla Server não consegue criar um Certificate Signing Request. Não existe nenhum botão para isso em lado nenhum da interface de administração, em nenhuma versão. O servidor consegue gerar um certificado autoassinado, obter um automaticamente através do Let’s Encrypt, ou carregar um certificado e uma chave privada que você forneça, e é nesta terceira opção que entra um certificado emitido por uma Autoridade Certificadora comercial. Assim, o pedido é construído fora do FileZilla Server, com OpenSSL ou com um gerador online, e apenas a chave e o certificado finais são entregues ao servidor.

Uma nota sobre versões antes dos comandos, porque isso determina que terminal deve abrir. O FileZilla Server foi reescrito para a versão 1.0 em setembro de 2021, e a versão atual é a 1.12.6, publicada em maio de 2026. Os pacotes para Debian e macOS chegaram com a versão 1.2.0 em dezembro de 2021; antes disso, o servidor funcionava apenas no Windows, e o Windows continua a ser onde vive a maioria das instalações. Instruções mais antigas que começam com “inicie sessão via SSH” pressupõem, tacitamente, um sistema Linux. A linha legada 0.9.x terminou com a versão 0.9.60.2 em fevereiro de 2017 e não recebe atualizações de segurança desde então, por isso, se ainda estiver a usá-la, planeie a atualização em conjunto com o certificado.

O que o FileZilla Server faz com os certificados

Vale a pena ver o destino antes de construir o pedido, porque isso indica que formato os ficheiros precisam de ter. Abra a interface de administração do FileZilla Server, ligue-se ao servidor e escolha Server e Configure… na barra de menus (o atalho de teclado é Ctrl+F). Na árvore à esquerda, abra Protocols settings, depois FTP and FTP over TLS (FTPS), e depois o separador Connection Security.

Essa página contém duas coisas: um menu Minimum allowed TLS version, que oferece v1.2 e v1.3, e um seletor TLS credentials com três opções e nada mais:

• Provide a X.509 certificate and private key. Dois campos, Certificate e Private key, cada um dos quais aceita dados PEM em bruto colados diretamente na interface ou um caminho para um ficheiro no sistema de ficheiros do servidor. O campo da chave aceita ainda um URL PKCS#11 se a chave estiver num token de hardware. Por baixo destes campos encontra-se Private key password (stored in plaintext). É aqui que acaba por entrar um certificado emitido por uma CA.
• Use a self-signed X.509 certificate. Um botão Generate new que cria um certificado assinado pelo próprio servidor. Útil para um teste fechado, mas nenhum cliente confia nele, pelo que todas as ligações produzem um aviso.
• Use a Let’s Encrypt® certificate. Suporte ACME integrado, adicionado no FileZilla Server 1.0. O servidor solicita e renova o certificado por si só, sem qualquer CSR para tratar.

Nenhuma das três opções produz um certificate signing request que possa enviar a uma Autoridade Certificadora. O FileZilla Server chega a construir um internamente como parte da troca com o Let’s Encrypt, mas este nunca é escrito em disco nem mostrado na interface, e está associado a essa encomenda automatizada.

Vale a pena reter dois pormenores deste ecrã para a secção seguinte. Primeiro, os campos de caminho são resolvidos na máquina que executa o motor do servidor, não na máquina que executa a interface de administração, o que é relevante porque muitas vezes se trata de dois computadores diferentes. Segundo, como a interface também aceita o certificado e a chave como texto colado, não é estritamente necessário copiar ficheiros para o servidor. De qualquer forma, a chave privada que está prestes a criar tem de chegar a essa máquina de alguma forma, e gerá-la lá é o caminho mais simples.

Gerar o CSR para o FileZilla Server

Se já gerou o seu CSR, salte esta secção e avance diretamente para instalar o seu certificado SSL no FileZilla Server assim que o certificado for emitido. Caso contrário, escolha uma das duas opções abaixo. Ambas produzem o mesmo par de ficheiros.

Opção 1: Usar o Gerador de CSR da SSL Dragon

O nosso Gerador de CSR cria o pedido e a chave privada correspondente a partir de um único formulário, o que evita ter de instalar o OpenSSL num servidor Windows apenas para executar um comando. Guarde a chave privada gerada e mantenha-a em local seguro. O certificado emitido pela CA não tem qualquer valor sem ela, e ninguém lhe pode enviar uma substituta.

Opção 2: Gerar o CSR com o OpenSSL

Onde executa o comando depende do sistema operativo que aloja o FileZilla Server:

• Windows. Abra o Command Prompt ou o PowerShell. O Windows não inclui o OpenSSL, por isso precisa de instalar um: o Git for Windows inclui uma versão disponível no path dentro do Git Bash, ou pode instalar um pacote independente de OpenSSL para Windows, ou usar o Windows Subsystem for Linux. Seja qual for a opção escolhida, execute primeiro openssl version e certifique-se de que obtém resposta.
• Linux. Abra um terminal no servidor, ou ligue-se via SSH. O OpenSSL vem instalado por predefinição nas distribuições mais comuns.
• macOS. Abra o Terminal. O comando openssl no macOS corresponde, na verdade, a uma compilação do LibreSSL e não do OpenSSL, o que é relevante para algumas opções referidas mais adiante. Todos os comandos deste tutorial foram testados em ambas as compilações e funcionam nas duas.

Mude para uma diretoria que consiga encontrar novamente e execute este único comando. Ele cria a chave privada e o pedido em conjunto:

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

O que faz cada parte:

• req -new cria um novo certificate signing request.
• -newkey rsa:2048 gera, ao mesmo tempo, uma nova chave RSA de 2048 bits. Esse é o menor tamanho de chave que as CAs públicas ainda assinam. Use rsa:4096 se a sua política de segurança o exigir.
• -nodes grava a chave privada sem palavra-passe, para que o FileZilla Server a consiga ler sem intervenção após um reinício. Use exatamente esta grafia e não o alias mais recente -noenc: o OpenSSL 3.x aceita ambos, mas a compilação LibreSSL que o macOS disponibiliza como openssl rejeita -noenc e mostra o bloco de utilização em vez de executar o comando.
• -keyout e -out definem o nome dos dois ficheiros de saída. Nomeá-los a partir do nome do host é preferível a server.key e server.csr, porque daqui a um ano terá vários.
• -addext "subjectAltName=..." coloca o nome do host na extensão Subject Alternative Name. Não a omita. As Baseline Requirements do CA/Browser Forum já descrevem o Common Name como não recomendado e exigem que qualquer valor nele contido derive das entradas SAN, pelo que é a lista SAN que é considerada autoritativa.

Para vários nomes de host, ou para um wildcard, estenda a mesma opção com uma lista separada por vírgulas. Repita o Common Name dentro dela:

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

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

Se preferir usar uma chave de curva elíptica, o comando equivalente encontra-se abaixo. Verifique primeiro se a sua Autoridade Certificadora emite certificados ECDSA para o produto que está a comprar, uma vez que nem todas as marcas o fazem.

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"

O segundo -pkeyopt não é decorativo. No OpenSSL não muda nada, porque uma named curve já é a predefinição, mas na compilação LibreSSL fornecida com o macOS a sua ausência faz com que o pedido descreva a curva escrevendo todos os seus parâmetros em vez de a nomear. A RFC 5480 proíbe essa forma em certificados públicos, e um pedido construído dessa maneira não identifica nenhuma curva.

Responder aos pedidos de informação

O OpenSSL pede agora os dados que constam do pedido, por esta ordem:

1. Country Name (2 letter code): o código de duas letras do seu país, por exemplo PT. Aqui está a lista completa de códigos de país.
2. State or Province Name (full name): escrito por extenso. Lisboa, e não LX.
3. Locality Name (eg, city): o nome completo da cidade, por exemplo Porto.
4. Organization Name (eg, company): a designação legal exata da sua organização, por exemplo Exemplo Holding, Lda. Se estiver a comprar um certificado de Validação de Domínio, a CA não verifica nem utiliza este campo, pelo que pode ser omitido.
5. Organizational Unit Name (eg, section): deixe em branco. Desde 1 de setembro de 2022 que as Baseline Requirements do CA/Browser Forum incluem este atributo entre os que as CAs não devem incluir, pelo que o que escrever será descartado.
6. Common Name: o nome de host totalmente qualificado ao qual os seus clientes FTPS se ligam, por exemplo ftp.seudominio.com, ou o wildcard *.seudominio.com. A formulação deste pedido varia ligeiramente entre compilações, mas na configuração predefinida é a sexta pergunta.
7. Email Address: opcional, e normalmente omitido.
8. A challenge password: deixe em branco. É um atributo legado do próprio pedido, nunca chega ao certificado emitido, e os formulários de encomenda de certificados não o solicitam.
9. An optional company name: deixe também em branco.

Uma armadilha que vale a pena conhecer antes de começar a escrever. “Deixar em branco” não significa “premir Enter”. Vários campos têm um valor predefinido proveniente do ficheiro de configuração do OpenSSL, apresentado entre parênteses retos no final do pedido, e premir Enter aceita essa predefinição em vez de deixar o campo vazio. Numa configuração padrão do OpenSSL, premir Enter nas primeiras perguntas produziu um pedido com C=AU, ST=Some-State e O=Internet Widgits Pty Ltd, o que não é certamente o que se pretende enviar a uma Autoridade Certificadora. Para deixar um campo genuinamente vazio, digite um único ponto final e prima Enter. O próprio OpenSSL o indica no preâmbulo que apresenta mesmo antes das perguntas.

Depois de responder à última pergunta, ficará com dois novos ficheiros na diretoria atual:

• ftp.yourdomain.com.csr: o certificate signing request. É este que cola no seu formulário de encomenda.
• ftp.yourdomain.com.key: a chave privada. Nunca é enviada à Autoridade Certificadora e nunca sai do seu controlo. Quem a detiver pode fazer-se passar pelo seu servidor, por isso restrinja quem a pode ler e faça uma cópia de segurança num local a que ainda tenha acesso daqui a três anos. Se a perder, o certificado emitido torna-se inutilizável: terá de gerar um novo pedido e solicitar uma reemissão.

Verifique o CSR antes de encomendar

Um erro de escrita no pedido significa que a CA emite um certificado que não consegue usar, e corrigi-lo custa uma nova ronda de validação. Releia o pedido antes de o submeter:

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

Verifique três coisas no resultado: a linha Subject contém os dados que pretendia introduzir, a secção Subject Alternative Name lista todos os nomes de host que os clientes irão usar, e a verificação de assinatura é bem-sucedida. O OpenSSL 3.x reporta este último ponto como Certificate request self-signature verify OK, enquanto a compilação LibreSSL no macOS o abrevia para verify OK. Ambos significam o mesmo. Se preferir não trabalhar na linha de comandos, cole o pedido no nosso Descodificador de CSR.

Vale também a pena confirmar que a chave em disco é realmente aquela a partir da qual este pedido foi construído, sobretudo se tiver gerado várias. Comparar as chaves públicas funciona com qualquer tipo de chave e tanto no OpenSSL como no LibreSSL:

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

Os dois blocos têm de ser idênticos, carácter por carácter. Esta é a versão portátil da comparação, mais conhecida, de módulo e md5, que só funciona com chaves RSA e reporta um par de curva elíptica válido como uma discrepância.

Por fim, abra o ficheiro .csr num editor de texto simples, como o Notepad ou o TextEdit, e copie todo o bloco, incluindo a primeira e a última linha:

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

Cada linha de marcação tem exatamente cinco hífenes, as palavras, e depois mais cinco hífenes. Não as volte a escrever manualmente e não as cole através de um processador de texto, que pode converter sequências de hífenes em travessões e produzir um pedido que a CA rejeita como inválido.

Quando não precisa de um CSR de todo

Desde a versão 1.0, o FileZilla Server consegue obter e renovar sozinho um certificado gratuito do Let’s Encrypt, sem qualquer pedido para gerar e sem ficheiros para importar. A mesma caixa de diálogo de definições tem uma página de topo Let’s Encrypt®, abaixo de Logging na árvore. Marque Enable Let’s Encrypt® certificate generation, clique em Create new account e aceite os termos de serviço, depois escolha em How to perform the challenges se o FileZilla Server deve responder-lhes com o seu próprio servidor web interno (propõe a porta 80 por predefinição) ou se pretende apontá-lo para a pasta que um servidor web já existente usa para responder a pedidos em /.well-known/acme-challenge/. Depois disso, escolha Use a Let’s Encrypt® certificate no separador Connection Security e mantenha marcada a opção Automatically try to renew the certificate in due time.

Dois limites determinam se esta opção é realista para si. O servidor apenas responde a desafios de validação HTTP, pelo que o nome de host tem de ser acessível a partir da internet na porta de desafio enquanto o certificado está a ser emitido e sempre que renova. E, uma vez que os certificados wildcard do Let’s Encrypt exigem validação baseada em DNS, que o FileZilla Server não realiza, não é possível obter um wildcard por esta via.

O caminho do CSR acima descrito é, portanto, ainda o indicado se precisar de um certificado wildcard, de Validação de Organização ou de Validação Estendida, ou de um certificado para um servidor que não esteja exposto à internet. Os nossos tutoriais ACME abordam a emissão automatizada com mais profundidade. A opção restante, o botão Generate new em Use a self-signed X.509 certificate, destina-se apenas a testes: coloca o FTPS a funcionar em segundos, e faz com que todos os clientes apresentem um aviso que os utilizadores rapidamente aprendem a ignorar.

Perguntas Frequentes