Cómo generar un CSR en FileZilla Server

Este tutorial te muestra cómo generar un CSR para FileZilla Server. Empecemos por la parte que ahorra más tiempo: FileZilla Server no puede crear una Solicitud de Firma de Certificado. No hay ningún botón para eso en ninguna parte de la interfaz de administración, en ninguna versión. El servidor puede generar un certificado autofirmado, obtener uno automáticamente de Let’s Encrypt, o cargar un certificado y una clave privada que tú proporciones, y esa tercera opción es en la que entra un certificado de una Autoridad de Certificación comercial. Así que la solicitud se construye fuera de FileZilla Server, con OpenSSL o con un generador en línea, y solo la clave y el certificado terminados se entregan al servidor.

Una nota sobre versiones antes de los comandos, porque decide qué terminal abrir. FileZilla Server fue reescrito para la versión 1.0 en septiembre de 2021, y la versión actual es 1.12.6, publicada en mayo de 2026. Los paquetes de Debian y macOS llegaron con la versión 1.2.0 en diciembre de 2021; antes de eso el servidor solo funcionaba en Windows, y Windows sigue siendo donde vive la mayoría de las instalaciones. Las instrucciones antiguas que comienzan con «inicia sesión por SSH» asumen tácitamente un host Linux. La línea heredada 0.9.x terminó con la versión 0.9.60.2 en febrero de 2017 y no ha recibido actualizaciones de seguridad desde entonces, así que si todavía la usas, planifica la actualización junto con el certificado.

Qué hace FileZilla Server con los certificados

Vale la pena ver el destino antes de construir la solicitud, porque eso indica qué forma deben tener los archivos. Abre la interfaz de administración de FileZilla Server, conéctate al servidor, y luego elige Server y Configure… en la barra de menú (el atajo de teclado es Ctrl+F). En el árbol de la izquierda, abre Protocols settings, luego FTP and FTP over TLS (FTPS), y luego la pestaña Connection Security.

Esa página contiene dos cosas: un menú Minimum allowed TLS version que ofrece v1.2 y v1.3, y un selector TLS credentials con tres opciones y nada más:

• Provide a X.509 certificate and private key. Dos campos, Certificate y Private key, cada uno de los cuales acepta datos PEM en bruto pegados directamente en la interfaz o una ruta a un archivo en el sistema de archivos del servidor. El campo de la clave además acepta una URL PKCS#11 si la clave reside en un token de hardware. Debajo de ellos está Private key password (stored in plaintext). Aquí es donde termina un certificado emitido por una CA.
• Use a self-signed X.509 certificate. Un botón Generate new que crea un certificado que el servidor firma él mismo. Útil para una prueba cerrada, pero ningún cliente confía en él, así que cada conexión produce una advertencia.
• Use a Let’s Encrypt® certificate. Soporte ACME integrado, añadido en FileZilla Server 1.0. El servidor solicita y renueva el certificado por sí mismo, sin ningún CSR que tengas que manejar.

Ninguna de las tres opciones produce una solicitud de firma de certificado que puedas enviar a una Autoridad de Certificación. FileZilla Server sí construye una internamente como parte del intercambio con Let’s Encrypt, pero nunca se escribe en disco ni se muestra en la interfaz, y está ligada a ese pedido automatizado.

Dos detalles de esa pantalla vale la pena llevar a la siguiente sección. Primero, los campos de ruta se resuelven en la máquina que ejecuta el motor del servidor, no en la máquina que ejecuta la interfaz de administración, lo cual importa porque a menudo son equipos diferentes. Segundo, como la interfaz también acepta el certificado y la clave como texto pegado, no tienes estrictamente que copiar archivos al servidor. De cualquier forma, la clave privada que estás a punto de crear tiene que llegar a esa máquina de alguna manera, y generarla allí es la ruta más simple.

Genera el CSR para FileZilla Server

Si ya generaste tu CSR, salta esta sección y ve directamente a instalar tu certificado SSL en FileZilla Server una vez que el certificado esté emitido. De lo contrario, elige una de las dos rutas siguientes. Ambas producen el mismo par de archivos.

Opción 1: Usar el Generador de CSR de SSL Dragon

Nuestro Generador de CSR construye la solicitud y la clave privada correspondiente a partir de un solo formulario, lo que evita instalar OpenSSL en un servidor Windows solo para ejecutar un comando. Guarda la clave privada que produce y consérvala en un lugar seguro. El certificado que emite la CA no vale nada sin ella, y nadie puede enviarte un reemplazo.

Opción 2: Generar el CSR con OpenSSL

Dónde ejecutas el comando depende del sistema operativo que hospeda FileZilla Server:

• Windows. Abre el Símbolo del sistema o PowerShell. Windows no incluye OpenSSL de fábrica, así que necesitas uno: Git for Windows incluye una compilación que está en el PATH dentro de Git Bash, o puedes instalar un paquete independiente de OpenSSL para Windows, o usar el Subsistema de Windows para Linux. Cualquiera que elijas, ejecuta primero openssl version y asegúrate de que responda.
• Linux. Abre una terminal en el servidor, o conéctate por SSH. OpenSSL viene instalado por defecto en las distribuciones principales.
• macOS. Abre Terminal. El comando openssl en macOS es una compilación de LibreSSL en lugar de OpenSSL, lo cual importa para un par de opciones señaladas más abajo. Cada comando de este tutorial se ejecutó en ambas compilaciones y funciona en las dos.

Muévete a un directorio que puedas volver a encontrar, y luego ejecuta este único comando. Crea la clave privada y la solicitud juntas:

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

Qué hace cada parte:

• req -new crea una nueva solicitud de firma de certificado.
• -newkey rsa:2048 genera al mismo tiempo una nueva clave RSA de 2048 bits. Ese es el tamaño de clave más pequeño que las CA públicas firmarán. Usa rsa:4096 si tu política de seguridad lo exige.
• -nodes escribe la clave privada sin frase de contraseña, para que FileZilla Server pueda leerla sin intervención después de un reinicio. Usa esta forma de escritura y no el alias más nuevo -noenc: OpenSSL 3.x acepta ambos, pero la compilación de LibreSSL que macOS distribuye como openssl rechaza -noenc e imprime su bloque de uso en lugar de ejecutarse.
• -keyout y -out nombran los dos archivos de salida. Nombrarlos según el host es mejor que server.key y server.csr, porque de aquí a un año tendrás varios.
• -addext "subjectAltName=..." coloca el nombre de host en la extensión Subject Alternative Name. No la omitas. Los Requisitos Básicos del CA/Browser Forum ahora describen el Common Name como no recomendado y exigen que cualquier valor en él se derive de las entradas SAN, así que la lista SAN es la que tiene autoridad.

Para varios nombres de host, o para un comodín, extiende la misma opción con una lista separada por comas. Repite el Common Name dentro de ella:

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

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

Si prefieres usar una clave de curva elíptica, el comando equivalente está abajo. Comprueba primero que tu Autoridad de Certificación emite certificados ECDSA para el producto que estás comprando, ya que no todas las marcas lo hacen.

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"

El segundo -pkeyopt no es decoración. En OpenSSL no cambia nada, porque una curva nombrada ya es el valor por defecto, pero en la compilación de LibreSSL que distribuye macOS su ausencia hace que la solicitud describa la curva escribiendo todos sus parámetros en lugar de nombrarla. La RFC 5480 prohíbe esa forma en certificados públicos, y una solicitud construida así no identifica ninguna curva en absoluto.

Responde a las preguntas

OpenSSL ahora pide los detalles que van en la solicitud, en este orden:

1. Country Name (2 letter code): el código de dos letras de tu país, por ejemplo US. Aquí está la lista completa de códigos de país.
2. State or Province Name (full name): escrito completo. California, no CA.
3. Locality Name (eg, city): el nombre completo de la ciudad, por ejemplo San Jose.
4. Organization Name (eg, company): el nombre legal exacto de tu organización, por ejemplo Example Holding LLC. Si estás comprando un certificado de Validación de Dominio, la CA no verifica ni usa este campo, así que puede dejarse en blanco.
5. Organizational Unit Name (eg, section): déjalo en blanco. Desde el 1 de septiembre de 2022 los Requisitos Básicos del CA/Browser Forum han incluido este atributo entre los que las CA no deben incorporar, así que lo que escribas se descarta.
6. Common Name: el nombre de host completamente cualificado al que se conectan tus clientes FTPS, por ejemplo ftp.yourdomain.com, o el comodín *.yourdomain.com. La redacción de esta pregunta varía ligeramente entre compilaciones, pero en la configuración por defecto es la sexta pregunta.
7. Email Address: opcional, y normalmente se deja en blanco.
8. A challenge password: déjalo en blanco. Es un atributo heredado de la propia solicitud, nunca llega al certificado emitido, y los formularios de pedido de certificados no lo piden.
9. An optional company name: déjalo también en blanco.

Una trampa que conviene conocer antes de empezar a escribir. «Déjalo en blanco» no significa «presiona Enter». Varios campos llevan un valor por defecto tomado del archivo de configuración de OpenSSL, mostrado entre corchetes al final de la pregunta, y presionar Enter acepta ese valor por defecto en lugar de dejar el campo vacío. En una configuración estándar de OpenSSL, presionar Enter en las primeras preguntas produjo una solicitud que decía C=AU, ST=Some-State y O=Internet Widgits Pty Ltd, que no es lo que nadie quiere enviar a una Autoridad de Certificación. Para dejar un campo realmente en blanco, escribe un solo punto y presiona Enter. OpenSSL lo indica en el preámbulo que imprime justo encima de las preguntas.

Cuando la última pregunta esté respondida, tendrás dos archivos nuevos en el directorio actual:

• ftp.yourdomain.com.csr: la solicitud de firma de certificado. Esta es la que pegas en tu formulario de pedido.
• ftp.yourdomain.com.key: la clave privada. Nunca va a la Autoridad de Certificación y nunca sale de tu control. Cualquiera que la tenga puede suplantar a tu servidor, así que restringe quién puede leerla y haz una copia de seguridad en un lugar al que sigas teniendo acceso dentro de tres años. Si la pierdes, el certificado emitido queda inutilizable: tienes que generar una nueva solicitud y pedir una reemisión.

Comprueba el CSR antes de hacer el pedido

Una errata en la solicitud significa que la CA emite un certificado que no puedes usar, y arreglarlo cuesta otra ronda de validación. Vuelve a leer la solicitud antes de enviarla:

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

Comprueba tres cosas en la salida: la línea Subject lleva los detalles que querías introducir, la sección Subject Alternative Name lista cada nombre de host que usarán los clientes, y la comprobación de la firma pasa. OpenSSL 3.x reporta esto último como Certificate request self-signature verify OK, mientras que la compilación de LibreSSL en macOS lo abrevia a verify OK. Ambos significan lo mismo. Si prefieres no trabajar en la línea de comandos, pega la solicitud en nuestro Decodificador de CSR en su lugar.

También vale la pena confirmar que la clave en disco es realmente la que se usó para construir esta solicitud, especialmente si generaste varias. Comparar las claves públicas funciona con cualquier tipo de clave y tanto en OpenSSL como en LibreSSL:

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

Los dos bloques deben ser idénticos, carácter por carácter. Esta es la versión portátil de la comparación de módulo y md5 más conocida, que solo funciona con claves RSA y reporta un par de curva elíptica perfectamente sano como si no coincidiera.

Finalmente, abre el archivo .csr en un editor de texto plano como el Bloc de notas o TextEdit y copia todo el bloque, incluyendo la primera y última línea:

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

Cada línea marcadora tiene exactamente cinco guiones, las palabras, y luego cinco guiones más. No las vuelvas a escribir a mano y no pegues el texto a través de un procesador de texto, que puede convertir las secuencias de guiones en rayas y producir una solicitud que la CA rechace por estar mal formada.

Cuando no necesitas un CSR en absoluto

Desde la versión 1.0, FileZilla Server puede obtener y renovar un certificado gratuito de Let’s Encrypt por sí solo, sin ninguna solicitud que tengas que generar y sin archivos que importar. El mismo cuadro de diálogo de configuración incluye una página de nivel superior Let’s Encrypt®, debajo de Logging en el árbol. Marca Enable Let’s Encrypt® certificate generation, haz clic en Create new account y acepta los términos de servicio, luego elige en How to perform the challenges si FileZilla Server debe responderlos con su propio servidor web interno (propone el puerto 80 por defecto) o si vas a apuntarlo a la carpeta que un servidor web existente usa para responder solicitudes bajo /.well-known/acme-challenge/. Después de eso, elige Use a Let’s Encrypt® certificate en la pestaña Connection Security y deja marcado Automatically try to renew the certificate in due time.

Dos límites deciden si esto es realista para ti. El servidor solo responde a desafíos de validación HTTP, así que el nombre de host tiene que ser accesible desde internet en el puerto de desafío mientras se emite el certificado y cada vez que se renueva. Y como los certificados comodín de Let’s Encrypt requieren validación basada en DNS, que FileZilla Server no realiza, no puedes obtener un comodín de esta forma.

Por lo tanto, la ruta del CSR anterior sigue siendo la que hay que tomar si necesitas un comodín, un certificado de Validación de Organización o de Validación Extendida, o un certificado para un servidor que no está expuesto a internet. Nuestros tutoriales de ACME cubren la emisión automatizada con más profundidad. La opción restante, el botón Generate new bajo Use a self-signed X.509 certificate, es solo para pruebas: pone en marcha FTPS en segundos, y hace que cada cliente muestre una advertencia que los usuarios aprenden rápidamente a ignorar.

Preguntas frecuentes