Cómo generar un certificado autofirmado usando OpenSSL

Un certificado autofirmado es aquel que te emites a ti mismo en lugar de comprarlo a una autoridad de certificación. Los navegadores no lo reconocerán automáticamente, por lo que no tiene cabida en un sitio web público, pero es la forma más rápida de habilitar HTTPS en una máquina de desarrollo, un entorno de pruebas, un panel interno o cualquier servicio que nunca se exponga a internet.

Esta guía te muestra cómo crear un certificado autofirmado con OpenSSL en Windows, Linux y macOS. El comando es el mismo en los tres sistemas. También verás cómo comprobar que el certificado que has generado realmente funciona y cómo hacer que tu propia máquina confíe en él para que las advertencias del navegador desaparezcan.

Qué es un certificado autofirmado

Un certificado autofirmado es un certificado digital firmado con su propia clave privada en lugar de por una autoridad de certificación (CA) de confianza. Desde el punto de vista criptográfico es un certificado X.509 normal: cifra el tráfico exactamente igual que uno comprado. Lo que le falta es una cadena de confianza. Nada fuera de tu propia máquina tiene motivo alguno para creer en él, así que los navegadores muestran una advertencia hasta que les indiques lo contrario.

Esto hace que los certificados autofirmados sean adecuados para:

• Desarrollo local, donde necesitas HTTPS para que las cookies, los service workers o un SDK de pagos se comporten como lo harán en producción.
• Servicios internos, como un panel de intranet, un panel de monitorización o una interfaz de gestión de dispositivos en una red privada.
• Pruebas y entornos de staging, donde quieres ensayar una configuración TLS sin gastar un certificado en ello.
• Servidores de origen detrás de un proxy que acepta un certificado no confiable en el tramo interno, como Cloudflare en modo Full.

No son la herramienta adecuada para nada que un visitante real vaya a cargar. Tratamos esa distinción en detalle más abajo, en la sección sobre cuándo no usar uno.

Antes de empezar: comprueba tu OpenSSL

Necesitas la herramienta de línea de comandos OpenSSL. Comprueba qué versión tienes:

openssl version

• Linux: OpenSSL viene preinstalado en la mayoría de las distribuciones. Si no es así, consulta nuestra guía sobre cómo instalar OpenSSL en Ubuntu.
• Windows: OpenSSL no viene incluido. Sigue nuestras instrucciones sobre cómo instalar OpenSSL en Windows, y luego ejecuta el comando desde el Símbolo del sistema o PowerShell.
• macOS: Apple incluye LibreSSL, una bifurcación de OpenSSL, como el comando openssl integrado, así que esto devuelve algo como LibreSSL 3.3.6 en lugar de una versión de OpenSSL.

El comando principal de esta guía funciona tanto en LibreSSL 3.3.6 como en las versiones actuales de OpenSSL, así que los usuarios de Mac pueden usar la herramienta integrada. Si prefieres tener OpenSSL genuino (algunos de los comandos opcionales que veremos a continuación lo necesitan), instálalo con el gestor de paquetes Homebrew y llámalo por su ruta completa:

brew install openssl@3
/opt/homebrew/opt/openssl@3/bin/openssl version

En los Mac con Intel, la ruta es /usr/local/opt/openssl@3/bin/openssl en su lugar. Para más detalles sobre cómo leer el resultado, consulta nuestra guía sobre cómo comprobar tu versión de OpenSSL.

Cómo crear un certificado autofirmado con OpenSSL

Paso 1: Abre una terminal

En Linux, pulsa Ctrl + Alt + T o busca «Terminal» en el menú de aplicaciones. En macOS, abre Aplicaciones, luego Utilidades y después Terminal, o pulsa Cmd + Espacio y escribe «Terminal». En Windows, pulsa Win + R, escribe cmd y pulsa Intro.

Paso 2: Ve a la carpeta donde quieres los archivos

OpenSSL escribe su salida en el directorio en el que te encuentres en ese momento, no en el directorio donde está instalado OpenSSL. Crea una carpeta para este certificado y muévete a ella para que la clave y el certificado queden en un lugar donde puedas encontrarlos:

mkdir my-cert
cd my-cert

En Windows, usa los mismos dos comandos en el Símbolo del sistema. No ejecutes los comandos desde dentro de la carpeta del programa OpenSSL: en Windows ese directorio a menudo no permite escritura a un usuario normal, y mezclar tus claves con los binarios hace que sea fácil perderlas.

Paso 3: Ejecuta el comando del certificado

Este único comando genera la clave privada y el certificado autofirmado juntos. Sustituye example.com y www.example.com por los nombres a través de los cuales se accederá realmente a tu servicio:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Mantenlo en una sola línea. El Símbolo del sistema y los shells de Unix usan caracteres de continuación de línea diferentes, y una sola línea funciona en todos los casos. Usa comillas dobles, no comillas simples, por el mismo motivo: el Símbolo del sistema no trata las comillas simples como comillas.

Esto es lo que hace cada parte:

• req -x509: produce un certificado firmado y terminado en lugar de una solicitud de firma de certificado.
• -newkey rsa:2048: crea una nueva clave privada RSA de 2048 bits como parte del mismo comando. 2048 bits es el mínimo actual y un valor predeterminado razonable. Usa rsa:4096 si tu política exige una clave más grande, a costa de negociaciones (handshakes) más lentas.
• -keyout private.key: el nombre de archivo para la clave privada.
• -out certificate.crt: el nombre de archivo para el certificado.
• -days 365: durante cuánto tiempo permanece válido el certificado. Consulta la sección sobre validez más abajo antes de cambiar esto.
• -nodes: deja la clave privada sin cifrar, para que tu servidor web pueda iniciarse sin que una persona escriba una contraseña.
• -addext «subjectAltName=…»: la lista de nombres de host para los que es válido el certificado. Sin esto, el certificado no coincide con nada.
• -addext «basicConstraints=critical,CA:FALSE»: marca el certificado como un certificado de entidad final (servidor) en lugar de una autoridad de certificación.
• -addext «extendedKeyUsage=serverAuth»: indica que el certificado es para autenticar un servidor TLS. Las plataformas de Apple lo tratan como obligatorio.

Por qué importan las tres opciones -addext

Estos tres indicadores marcan la diferencia entre un certificado que funciona y uno que los clientes rechazan directamente. Merece la pena entenderlos, porque un certificado autofirmado creado sin ellos falla de tres formas que son fáciles de diagnosticar mal.

El Subject Alternative Name es donde viven los nombres de host. Los navegadores dejaron de leer el campo Common Name hace años y ahora comparan el nombre de host únicamente con la extensión Subject Alternative Name (SAN). Un certificado sin SAN no coincide con ningún sitio, aunque el Common Name parezca correcto. Enumera cada nombre que vayas a usar, separados por comas. Para un servicio local también puedes incluir una dirección IP:

-addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1"

Sin CA:FALSE, OpenSSL te crea un certificado de CA. Cuando req -x509 se deja con sus valores predeterminados, establece basicConstraints como critical, CA:TRUE, lo que describe una autoridad de certificación, no un servidor web. Chrome y Safari aceptan eso en un certificado de servidor. Firefox no, y se detiene con MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY. Aún puedes hacer clic en Avanzado y añadir una excepción, pero estarías solucionando un problema con un certificado que ya sabes que está mal formado, y otros clientes trazan la línea en lugares diferentes. Pasar basicConstraints=critical,CA:FALSE evita la situación desde el principio.

La versión de LibreSSL que incluye macOS se comporta de forma diferente en este punto: dejada con sus valores predeterminados, escribe un certificado X.509 versión 1 sin ninguna extensión, por lo que no tienes el problema de CA:TRUE pero tampoco tienes Subject Alternative Name. Proporcionar las extensiones explícitamente te da el mismo certificado correcto en ambas herramientas.

Sin serverAuth, las plataformas de Apple rechazan el certificado. Los requisitos publicados por Apple para certificados de confianza establecen que un certificado de servidor TLS debe llevar una extensión ExtendedKeyUsage que contenga el OID id-kp-serverAuth. Un certificado sin ella falla en la validación de certificados de macOS bajo la política TLS con el mensaje «Invalid Extended Key Usage for policy», incluso cuando el certificado se proporciona como su propio ancla de confianza. Firefox y Chrome son más tolerantes y tratan la ausencia de ExtendedKeyUsage en un certificado de servidor como algo permitido, así que esto es fácil de pasar por alto hasta que sea un Mac o un iPhone lo que no se conecte. Añadir extendedKeyUsage=serverAuth no cuesta nada en las demás plataformas y es lo que emitiría de todos modos una CA pública.

Paso 4: Rellena los detalles del certificado

OpenSSL pide los campos que forman el Distinguished Name. Pulsa Intro para omitir cualquiera de ellos, pero rellena al menos uno, y que sea el Common Name. La versión de LibreSSL en macOS se detiene con «error, no objects specified in config file» y no escribe nada si dejas todos los campos en blanco. Los valores de abajo son ejemplos, así que usa los tuyos:

• Country Name: el código de dos letras de tu país, por ejemplo US.
• State or Province Name: escrito de forma completa, por ejemplo California.
• Locality Name: tu ciudad, por ejemplo San Jose.
• Organization Name: el nombre de tu empresa o proyecto, por ejemplo Example Inc.
• Organizational Unit Name: el equipo responsable, por ejemplo IT.
• Common Name: el nombre de host principal, por ejemplo example.com. Usa el mismo nombre que pusiste primero en la lista del Subject Alternative Name.
• Email Address: una dirección de contacto, por ejemplo [email protected]. Opcional.

Aquí solo importa realmente el Common Name, y únicamente como etiqueta: la comparación del nombre de host la realiza el Subject Alternative Name que ya has establecido en la línea de comandos. Todo lo demás es descriptivo.

Notarás que el comando nunca pide una challenge password. Ese aviso pertenece a las solicitudes de firma de certificado, y es un campo vestigial que las CA generalmente ignoran o rechazan. Como este comando produce un certificado terminado en lugar de una solicitud, el aviso no aparece en absoluto.

Paso 5: Verifica el certificado antes de usarlo

No te saltes este paso. Un certificado autofirmado puede generarse correctamente y, sin embargo, no ser utilizable, y el fallo solo aparece más tarde como un error del navegador. Lee de nuevo el certificado:

openssl x509 -in certificate.crt -noout -text

En el bloque de extensiones X509v3 estás buscando exactamente tres cosas:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Extended Key Usage:
    TLS Web Server Authentication

Si falta la línea del Subject Alternative Name, el certificado no coincidirá con ningún nombre de host. Si Basic Constraints indica CA:TRUE, Firefox se detendrá en él. Si falta la línea de Extended Key Usage, las plataformas de Apple rechazarán el certificado. En cualquiera de esos casos, elimina los dos archivos y ejecuta el comando de nuevo con las tres opciones -addext presentes.

En OpenSSL 3.x puedes pedir solo esas extensiones en lugar de leer todo el certificado:

openssl x509 -in certificate.crt -noout -ext subjectAltName,basicConstraints,extendedKeyUsage

El indicador -ext no existe en la versión de LibreSSL que incluye macOS, que informa «unknown option -ext». En un Mac sin modificar, usa la versión con -text de arriba.

Para confirmar que el certificado y la clave pertenecen entre sí, compara sus módulos. Los dos comandos deben imprimir el mismo hash:

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

El certificado en sí es un archivo de texto. Al abrirlo en un editor de texto se muestra un bloque en base64 entre las líneas BEGIN CERTIFICATE y END CERTIFICATE, que es lo que pegas en los paneles de control que piden el certificado en lugar de una carga de archivo.

Variantes del comando

Generarlo sin ningún aviso

Para scripts y pipelines de CI, proporciona el Distinguished Name con -subj y el comando se ejecuta sin intervención:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Usar una clave EC en lugar de RSA

Las claves de curva elíptica son más pequeñas y rápidas que RSA con una fortaleza equivalente, y todos los navegadores actuales las admiten. P-256 es la opción estándar:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

El resultado está firmado con ecdsa-with-SHA256. Quédate con RSA si tienes que dar soporte a clientes embebidos antiguos o versiones antiguas de Java, que a veces carecen de soporte para EC.

Usa OpenSSL genuino para esto. La versión de LibreSSL en macOS acepta el comando, pero escribe la curva en el certificado como un conjunto completo de parámetros explícitos en lugar del identificador estándar P-256. El RFC 5480 establece que la forma explícita no debe usarse en certificados, y el propio macOS rechaza un certificado codificado de esa forma.

Comprueba el resultado con openssl x509 -in certificate.crt -noout -text: quieres ver una línea que diga «ASN1 OID: prime256v1», no un bloque que enumere Prime, A, B y Generator. En un Mac sin modificar, usa el comando RSA anterior o instala OpenSSL primero a través de Homebrew.

¿-nodes o -noenc?

Ambos indicadores hacen lo mismo: evitan que OpenSSL cifre la clave privada con una contraseña. OpenSSL 3.x añadió -noenc como el nombre más claro y marca -nodes como obsoleto, aunque todavía lo acepta. LibreSSL, que es lo que incluye macOS, no reconoce -noenc en absoluto y da un error.

Esta guía usa -nodes porque es la opción que funciona en cualquier compilación que probablemente encuentres, incluido un Mac sin modificar. Si estás en OpenSSL 3.x y quieres evitar la ortografía obsoleta, cambia a -noenc. Nada más cambia.

Si eliminas el indicador por completo, OpenSSL cifra la clave con una contraseña que tú elijas, y tu servidor web te la pedirá entonces en cada reinicio. Eso raramente es lo que quieres para un certificado de desarrollo.

Haz que tu máquina confíe en el certificado

Un certificado autofirmado correcto sigue produciendo una advertencia del navegador, porque no se le ha indicado a nada que confíe en él. Añadirlo a tu almacén de confianza local es lo que desactiva la advertencia, y suele ser el propósito de crear uno en primer lugar.

Haz esto solo en máquinas que controlas, y solo para certificados que has generado tú mismo. Un certificado de confianza es de confianza para todos los sitios que nombra, así que trata la clave privada en consecuencia y nunca la compartas.

Llavero de macOS

Añade el certificado al llavero del sistema y márcalo como de confianza para TLS. Se te pedirá tu contraseña de administrador:

sudo security add-trusted-cert -d -r trustRoot -p ssl -k /Library/Keychains/System.keychain certificate.crt

La parte -p ssl limita la confianza a las conexiones TLS. Si la omites, el certificado será de confianza para cualquier propósito que macOS reconozca, incluida la firma de código, que es mucho más de lo que necesita un certificado de desarrollo.

Para hacerlo a través de la interfaz en su lugar, haz doble clic en el archivo del certificado para abrir Acceso a Llaveros, busca la entrada en el llavero Sistema, ábrela, expande Confianza y ajusta Al usar este certificado a Siempre confiar. Para deshacerlo más tarde, elimina la entrada de Acceso a Llaveros.

Almacén de certificados de Windows

Abre el Símbolo del sistema como administrador (pulsa Win + R, escribe cmd, y luego pulsa Ctrl + Shift + Enter) y añade el certificado al almacén de Entidades de certificación raíz de confianza:

certutil -addstore -f "Root" certificate.crt

Alternativamente, haz doble clic en el archivo del certificado, elige Instalar certificado, selecciona Máquina local, luego Colocar todos los certificados en el siguiente almacén, y navega hasta Entidades de certificación raíz de confianza. Para eliminarlo más tarde, abre certmgr.msc y elimina la entrada de ese almacén.

ca-certificates en Linux

En Debian y Ubuntu, copia el certificado al directorio local de anclas y reconstruye el paquete. El archivo tiene que mantener una extensión .crt o la herramienta de actualización lo ignorará:

sudo cp certificate.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

En RHEL, CentOS, AlmaLinux, Rocky y Fedora, las rutas son distintas:

sudo cp certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

La excepción de Firefox

Firefox mantiene su propio almacén de confianza en lugar de usar el del sistema operativo. En Windows y macOS también lee, por defecto, las raíces añadidas al almacén del SO, así que los pasos anteriores normalmente lo cubren. En Linux no es así, por lo que el certificado tiene que importarse directamente en Firefox: abre Configuración, luego Privacidad y seguridad, desplázate hasta Certificados, haz clic en Ver certificados, abre la pestaña Autoridades y usa Importar.

Reinicia el navegador después de cualquiera de estos cambios. Los navegadores almacenan en caché las decisiones sobre certificados, y una sesión desactualizada es una razón habitual por la que la advertencia parece persistir después de una importación correcta.

Cuándo no usar un certificado autofirmado

Nunca pongas uno en un sitio que vaya a visitar el público. Cada visitante recibe una advertencia de seguridad a pantalla completa, y quienes continúan de todos modos han sido entrenados para hacer clic exactamente en la advertencia que los protege de un ataque real. Tampoco hay forma de que un visitante distinga tu certificado autofirmado del de un atacante, que es precisamente la razón por la que los navegadores desconfían de ellos. Entramos en los detalles en nuestro artículo sobre los peligros de los certificados autofirmados.

Los certificados autofirmados también incumplen requisitos prácticos más allá de la advertencia del navegador. Los procesadores de pagos, las tiendas de aplicaciones, las aplicaciones móviles con fijación de certificados (certificate pinning) y la mayoría de los regímenes de cumplimiento exigen un certificado de una CA reconocida. Para cualquier cosa orientada al público, usa un certificado emitido por una autoridad de certificación de confianza, que solicitas con un CSR y validas antes de la emisión. Una vez esté activo, confirma la instalación con nuestro SSL Checker.