Usar certificados SSL/TLS en un entorno de desarrollo local puede parecer un paso opcional, pero en realidad es una práctica muy útil. Te ayuda a familiarizarte con la configuración de HTTPS, a detectar problemas de seguridad antes de tiempo y a preparar la transición hacia un entorno de producción. En este artículo verás cómo generar certificados SAN (Subject Alternative Name) con OpenSSL y actuar como tu propia CA privada, una solución gratuita y compatible con los navegadores y sistemas actuales.
Aunque el término “certificado SSL” sigue siendo de uso común por razones históricas, los certificados modernos son en realidad certificados “SSL/TLS”. TLS es una versión más reciente de SSL que corrige algunas de sus vulnerabilidades de seguridad.
Cómo obtener un certificado SSL
A la hora de obtener un certificado SSL para una aplicación o servicio, puedes considerar una de las siguientes opciones principales:
- un certificado autofirmado
- un certificado emitido por una CA pública
- un certificado firmado por una CA privada
La elección del certificado SSL adecuado depende de tus necesidades específicas. Aunque todas estas opciones pueden funcionar en un entorno de desarrollo local, no todas se adaptan igual de bien a tu caso concreto. Veámoslas una por una.
Certificados autofirmados
Los certificados self-signed están firmados por el mismo usuario o entidad que los creó, lo que significa que no han sido validados por un tercero de confianza, como una CA. Aunque son gratuitos y fáciles de crear, también tienen las siguientes desventajas:
- Los navegadores web y la mayoría de las aplicaciones muestran una alerta de seguridad que te invita a cancelar la conexión, lo que te obliga a ignorar explícitamente estas advertencias o a configurar aplicaciones para que no verifiquen la CA de forma predeterminada, algo que fomenta un comportamiento inseguro.
- No pueden evitar la suplantación de identidad ni pueden revocarse, lo que permite ataques de intermediario, en los que un atacante intercepta y posiblemente altera la comunicación entre las dos partes.
Los certificados autofirmados se firman con tu propia clave privada.
Certificados emitidos por una CA pública
Las CA públicas han sido auditadas y aprobadas por organizaciones independientes para garantizar que cumplan con los estándares de seguridad. Esto significa que tanto los servidores como los clientes consideran que los certificados emitidos por estas CAs son de confianza. Aunque esta opción es indispensable para publicar servicios en Internet, tiene los siguientes inconvenientes en un entorno local:
- Es necesario poseer un nombre de dominio a través de un registrador de dominios, ya sea gratuito o de pago, para poder emitir el certificado.
- Las claves privadas pueden quedar expuestas accidentalmente, lo que permite a un atacante hacerse pasar por el servidor o acceder a información confidencial.
- La emisión de estos certificados normalmente implica una tarifa de licencia, lo que puede aumentar los costos de desarrollo.
¿Qué pasa con Let’s Encrypt? Aunque los certificados emitidos por Let’s Encrypt son completamente gratuitos, emitirlos y renovarlos (se requiere renovación cada 90 días) aún requiere la validación del dominio, lo que suele ser un problema si:
- No se puede acceder públicamente al entorno de desarrollo local (escenario habitual).
- El registrador de dominios no ofrece una API REST para automatizar el proceso sin interacción del usuario.
Los certificados emitidos por una CA pública técnicamente pueden estar firmados por tu certificado raíz o por uno intermedio. Sin embargo, la práctica común es utilizar el certificado intermedio como puente para mantener segura la clave privada del certificado raíz.
Es importante tener en cuenta que una CA pública no es lo mismo que una CA confiable, por lo que es crucial asegurarse de que la CA elegida tenga una buena reputación en cuanto a estándares de seguridad. Algunas de las CA públicas de mayor reputación son, entre otras: Comodo, DigiCert, GoDaddy, GeoTrust y Let’s Encrypt.
Certificados emitidos por una CA privada
Los certificados emitidos por una CA privada (también conocida como CA interna o empresarial) están destinados únicamente para uso interno, como dentro de una organización específica o red local, donde puedes controlar qué certificados son confiables. El hecho de que sean gratuitos y no requieran registro de dominio los hace ideales para entornos de desarrollo local.
Sin embargo, introducen un nivel adicional de gestión que consiste en:
- Instalación del certificado raíz e intermedio (si lo hubiera) de la CA privada en el almacén de certificados de cada cliente, ya que no están incluidos en la lista de confianza de navegadores web y sistemas operativos (es decir, no son válidos en Internet).
- Configuración del archivo de hosts local o DNS interno para resolver nombres de dominio en las direcciones IP correctas, ya que los nombres de dominio que se utilizan internamente pueden no poder resolverse públicamente.
Los certificados emitidos por una CA privada pueden ser firmados ya sea por tu certificado raíz o por un certificado intermedio, la emisión de los intermedios dependerá de las necesidades de seguridad, estructura y tamaño del entorno interno.
Los términos autofirmado y autoemitido a veces se intercambian incorrectamente. El punto clave es que, si bien los certificados autofirmados se refieren explícitamente a un certificado en el que la entidad firma, los certificados autoemitidos pueden implicar tanto un certificado autofirmado como un certificado emitido por una CA privada. En resumen, todos los certificados autofirmados son autoemitidos, pero no todos los certificados autoemitidos son autofirmados.
Un poco de contexto
Los primeros certificados SSL, introducidos en 1994, solo admitían el atributo Nombre común (CN) del campo Propiedad del sujeto para identificar el dominio principal. Sin embargo, depender únicamente de CN para validar un dominio presentaba varias limitaciones importantes:
- Solo puede contener un nombre de dominio o comodín, no adecuado para certificados que necesitan proteger múltiples dominios o subdominios.
- No especifica claramente el propósito o uso del nombre, lo que ha generado ambigüedad y errores de seguridad en el pasado.
- Está limitado a 64 caracteres, lo que puede no ser suficiente para algunos nombres o títulos descriptivos.
En 1999, se introdujo la extensión Subject Alternative Name (SAN) como parte del estándar X.509 para certificados digitales, con el objetivo de abordar las limitaciones del campo CN. Desde entonces, los navegadores y sistemas modernos se adhieren cada vez más a su uso, como se destaca en los siguientes RFC:
- RFC 2818 (mayo de 2000): recomienda utilizar la extensión Nombre alternativo del sujeto (SAN) del tipo de nombre DNS en lugar de CN.
- RFC 5280 (mayo de 2008): establece que el nombre del sujeto PUEDE figurar en el campo de asunto y/o en la extensión SubjectAltName.
- RFC 6125 (marzo de 2011): establece que el validador debe verificar SAN primero y, si SAN existe, entonces no se debe verificar CN.
Chrome, por ejemplo, desde tu versión 58 (abril de 2017) pasó a utilizar exclusivamente la extensión SAN para la validación de dominios, arrojando un error
ERR_CERT_COMMON_NAME_INVALIDen caso de que no se encuentre.
Emitir un certificado SAN a través de una CA privada
En general, los pasos básicos para emitir un certificado firmado por una CA son los siguientes:
- Crear una clave privada (KEY) en un entorno seguro.
- Generar una Solicitud de Firma de Certificado (CSR) a partir de esa clave.
- Emitir un certificado (CRT) firmado por la CA mediante el CSR.
Como vas a actuar como una CA privada, lo primero que debes hacer es crear tu certificado raíz. En las secciones siguientes, puedes elegir el período de validez y los nombres de archivo y dominio que mejor se adapten a tu caso.
Recuerda siempre mantener seguras tus claves privadas y CSR. Cualquiera que tenga acceso a ellos puede hacerse pasar por tus servidores.
Emitir la CA privada
Dado que no existe una entidad superior que pueda firmar el certificado raíz de la CA, esta debe firmar ella misma. Por este motivo, no es necesario generar una CSR, pudiendo crearse tanto la clave privada como el certificado raíz autofirmado en un solo paso.
1
2
3
4
5
openssl req -x509 -sha256 -newkey rsa:2048 -nodes \
-keyout ca.key \
-out ca.crt \
-days 365 \
-subj '/CN=Homenet CA'
Después de ejecutar el comando anterior, se crea un nuevo certificado autofirmado con una clave privada RSA de 2048 bits sin frase de contraseña y una validez de 1 año. El certificado y la clave privada se almacenan en los archivos ca.crt y ca.key, respectivamente.
Recuerda que los certificados raíz de las CA, ya sean públicos o privados, no están firmados por otra CA. Están autofirmados y las entidades independientes deben dar fe de la confiabilidad de una CA pública.
Emisión del certificado SAN
Primero, necesitamos crear la solicitud de firma de certificado (CSR), que contendrá la información que la CA utilizará para firmar el certificado.
1
2
3
4
5
openssl req -newkey rsa:2048 -nodes \
-keyout star_home_arpa.key \
-out star_home_arpa.csr \
-subj '/CN=*.home.arpa' \
-addext 'subjectAltName=DNS:*.home.arpa'
La CSR y la clave privada se almacenan en los archivos star_home_arpa.csr y star_home_arpa.key, respectivamente. El nombre común del certificado es el dominio comodín *.home.arpa, que también se agrega como nombre de dominio alternativo.
Puedes agregar tantos dominios adicionales como necesites añadiendo más pares
DNS:FQDNseparados por comas en el camposubjectAltName. Si utilizas una dirección IP, antepongaIP:en lugar deDNS:.
Finalmente, el CSR creado anteriormente se puede enviar a nuestra CA privada para obtener el certificado firmado.
1
2
3
4
5
6
openssl x509 -req -sha256 -CAcreateserial -copy_extensions copy \
-days 365 \
-in star_home_arpa.csr \
-CA ca.crt \
-CAkey ca.key \
-out star_home_arpa.crt
El comando anterior toma el CSR star_home_arpa.csr, lo firma con la clave privada de la CA ca.key y genera un nuevo certificado X.509 star_home_arpa.crt. El nuevo certificado tiene una validez de 1 año e incluye las ampliaciones que estaban en el CSR.
RFC 8375 recomienda el uso del nombre
home.arpapara dominios locales porque, en teoría, los enrutadores y servidores DNS son conscientes de que las solicitudes ARPA que no comprenden no deben reenviarse a la Internet pública. Esto ayuda a evitar conflictos con los nombres de dominio públicos de Internet y proporciona un espacio de nombres seguro para las redes locales.
Verificando las extensiones SAN en el certificado
Para comprobar si el certificado realmente incluye las extensiones SAN, puedes buscar la sección X509v3 extensions en el resultado del siguiente comando.
1
openssl x509 -noout -text -in star_home_arpa.crt
Si el certificado incluye dichas extensiones, verá una línea que comienza con X509v3 Subject Alternative Name seguida de los dominios definidos, en nuestro caso:
1
2
3
4
5
...
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:*.home.arpa
...
Instalación del certificado de CA raíz
Ten en cuenta que los pasos anteriores generan un certificado firmado por tu propia CA privada, y que los clientes no van a confiar en ella como una CA de confianza por defecto. Por eso, si quieres que los certificados emitidos por esa CA sean aceptados en un sistema, tendrás que instalar el certificado de CA raíz en el sistema operativo de cada entorno donde vayas a confiar en ellos.
Windows
Para clientes de Windows, podemos instalar el certificado en cualquier ámbito: en la máquina local (que requiere privilegios de administrador) o para el usuario actual. Veremos cómo hacer esto usando la CLI de PowerShell o la GUI de la Consola de Certificate Manager.
PowerShell
Ámbito de usuario: esto instala el certificado para una cuenta de usuario específica en el sistema, haciéndolo accesible solo para ese usuario en particular y cualquier aplicación que ejecuta.
1
Import-Certificate -FilePath .\ca.crt -CertStoreLocation Cert:\CurrentUser\Root
Ámbito de la máquina (como administrador): esto instala el certificado para todo el sistema informático, haciéndolo accesible para todas las cuentas de usuario y aplicaciones que se ejecutan en esa máquina (lo más común para los certificados que son esenciales para la seguridad de todo el sistema).
1
Import-Certificate -FilePath .\ca.crt -CertStoreLocation Cert:\LocalMachine\Root
Consola de administrador de certificados
El procedimiento de instalación es el mismo para ambos ámbitos; solo difiere el acceso directo utilizado para acceder a la consola en el paso 1:
- Presiona la tecla Windows + R para abrir el cuadro de diálogo ‘Ejecutar’ y escribe:
certmgr.mscpara el alcance del usuariocertlm.mscpara el alcance de la máquina (como administrador)
- Amplía ‘Certificados’ / ‘Autoridades de certificación raíz de confianza’ / ‘Certificados’.
- Haz clic con el botón derecho en la carpeta ‘Autoridades de certificación raíz de confianza’ y selecciona ‘Todas las tareas’/’Importar…’.
- Escribe el nombre del archivo o haz clic en Examinar y selecciona el certificado que deseas importar.
- Selecciona ‘Colocar todos los certificados en el siguiente almacén’ y utiliza ‘Autoridades de certificación raíz de confianza’ como ‘Almacén de certificados’.
Linux
Linux no tiene un almacén de certificados unificado a nivel de usuario como Windows. En cambio, los certificados suelen almacenarse en directorios específicos del sistema de archivos. Para instalar un certificado en el almacén de certificados del sistema, siga estos pasos como administrador:
Copia el certificado
ca.crten el directorio del almacén de CA.1
sudo cp ca.crt /usr/local/share/ca-certificates/ca.crtAsegúrate de que los permisos sean correctos para el certificado
ca.crt.1
sudo chmod 664 /usr/local/share/ca-certificates/ca.crt
755: Cualquier persona debe poder acceder a los directorios, pero solo el usuario root debe poder escribirlos.
644: Los certificados deben ser legibles por cualquier usuario o servicio que necesite verificar la autenticidad.
600: Las claves privadas asociadas con los certificados solo deben ser legibles por el usuario root.
Finalmente, actualiza el almacén de CA para que los cambios surtan efecto.
1
sudo update-ca-certificates
Algunos programas pueden tener tu propio almacén de certificados y es posible que necesites importar tu certificado a esos almacenes de certificados específicos, como con Firefox o Chrome.
Editando tu archivo de hosts
El archivo de hosts es un archivo simple que asigna nombres de dominio a direcciones IP. Cuando tu navegador u otra aplicación usa un nombre de dominio, consulta primero el archivo de hosts para comprobar si existe una entrada para ese nombre. Si la hay, se utiliza la dirección IP asociada para llegar al sitio web. Si no es así, la aplicación consulta el servidor de resolución DNS local o, si no existe o no tiene autoridad para ese dominio, uno público.
Como los dominios locales no están registrados en servidores DNS públicos, puedes editar el archivo de hosts de tu sistema si no quieres o no necesitas usar un servidor DNS local. Así consigues una forma manual y efectiva de asignar nombres de dominio locales a direcciones IP.
Las rutas de los archivos hosts para la mayoría de las distribuciones de Linux, así como para los sistemas Windows, son:
- Linux:
/etc/hosts - Windows:
C:\Windows\System32\drivers\etc\hosts
Un archivo de hosts típico podría verse así:
1
2
3
4
5
6
7
8
127.0.0.1 localhost
::1 localhost
# Ejemplo de entrada para un servidor local
192.168.1.100 www.home.arpa
# Ejemplo de bloqueo de un sitio web
0.0.0.0 www.example.com
En este ejemplo, localhost está asociado con las direcciones IP 127.0.0.1 y ::1, que son las direcciones IP de bucle invertido estándar para IPv4 e IPv6, respectivamente.
La línea 192.168.1.100 www.home.arpa es un ejemplo de cómo puedes asociar un nombre de dominio local con una dirección IP en tu red local.
La línea 0.0.0.0 www.example.com es un ejemplo de cómo se puede bloquear el acceso a un sitio web específico redirigiendo tu nombre de dominio a una dirección IP no válida.
Las líneas que comienzan con # son comentarios y no afectan la resolución del nombre de host. Puede utilizar comentarios para agregar notas o desactivar temporalmente ciertas entradas.
Conclusión
En este artículo has visto cómo actuar como una CA privada y emitir certificados SAN con OpenSSL en pocos pasos. Esto te permite obtener certificados para desarrollo local sin depender de terceros, de forma ligera y gratuita, respetando los estándares actuales y manteniendo la compatibilidad con navegadores y sistemas modernos. También has revisado cómo confiar en esos certificados desde el sistema operativo y cómo mapear dominios locales editando el archivo hosts.
Este mismo enfoque resulta especialmente útil en entornos como los objetos TLS Secret dentro de un clúster de Kubernetes on-premise, donde puedes asignar nombres de dominio a los servicios que se ejecutan en él. En una próxima entrada, te mostraré cómo automatizar este proceso mediante un Ingress Controller de tipo load balancer.
