Generador de certificados autofirmados
Un certificado y su clave privada para un servicio interno, sin memorizar una invocación de openssl: introduce el nombre común, enumera cada nombre e IP que el certificado debe cubrir, elige la validez y el tamaño de clave, y descarga ambos archivos PEM. Las claves se generan localmente en tu navegador y nunca se suben: esta página no hace ninguna petición de red, y la clave existe solo en tu pestaña hasta que la guardas.
Las claves más grandes tardan más en generarse: 4096 bits puede llevar un rato en una máquina modesta. El trabajo ocurre en tu máquina, en esta pestaña: déjala abierta y deja que termine.
Autofirmado: el sujeto y el emisor coinciden, así que ninguna autoridad pública respalda este certificado. Los navegadores avisarán hasta que se añada al almacén de confianza de las máquinas que lo usan.
- Nombres cubiertos (SAN)
- Válido desde
- Válido hasta
- Huella SHA-256
Certificado (PEM)
Clave privada (PEM): mantenla en secreto
Instala ambos archivos en el servidor (el certificado y la clave como pareja), restringe los permisos del archivo de la clave a la cuenta del servicio y anota la fecha de caducidad en un sitio donde la veas: un certificado interno que caduca en silencio es una caída clásica autoinfligida. El analizador de certificados vuelve a leer el certificado generado si quieres comprobar lo que desplegaste, y el comprobador de certificado y clave demuestra que la pareja descargada va junta: agrupa los archivos por su clave pública compartida, de modo que una clave sobrante de una pareja anterior no puede colarse en el despliegue sin que se note.
Para qué sirve un certificado autofirmado
Un certificado autofirmado es un certificado cuyo emisor y cuyo sujeto son el mismo: avala por sí mismo. Suena a defecto, y para la web pública lo es: el navegador de un visitante no tiene motivos para creer la palabra de un desconocido. Pero gran parte del TLS nunca se enfrenta al público: paneles internos, entornos de laboratorio y de pruebas, servicios de laboratorio doméstico, interfaces de administración de equipos de red y el tráfico entre servicios dentro de una misma organización. Para eso, el público son máquinas que controlas, y la pregunta de la confianza tiene otra respuesta: instalas el certificado (o tu propia CA pequeña) en los almacenes de confianza que gestionas, una vez, deliberadamente. A cambio obtienes cifrado e identidad dentro de tus propios muros sin que una CA pública conozca jamás tus nombres de host internos, nombres que son, en sí mismos, un mapa de tu infraestructura.
El ritual de generación solía ser un comando de openssl que nadie recordaba y todo el mundo copiaba y pegaba, con los SAN atornillados mediante un archivo de configuración porque el parámetro para ellos no existía en las versiones antiguas. Esta página existe para que la forma del certificado sea visible: los nombres son una lista que puedes leer, la validez es un número de días que eliges sabiendo que caducará, y el tamaño de clave es una decisión en lugar de un valor por defecto que nunca notaste. Lo que deliberadamente no hace es fingir que es una CA: no hay cadena, ni intermediario, ni nada que revocar. Un servicio, un certificado, una fecha de caducidad de la que llevar la cuenta.
Cómo hacer que los clientes lo acepten
Generar el certificado es la mitad fácil; la confianza es el despliegue. En un puñado de máquinas tuyas, añadir el certificado al almacén de confianza del sistema operativo (o del navegador) acaba con los avisos para siempre, y herramientas como curl y git aceptan un puntero --cacert por comando en lugar del peligroso hábito de desactivar la verificación: la opción -k entrena a todo el mundo para ignorar justo el aviso que detectaría un ataque real. Cuando el público crece más allá de un puñado de máquinas, pasa de los certificados autofirmados sueltos a una pequeña CA privada: firma con ella los certificados de servicio, distribuye solo el certificado de la CA y la rotación deja de ser una gira por cada cliente. Y cuando un servicio resulta estar orientado al público después de todo, sustituye el certificado por uno de confianza pública: el comprobador SSL verifica lo que un servidor presenta realmente una vez en producción, que es el momento en que lo autofirmado deja de ser una opción.
Herramientas relacionadas: vuelve a leer cualquier certificado con el analizador de certificados SSL, o comprueba lo que presenta un servidor en vivo con el comprobador SSL.
Lectura adicional: una rutina de fiabilidad: por qué los certificados internos y sus fechas de caducidad pertenecen a la misma página de planificación que las rotaciones y las copias de seguridad.
La generación de certificados usa node-forge, bajo la licencia BSD-3-Clause, y se carga solo cuando pulsas Generar. Ninguna parte de esta herramienta hace una petición de red.
Preguntas frecuentes
¿Dónde debería usar un certificado autofirmado?
En cosas con las que solo habláis tú y tus propios sistemas: paneles internos, entornos de laboratorio y de pruebas, servicios de laboratorio doméstico, páginas de administración de dispositivos y como marcador que permite a un servidor arrancar antes de que se emita un certificado real. La regla es el alcance: si el navegador de un desconocido lo verá alguna vez, necesita en su lugar un certificado de confianza pública; esos son gratuitos en Let’s Encrypt.
¿Por qué los navegadores avisan sobre los certificados autofirmados?
Porque «autofirmado» significa que el único que avala el certificado es él mismo. El cifrado funciona —la conexión es privada—, pero nada demuestra que el servidor sea quien dice ser, que es la mitad del TLS que normalmente aporta una autoridad de certificación. Por eso los navegadores avisan hasta que el certificado (o una CA que controlas) se añade al almacén de confianza de las máquinas que lo usan.
¿Por qué el nombre común aparece también en la lista de SAN?
Los navegadores modernos ignoran por completo el campo del nombre común y comprueban en su lugar la lista de nombres alternativos del sujeto. Un certificado cuyo nombre principal no está en su propia lista de SAN falla en el mismo nombre para el que se creó —el error de autofirmado más común—, así que esta página añade siempre el nombre común a los SAN.
¿Basta con RSA de 2048 bits o debería elegir 4096?
RSA de 2048 bits es la base actual y es suficiente para servicios internos; es lo que siguen usando la mayoría de los certificados públicos. 4096 bits compra margen frente a futuros criptoanálisis a costa de una generación más lenta y apretones de manos ligeramente más lentos. Tiene sentido para una CA interna de larga vida o un servicio que no puedas reemitir con facilidad. La generación ocurre en tu propia máquina en cualquier caso: 4096 bits puede llevar un rato, y la pestaña está trabajando, no bloqueada.
¿Es seguro generar una clave privada en una página web?
En esta página, sí, por cómo está construida: el par de claves se genera localmente en tu navegador con la biblioteca node-forge, la página no hace ninguna petición de red y nada de lo que generas se sube, se registra ni se almacena. Aun así, el hábito general merece la pena: genera claves solo en páginas (y máquinas) en las que confíes, y trata el archivo de la clave privada como un secreto desde el momento en que existe.