Importar y asignar certificados en Sophos Firewall

Un certificado solo está listo para usarse en Sophos Firewall cuando coinciden cuatro elementos: nombre de host, certificado de servidor, clave privada y cadena de la CA emisora. Después, el certificado todavía debe asignarse al servicio correcto. El mero hecho de que aparezca en Certificates > Certificates no modifica ningún portal ni ninguna regla WAF.

Para un certificado de una CA interna o pública, el método estándar más seguro es el siguiente:

1. Generar una Certificate Signing Request (CSR) en Certificates > Certificates > Add.
2. Solicitar a la CA deseada que firme la CSR.
3. Importar el certificado emitido mediante la acción de importación de la CSR existente.
4. Comprobar en Trusted que la CA correspondiente está instalada y en Valid until que el certificado es válido.
5. Asignar el certificado al servicio deseado y probarlo desde un cliente.

Con este método, la clave privada se genera en el firewall y no tiene que salir de él. También se puede cargar un certificado que se haya generado externamente, pero requiere la clave privada correspondiente y, si faltan, las CA intermedias y raíz.

Si ya se dispone de un archivo PFX o PEM, la vía rápida es Certificates > Certificates > Add > Upload certificate: seleccionar el formato, cargar el certificado junto con la clave privada necesaria y su contraseña y, después, comprobar la CA correspondiente, el periodo de validez y la asignación al servicio.

¿Qué método de certificado conviene utilizar?

• CA pública o interna, certificado nuevo: generar la CSR en el firewall. Así se reduce el transporte de claves y se evitan confusiones entre pares de certificado y clave.
• Certificado existente con clave privada: cargar el certificado en formato PEM, DER, CER o PKCS12. El formato, la contraseña y la cadena de CA deben ser correctos.
• Let’s Encrypt para un servicio público del firewall: el proceso integrado puede encargarse de la emisión y la renovación. El procedimiento completo se explica en Configurar certificados Let’s Encrypt en Sophos Firewall.
• Certificado wildcard externo: generarlo fuera del firewall e importarlo después. La planificación y la validación DNS-01 se describen en Crear un certificado wildcard de Let’s Encrypt.
• Solo para clientes internos gestionados: un certificado firmado localmente puede ser suficiente si todos los clientes confían en la CA interna emisora.

Un certificado autofirmado o firmado localmente no implica automáticamente un cifrado inseguro. Sin una cadena de confianza distribuida, el cliente no puede confirmar la identidad de forma fiable y muestra una advertencia. Por eso, para portales y aplicaciones WAF accesibles públicamente, una CA pública suele ser la mejor opción.

Diferencias entre certificado, CA, clave privada y CSR

Estos cuatro elementos cumplen funciones distintas:

• Certificado de servidor: contiene la identidad, la información de la clave pública, los nombres válidos y el periodo de validez. Es lo que se presenta al cliente.
• Clave privada: demuestra que el firewall está autorizado a utilizar el certificado. Nunca debe incluirse en tickets, capturas de pantalla ni repositorios públicos.
• Certificados de CA: forman la cadena de confianza desde la CA intermedia emisora hasta la CA raíz. Para ello no se necesita ninguna clave privada de la CA.
• CSR: contiene la solicitud del certificado y la clave pública. Cuando la CSR se genera en el firewall, la clave privada correspondiente permanece en el dispositivo.

Una CA para TLS Inspection cumple una función distinta a la de un certificado de servidor para WebAdmin o WAF. Durante el descifrado, la CA de inspección firma nuevos certificados para los clientes. Su selección y distribución se explica en Distribuir el certificado de CA de Sophos Firewall para TLS Inspection.

Preparar los nombres, la validez y la cadena

Antes de la importación debe quedar claro qué nombre abrirán realmente los usuarios y sistemas. Los clientes modernos comprueban principalmente los Subject Alternative Names (SAN). El Common Name por sí solo no es un sustituto fiable.

Ejemplo:

• URL utilizada: https://vpn.example.com
• nombre del certificado en SFOS: public-vpn-example-com-2026
• SAN del certificado: vpn.example.com
• DNS: vpn.example.com apunta al acceso previsto del firewall o de WAF

vpn.example.com es un ejemplo y debe sustituirse por el FQDN propio. Si un administrador accede mediante la dirección IP u otro alias, el certificado solo coincidirá si ese nombre o esa IP también figura como SAN.

Antes del cambio, compruebe lo siguiente:

• La fecha, la hora y el NTP del firewall son correctos.
• Todos los FQDN necesarios aparecen como SAN en la solicitud o en el certificado.
• La clave privada y el certificado forman el mismo par.
• Se conocen las CA intermedias y raíz.
• Están documentados la fecha de caducidad y el responsable de la renovación.
• Se conservan el certificado anterior y sus asignaciones como vía de retorno.

Método recomendado: generar la CSR en el firewall

Crear la CSR

1. Abra Certificates > Certificates.
2. Seleccione Add.
3. En Action, seleccione Generate certificate signing request (CSR).
4. Asigne un nombre interno descriptivo, por ejemplo, public-vpn-example-com-2026.
5. Seleccione el Key Type, la longitud de clave o curva y el hash requeridos según sus propios requisitos de seguridad y los de la CA.
6. En Common name, introduzca el FQDN principal, por ejemplo, vpn.example.com.
7. En Subject Alternative Names, añada al menos el nombre DNS que se utilizará realmente.
8. Guarde la configuración y descargue la CSR mediante el icono de descarga.

El nombre interno del certificado es solo una denominación de SFOS. No tiene que coincidir con el FQDN, pero debería permitir identificar el propósito y el año de renovación. Los SAN, en cambio, forman parte de la comprobación técnica de identidad y deben coincidir con la URL que se utilizará posteriormente.

Solicitar la firma de la CSR

Entregue la CSR descargada a la CA pública o interna correspondiente. No permita que se generen nuevos archivos de clave si debe utilizarse la clave privada creada en el firewall. A continuación, la CA proporciona el certificado de servidor firmado y, según el proveedor, certificados intermedios adicionales.

Antes de la importación, compruebe lo siguiente:

• La CA ha firmado la CSR correcta.
• La lista de SAN contiene todos los nombres autorizados.
• El periodo de validez y el emisor coinciden con el pedido o con la política interna.
• La cadena de CA está completa.

Importar en la CSR el certificado firmado

1. Abra Certificates > Certificates.
2. En la fila de la CSR correspondiente, seleccione la acción de importación en Manage.
3. Cargue el certificado emitido o pegue el texto del certificado.
4. Como propósito, seleccione normalmente Certificate only. Si el mismo archivo contiene además la cadena de CA, seleccione el propósito adecuado para el certificado y la CA.
5. Ejecute Import certificate.

SFOS vincula el certificado con la clave privada disponible en el firewall y elimina después la entrada de la CSR. Por ello, antes de importarlo debe comprobar cuidadosamente que se ha seleccionado la fila de la CSR correcta.

Cargar un certificado existente con su clave privada

Si el certificado y la clave ya se generaron fuera del firewall:

1. Abra Certificates > Certificates > Add.
2. Seleccione Upload certificate.
3. Asigne un nombre inequívoco.
4. Seleccione el formato de archivo existente.
5. Cargue el certificado y los datos de clave que requiera el formato.
6. Si la clave privada está cifrada, introduzca su contraseña.
7. Guarde la configuración.

SFOS admite los siguientes formatos de certificado:

• PEM (.pem): codificado en Base64; el certificado y la clave privada suelen estar en archivos separados.
• DER (.der) y CER (.cer): formatos binarios de certificado; la clave privada se encuentra en un archivo separado.
• PKCS7 (.p7b): puede contener certificados y una cadena, pero no una clave privada.
• PKCS12 (.pfx o .p12): puede contener conjuntamente el certificado de servidor, la cadena de CA y la clave privada.

Se admiten claves RSA y ECC. SFOS acepta un máximo de 30 caracteres para la contraseña de una clave privada importada. Este límite del producto no justifica el uso de una clave privada sin protección: establezca para el traslado una contraseña robusta dentro de ese límite y elimine después el archivo de importación de cualquier ubicación intermedia insegura.

Completar una cadena de CA incompleta

En Certificates > Certificates, una entrada verde en Trusted indica que la CA correspondiente está instalada en SFOS. Si no aparece, compruebe primero el emisor y la cadena:

1. Abra Certificates > Certificate authorities.
2. Seleccione Add.
3. Cargue la CA intermedia o raíz que falte, o pegue el texto del certificado.
4. Para una cadena destinada exclusivamente a establecer confianza, utilice Validation only.
5. Guarde la configuración y vuelva a comprobar el estado Trusted del certificado de servidor.

Una CA raíz o intermedia pública no necesita una clave privada para la validación. Signing and validation solo está destinado a una CA con la que el firewall vaya a firmar certificados y cuya clave privada esté presente deliberadamente en el firewall.

Upgrade a SFOS 21 o posterior: comprobar los nombres de CA reservados

Durante el primer upgrade de una instalación anterior a SFOS 21 o posterior, NC-146082 puede bloquear la migración. La causa no es la validez del certificado, sino una entrada de CA ya configurada cuyo nombre reserva SFOS para las CA de Let’s Encrypt integradas:

Lets_Encrypt_R10
Lets_Encrypt_R11
Lets_Encrypt_R12
Lets_Encrypt_R13
Lets_Encrypt_R14
Lets_Encrypt_E5
Lets_Encrypt_E6
Lets_Encrypt_E7
Lets_Encrypt_E8
Lets_Encrypt_E9

Antes de la ventana de mantenimiento:

1. Crear un backup reciente de la configuración y tener disponibles la contraseña del backup y la Secure Storage Master Key.
2. En Certificates > Certificate authorities, buscar los nombres exactos. Si no hay coincidencias, NC-146082 no requiere ningún cambio.
3. Si hay una coincidencia, documentar el tipo, Subject, Issuer, propósito y la presencia del icono de clave. El icono indica que el firewall posee la clave privada de la CA.
4. Exportar además una CA con clave privada desde Backup and firmware > Import export > Export selective configuration como CertificateAuthority. Después, identificar los certificados y servicios que dependen de la CA, por ejemplo VPN, WebAdmin y portales, WAF, SMTP TLS o TLS Inspection.
5. Eliminar una entrada configurada por el administrador solo después de sustituir todas sus dependencias o demostrar que ya no son necesarias. A continuación, repetir el upgrade.

No se debe eliminar una CA integrada. Si WebAdmin rechaza la eliminación, falta la clave privada original o alguna referencia sigue sin estar clara, hay que detener el upgrade y recurrir al soporte de Sophos. Las modificaciones en la base de datos o mediante Advanced Shell no son una alternativa segura.

Después del upgrade, comprobar que las CA de Let’s Encrypt integradas están presentes, que los certificados dependientes vuelven a mostrar Trusted y que los servicios afectados funcionan.

Asignar el certificado al servicio correcto

Antes de asignarlo: asegurar la vía de retorno

Un cambio de certificado no debe comenzar eliminando la entrada anterior:

1. Importe el nuevo certificado y la cadena de CA completa.
2. Compruebe los SAN, el emisor, el periodo de validez y Trusted.
3. Documente la asignación anterior y los servicios afectados.
4. Asigne primero el nuevo certificado a un solo servicio.
5. Pruebe ese servicio mediante su FQDN y puerto reales.
6. Si se producen errores, vuelva a seleccionar inmediatamente el certificado anterior.
7. Cambie los demás servicios uno por uno y compruébelos después de cada cambio.
8. Elimine el certificado anterior solo cuando ya no exista ninguna referencia y el nuevo estado sea estable.

WAF y SMTP se pueden cambiar por separado. En cambio, WebAdmin, User Portal, VPN Portal, Captive Portal y los dos portales SPX cambian simultáneamente mediante una selección de certificado compartida.

Cuando modifique WebAdmin, mantenga además abierta una sesión de administrador existente y un acceso de gestión local alternativo hasta haber comprobado el inicio de sesión y el certificado mediante el FQDN previsto.

WebAdmin y portales

En Administration > Admin and user settings > Admin console and end-user interaction se selecciona un certificado común para estos servicios:

• WebAdmin Console
• User Portal
• VPN Portal
• Captive Portal
• SPX Registration Portal
• SPX Reply Portal

En el campo Certificate, seleccione el nuevo certificado y guarde con Apply. El certificado debe abarcar todos los FQDN mediante los que se accede a los servicios utilizados. Si, por ejemplo, se utiliza admin.example.com para WebAdmin y vpn.example.com para VPN Portal, ambos nombres deben figurar como SAN o debe unificarse la planificación de las URL.

El certificado de VPN Portal protege el sitio web HTTPS desde el que los usuarios obtienen perfiles y clientes. No es automáticamente el Local Certificate o Remote Certificate de un túnel IPsec.

WAF

Para una publicación WAF, edite la regla correspondiente en Rules and policies > Firewall, active HTTPS, seleccione el nuevo certificado en HTTPS certificate y guarde la configuración. La regla utiliza Protect with web server protection. El SNI, el dominio de la regla y el SAN del certificado deben describir el mismo nombre de host.

Al modificar una regla WAF, se reinician las reglas de Web Server Protection y se interrumpen las conexiones existentes. Por eso, en aplicaciones productivas, el cambio de certificado debe realizarse durante una ventana de mantenimiento. La publicación y la comprobación completas se explican en Sophos Firewall WAF: publicar un servidor web de forma segura.

SMTP TLS en modo MTA

Para Mail Protection, seleccione el nuevo certificado de servidor en el campo TLS certificate de Email > General settings > SMTP TLS configuration y guarde con Apply. Para la comunicación SMTP pública se recomienda un certificado de una CA pública, de modo que los sistemas remotos puedan comprobar la identidad sin tener que distribuir una CA propia. El resto del flujo de correo se explica en Mail Protection de Sophos Firewall en modo MTA.

Después del cambio, cree un nuevo backup de Sophos Firewall y documente la fecha de caducidad, el responsable y la próxima renovación.

Comprobar el certificado y su entrega

Comprobar el archivo antes de importarlo

En un ordenador de administración se puede examinar un certificado PEM con OpenSSL sin modificarlo:

openssl x509 -in firewall.pem -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256

Sustituya firewall.pem por la ruta local del archivo. La salida debe mostrar el Subject esperado, el emisor, el periodo de validez, los SAN necesarios y una huella SHA-256. El comando no lee ninguna clave privada.

Comprobar el servicio HTTPS desde el exterior

Pruebe WebAdmin, los portales y WAF desde un ordenador de administración con OpenSSL:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_hostname vpn.example.com -verify_return_error </dev/null

Sustituya el FQDN y el puerto por los del servicio HTTPS real. -servername envía el nombre mediante SNI para que se seleccione el certificado correcto cuando existen varios destinos WAF o portales. La comprobación es correcta si aparece el certificado esperado, el nombre de host coincide y al final figura Verification: OK.

Si se utiliza una CA interna, el ordenador de administración ya debe confiar en ella o recibirla expresamente como ancla de confianza para la prueba. De lo contrario, el error de verificación puede deberse al equipo de prueba aunque el firewall entregue la cadena correcta.

Comprobar SMTP con STARTTLS

SMTP en el puerto 25 o 587 suele comenzar sin cifrar y solo cambia a TLS mediante STARTTLS. Para ello se necesita una prueba propia:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Sustituya mail.example.com y el puerto 25 por el FQDN de SMTP y el puerto STARTTLS que se utilice realmente. Para TLS implícito en el puerto 465, no se utiliza -starttls smtp. También en este caso deben coincidir el certificado esperado, el nombre de host y Verification: OK.

Compruebe además en el navegador o cliente:

• La URL utiliza uno de los SAN incluidos.
• El emisor y la fecha de caducidad coinciden con el nuevo certificado.
• No aparece ninguna advertencia de certificado.
• El servicio WebAdmin, portal, WAF o de correo esperado funciona.
• Una prueba externa no sigue mostrando el certificado de un balanceador de carga o Reverse Proxy interpuesto.

Errores habituales y siguiente comprobación

• Trusted sigue vacío: falta una CA intermedia, se ha importado una CA incorrecta o la cadena no pertenece al certificado de servidor. Compruebe el emisor y el orden de las CA.
• Se rechaza la importación: compruebe el formato de archivo, la contraseña de la clave privada, el límite de 30 caracteres, el par de certificado y clave y la hora del sistema.
• El navegador indica un nombre incorrecto: el FQDN o la dirección IP utilizados no figuran en los SAN. Compare la URL, el DNS y los nombres del certificado.
• El navegador sigue mostrando el certificado anterior: el servicio todavía utiliza la asignación antigua o un proxy interpuesto termina TLS. Compruebe el destino esperado directamente con openssl s_client y SNI.
• WAF entrega el certificado incorrecto: compruebe Hosted Address, Listen Port, Domain, SNI y el orden de las reglas WAF que se solapan.
• Solo algunos clientes muestran una advertencia: compruebe el Trust Store, los certificados intermedios, la hora del sistema y posibles restricciones de Certificate Pinning del cliente afectado.
• Un portal deja de estar accesible después del cambio: vuelva a seleccionar el certificado anterior y compruebe por separado el FQDN, el puerto, Device Access y la cadena de certificados.

FAQ