Certificado de ssl: requisitos y cómo sacarlo online

Certificado de SSL y su papel en la seguridad web

Un certificado SSL es un certificado digital basado en el estándar X.509 que vincula la identidad de un dominio con una clave pública. Este formato y sus extensiones están definidos en el perfil de infraestructura de clave pública de Internet, ampliamente utilizado en la Web. En la práctica, el certificado permite establecer conexiones HTTPS seguras mediante el protocolo TLS, que protege la confidencialidad e integridad de los datos y evita suplantaciones durante el intercambio entre cliente y servidor.

Certificado SENCE
Certificado INACAP
Certificado FONASA 

Relación entre ssl y tls

Hoy, cuando decimos “certificado SSL” casi siempre nos referimos a certificados para TLS, la evolución directa de SSL. TLS incorpora mejoras sustanciales en seguridad y rendimiento, y es el protocolo que efectivamente usan los navegadores modernos para cifrar el tráfico HTTPS.

Cómo funciona la cadena de confianza

La confianza en la Web no depende de un único archivo: los navegadores verifican la cadena completa que va desde tu certificado de servidor hasta un certificado intermedio y, finalmente, un certificado raíz de una autoridad de certificación (CA) incluida en el almacén de confianza del sistema. Enviar una cadena incompleta suele provocar advertencias o calificaciones bajas en pruebas públicas.

Tipos de certificados y niveles de validación

Aunque todos los certificados válidos pueden cifrar el tráfico, difieren en cómo verifican la identidad del titular. Esta verificación la dictan normas públicas y políticas de cada CA.

Validación de dominio

Comprueba que controlas el dominio (por ejemplo, respondiendo un desafío HTTP, DNS o TLS definido por el protocolo de automatización ACME). Es el tipo más rápido y habitual para sitios y APIs que no requieren mostrar datos de empresa en el certificado.

Validación de organización

Añade verificación de la entidad legal que solicita el certificado: razón social, dirección y un teléfono verificable; normalmente incluye una llamada o verificación de contacto corporativo. Útil para reforzar la confianza en sitios de empresas y portales transaccionales.

Validación extendida

Implica un proceso más estricto de verificación legal y operacional de la organización, conforme a las directrices de referencia de la industria. Aunque los navegadores ya no resaltan como antes las diferencias visuales, EV sigue siendo una opción para sectores regulados con requisitos de identificación reforzada.

Certificados comodín y multidominio

Un comodín cubre todos los subdominios de un nivel de un mismo dominio base; los certificados multidominio usan la extensión Subject Alternative Name para listar varios FQDN en un único certificado. La identificación del servicio mediante subjectAltName está estandarizada y es el método recomendado para que los clientes validen el nombre del servidor.

Requisitos previos antes de solicitar un certificado

Para evitar rechazos y acelerar la emisión, confirma lo siguiente:

• Control del dominio y acceso al DNS público o al contenido web para completar los desafíos de validación.
• Un servidor o servicio capaz de presentar el certificado y clave privada, o un proveedor gestionado que haga de terminador TLS.
• Una solicitud de firma de certificado (CSR) correcta, con el nombre común y los subjectAltName que vas a usar, y claves de tamaño adecuado.
• Opcional pero recomendable: un registro CAA en DNS que indique qué CAs pueden emitir para tu dominio; esto evita emisiones no autorizadas.

Creación de la solicitud de firma

En servidores tipo Unix, la vía clásica consiste en generar una clave y un CSR con OpenSSL. Este CSR contendrá los atributos del sujeto y las extensiones necesarias:

# Ejemplo ilustrativo de CSR con OpenSSL openssl req -new -newkey rsa:2048 -nodes -keyout dominio.key -out dominio.csr # Para incluir subjectAltName, usa un archivo de configuración y -config 

Los campos del certificado y extensiones se describen en el perfil X.509 de uso en Internet.

Control del dominio con desafíos automáticos

Muchas CAs modernas usan ACME, un protocolo que automatiza la validación y emisión: coloca un archivo de desafío en tu servidor web, publica un registro temporal en tu DNS o responde a un desafío en la capa de aplicación. Esto facilita renovaciones frecuentes y reduce errores humanos.

Consideraciones sobre registros caa

Si configuras CAA, asegúrate de incluir la CA con la que emitirás; de lo contrario, la validación fallará. Varias CAs documentan cómo consultan CAA antes de emitir.

Formas comunes de obtener un certificado por internet

Existen múltiples vías, desde CA gratuitas automatizadas hasta plataformas gestionadas en la nube o tu propio panel de hosting. Lo clave es elegir el flujo más simple y seguro para tu contexto.

Emisión ágil con automatización

Un enfoque muy extendido es usar una CA gratuita que emite certificados de corta duración y promueve la renovación automática. Sus certificados estándar tienen una vigencia de noventa días y están pensados para automatizar la seguridad por defecto.

Instalación en apache o nginx con linux

En entornos Linux, un cliente ACME instala y renueva automáticamente. El flujo típico es: elegir el cliente, autorizar el dominio y hacer que el software configure el servidor y agende renovaciones. Este proceso está respaldado por el protocolo ACME, que describe la verificación y la emisión automatizada.

Instalación en windows con iis

En Windows, win-acme es un cliente ACME sencillo para IIS. Permite generar el certificado, instalarlo en el almacén del sistema, enlazarlo a los sitios de IIS y programar la renovación desatendida con el programador de tareas. La guía oficial ofrece pasos de inicio y referencias para enlazar los sitios y ajustar los bindings.

Emisión comodín y validación por dns

Para certificados comodín en ACME, se recurre normalmente al desafío DNS, que consiste en publicar un registro TXT temporal. Muchos clientes ACME integran automatizaciones con proveedores DNS para crear y eliminar estos registros.

Emisión con paneles de hosting

Si usas paneles de control, suele bastar con activar un módulo que se ocupa de emitir, instalar y renovar.

Activación en cpanel

AutoSSL instala certificados DV para los dominios alojados y renueva automáticamente antes del vencimiento. Hay documentación detallada y soporte para distintos servicios del servidor.

Activación en plesk

Plesk ofrece una extensión que mantiene tus dominios asegurados con certificados de confianza, con posibilidad de proteger también el propio panel y el correo. Los administradores pueden habilitarlo por plan de hosting y automatizar el reemplazo de certificados caducos o no confiables.

Emisión en cdn y nubes

Muchas plataformas gestionan certificados sin intervención manual.

Activación universal en una cdn popular

Al mover tu DNS y tráfico a una CDN ampliamente usada, se emiten certificados DV gratuitos de forma automática para tu dominio y se renuevan sin que tengas que gestionar claves o CSR. También es posible optar por certificados avanzados o subir tus propios certificados cuando necesitas control fino. La documentación oficial refleja el alcance y las limitaciones.

Certificado SENCE
Certificado INACAP
Certificado FONASA 

Buenas prácticas de instalación y configuración

Emitir el certificado es el comienzo; lo crucial es presentarlo con una configuración robusta y actualizada en tu servidor o plataforma.

Selección de protocolos y suites de cifrado

La comunidad de seguridad mantiene guías vivas con configuraciones recomendadas para diferentes servidores y niveles de compatibilidad. Estas guías indican qué protocolos habilitar, qué suites priorizar y cómo activar características modernas para lograr un equilibrio entre seguridad y compatibilidad. El generador de configuraciones de Mozilla es un recurso de referencia.

Encabezados de seguridad y hsts

Además del cifrado, refuerza la política de navegación forzando HTTPS con HTTP Strict Transport Security y añadiendo cabeceras modernas. La documentación para desarrolladores explica cómo implementarlo y qué consideraciones tener en cuenta.

Pruebas públicas de configuración

Tras instalar y configurar, analiza tu servidor con pruebas públicas que revisan protocolo, cadena de certificados, compatibilidad, soporte de funciones y vulnerabilidades conocidas. Una de las herramientas más reconocidas es la prueba de servidores de SSL Labs; apunta tu dominio y procura alcanzar una calificación alta ajustando tu configuración según el informe.

Solución de problemas habituales

Si el candado no aparece o ves advertencias, revisa estas causas comunes.

Cadena de certificados incompleta

Ocurre cuando el servidor entrega solo tu certificado y omite los intermedios. Corrígelo sirviendo el archivo que concatena tu certificado y los intermedios proporcionados por la CA. En clientes ACME conocidos, ese archivo suele denominarse fullchain.pem. Pruebas públicas como SSL Labs resaltan este problema con claridad.

Fallo en la validación de dominio

Comprueba que el desafío esté disponible donde corresponde: la ruta HTTP pública, el registro TXT en DNS o el punto de terminación para el desafío en la capa de aplicación. Muchos fracasos se deben a cachés DNS, proxys o despliegues que redirigen el tráfico impidiendo que la CA vea el desafío. El propio protocolo ACME detalla estos flujos.

Conflictos de configuración

En servidores con varios sitios, a veces el certificado se instala en un bloque de servidor equivocado o se sirve un archivo distinto al configurado. Audita las rutas de los archivos, las directivas de tu servidor y vuelve a probar con una herramienta externa para confirmar.

Mantenimiento y renovación continua

La seguridad del sitio depende de mantener certificados y protocolos al día.

Renovación automatizada y vigencia corta

Una práctica consolidada es usar certificados de corta vigencia con renovación automática. La documentación oficial recomienda renovar antes del vencimiento, y explica por qué adoptar periodos breves reduce el riesgo si una clave se ve comprometida o se emite por error.

Pruebas periódicas y observación

Programa comprobaciones regulares con herramientas públicas y aplica las actualizaciones que te sugieran. El generador de configuraciones y las guías técnicas se actualizan de forma continua para reflejar buenas prácticas modernas.

Revocación y transparencia

Conserva control de tus claves privadas y utiliza mecanismos de revocación si sospechas un compromiso. Las CAs modernas registran emisiones en bitácoras de transparencia, lo que permite auditar y detectar emisiones inesperadas; al elegir proveedor, confirma que cumpla estas prácticas públicas.

Guías rápidas según plataforma

Estas rutas resumen caminos confiables para “sacarlo online” minimizando fricción y errores.

Ruta de bajo esfuerzo en panel de hosting

Activa el módulo de emisión y renovación automática en tu panel. En cPanel, AutoSSL gestiona el ciclo completo; en Plesk, la extensión dedicada protege dominios, subdominios y el propio panel, con reemplazo automático de certificados caducados o no confiables.

Ruta con cdn gestionada

Si mueves tu sitio a una CDN de amplio alcance, obtendrás certificados DV para el perímetro sin gestionar CSR, claves ni renovaciones. Consulta límites y opciones de personalización cuando necesites cubrir subdominios profundos o políticas de cifrado específicas.

Ruta devops con automatización

Integra un cliente ACME en tu flujo de despliegue para emitir y renovar automáticamente. En Windows con IIS, win-acme ofrece asistentes y opciones de línea de comandos para manejar enlaces y renovaciones sin intervención.

Recomendaciones de seguridad complementarias

Más allá del certificado, robustece tu superficie:

Políticas de seguridad en el navegador

Refuerza con cabeceras como HSTS y otras directivas modernas. Revisa la guía de implementación para aplicar las políticas sin romper contenido heredado y planifica migraciones progresivas para evitar mixed content.

Compatibilidad y rendimiento

Selecciona configuraciones que concilien seguridad y compatibilidad con tus usuarios. Las guías de Mozilla ofrecen perfiles moderno e intermedio que equilibran algoritmos actuales con compatibilidad razonable.

Preguntas frecuentes

Qué diferencia práctica hay entre los certificados dv, ov y ev

DV solo verifica control del dominio; OV y EV añaden verificación de la organización mediante registros públicos, contacto telefónico y, en el caso de EV, controles reforzados definidos por la industria. El cifrado es equivalente; la diferencia es el nivel de validación de identidad.

Es mejor rsa o elípticas

Ambas son aceptadas; elige según compatibilidad y rendimiento. Las guías comunitarias recomiendan configuraciones que prioricen seguridad actual con atención a clientes antiguos, y permiten optar por claves elípticas cuando la audiencia lo permite.

Cómo verifico que todo está bien

Usa pruebas públicas que inspeccionan versión de protocolo, suites, soporte de funciones, cadena de certificados y vulnerabilidades conocidas. Ajusta hasta lograr una calificación alta y repite tras cambios mayores.

Por qué algunos certificados de corta vigencia

La vigencia corta, combinada con automatización, reduce el impacto de compromisos de clave y emisiones erróneas, y fomenta prácticas de seguridad modernas.

Lista de verificación para una implementación confiable

• Definir el ámbito: dominios y subdominios que cubrirás con subjectAltName.
• Decidir el nivel de validación según requisitos legales o de confianza de la marca.
• Crear CSR y clave privada con parámetros adecuados y conservarlos con buen gobierno de claves.
• Completar la validación de dominio usando el desafío más conveniente para tu entorno.
• Instalar fullchain e intermedios y revisar que no haya cadena incompleta.
• Aplicar una configuración de servidor recomendada y activar HSTS cuando proceda.
• Probar con herramientas públicas y documentar el proceso de renovación.

Guía avanzada de cumplimiento normativo y cambios recientes en la vigencia de los certificados

Además de saber cómo solicitar e instalar un certificado de servidor, conviene entender el marco normativo que obliga a las autoridades certificadoras y a los navegadores. El documento clave es el de CA/Browser Forum con sus Baseline Requirements, que fijan plazos de vigencia, validaciones permitidas y buenas prácticas para toda la Web PKI pública. La versión vigente del estándar incluye un cronograma de reducción progresiva de la vigencia máxima de los certificados de servidor. En concreto: hasta el 14 de marzo de 2026 se permite una validez máxima de hasta 398 días; desde el 15 de marzo de 2026 y hasta el 14 de marzo de 2027, el máximo baja a 200 días; del 15 de marzo de 2027 al 14 de marzo de 2029, a 100 días; y desde el 15 de marzo de 2029, a 47 días. Este calendario busca incentivar la automatización de renovaciones y mejorar la seguridad operacional.

Para que no haya dudas: si hoy adquieres un certificado con una entidad pública, todavía se aceptan vigencias de hasta 398 días; pero tu estrategia debe asumir que muy pronto serán necesarios ciclos de renovación más frecuentes (y automáticos). Lo mejor es implantar ya herramientas y flujos que no dependan de tareas manuales.

Lectura del requisito de identidad del servidor y uso de nombres alternativos

Otra exigencia importante es la correcta representación de la identidad del servicio. Los clientes modernos verifican el nombre del servidor usando el campo subjectAltName del certificado (SAN), no el campo común clásico. Esto está documentado en la guía del IETF para identidad de servicios sobre TLS, que recomienda “moverse” definitivamente al uso de SAN para nombres DNS. En la práctica, esto significa que cuando generes tu CSR debes incluir todos los dominios y subdominios en el SAN.

Políticas de transparencia y evidencias criptográficas

Los navegadores basados en Chromium exigen que los certificados de servidor incorporen pruebas de auditoría pública llamadas Signed Certificate Timestamps (SCT) emitidas por logs de Certificate Transparency. Estas pruebas pueden ir incrustadas en el certificado, entregarse vía OCSP “stapled” o incluirse durante el apretón de manos TLS. Si tu servidor no presenta SCTs válidos de logs en estado “usable”, el navegador puede marcar tu sitio como no conforme.

Mejores prácticas de configuración y cifrados recomendados

Configurar el servidor de forma segura y compatible es tan importante como obtener el certificado. La referencia más práctica y mantenida por una fuente independiente es la guía de Mozilla con su generador de configuraciones. Allí puedes seleccionar tu servidor (nginx, Apache, HAProxy, Caddy, Traefik, Tomcat, etc.) y optar por perfiles “moderno”, “intermedio” o “antiguo” según la clientela que debas soportar. El perfil intermedio suele ser la opción equilibrada para la mayoría de sitios productivos, y el generador entrega listas de cipher suites, versiones de protocolo y curvas elípticas apropiadas.

Encabezado de seguridad para transporte estricto

Una vez activo HTTPS, fortalece tu postura con HSTS. Este encabezado indica a los navegadores que solo deben conectarse a tu dominio mediante HTTPS y que deben elevar cualquier intento HTTP a HTTPS de forma automática. También endurece el tratamiento de errores de certificado. Antes de habilitar HSTS conviene confirmar que todo tu sitio y subdominios funcionan correctamente bajo TLS, y considerar el registro en la lista de precarga si corresponde a tu caso.

Recomendación sobre vigencia operativa

Aunque el marco normativo permite, por ahora, emitir certificados públicos con cientos de días de vigencia, la práctica recomendada en operación es usar periodos cortos y automatizados. Proyectos como Let’s Encrypt fijan vigencias de 90 días por diseño, precisamente para reducir el riesgo y empujar la automatización con ACME.

Automatización con el protocolo de gestión automática

La automatización es la piedra angular de una operación TLS moderna. El estándar que lo hace posible es el protocolo ACME, publicado por el IETF. ACME define cómo el servidor y la autoridad certificadora interactúan para validar el control del dominio y emitir, renovar o revocar certificados sin intervención manual. Gracias a ACME, hoy es factible mantener cientos o miles de certificados con renovaciones continuas y cero ventanas de riesgo por expiración.

Desafíos para validar el control del dominio

En el flujo ACME puedes demostrar control sobre un nombre de dominio de distintas maneras. Las más comunes son HTTP-01 (colocar un token en una ruta conocida de tu servidor web), DNS-01 (publicar un registro TXT bajo el dominio solicitado) y TLS-ALPN-01 (presentar un certificado especial en el puerto estándar durante la negociación). Elegir el método adecuado depende de tu arquitectura: HTTP-01 es simple si controlas el servidor web; DNS-01 es ideal para comodines y entornos distribuidos; TLS-ALPN-01 resulta útil cuando no puedes exponer archivos HTTP.

Implementaciones y ecosistema

ACME no es exclusivo de una organización: existen múltiples clientes y extensiones. En entornos Windows con IIS, win-acme automatiza la emisión y renovación, con validaciones HTTP y DNS integradas. En paneles de hosting, AutoSSL de cPanel y la extensión Let’s Encrypt de Plesk habilitan certificados para cada sitio con uno o dos clics. En Kubernetes, cert-manager actúa como controlador que resuelve desafíos ACME y gestiona recursos Issuer y Certificate para renovar de forma continua.

Respuesta en línea de estado y optimizaciones de revocación

Los navegadores verifican si un certificado fue revocado. Hacerlo consultando a la CA en cada visita (OCSP “en línea”) afecta la privacidad y el rendimiento. Por eso existe OCSP stapling: tu servidor consulta periódicamente a la CA y “engrampa” la respuesta OCSP válida durante el apretón de manos TLS, evitando latencia adicional para tus usuarios y sin filtrar sus hábitos de navegación a terceros. Considera también el uso de la extensión “Must-Staple” si tu público objetivo lo soporta y tu servidor mantiene el stapling correctamente.

Configuración en servidores web populares

En Apache y nginx, habilitar OCSP stapling requiere activar directivas de uso y caché, así como asegurar que la cadena de certificados y la raíz intermedia estén completas. Es recomendable monitorear la validez de las respuestas y activar alarmas si expiran.

Autenticación mutua para servicios críticos

Además del típico esquema donde el servidor se autentica ante el cliente, TLS permite autenticación de cliente mediante certificados, conocida como mTLS. En escenarios B2B, APIs sensibles o redes internas con alta criticidad, mTLS añade una barrera fuerte: el servidor solicita un certificado al cliente; si el cliente no lo presenta o no pertenece a una CA de confianza definida, la conexión se rechaza. Esta capacidad está definida y soportada en la especificación del protocolo moderno.

Experiencia de usuario y despliegue responsable

mTLS incrementa el peso operativo: hay que emitir, distribuir y rotar certificados cliente, definir políticas de confianza por organización o por entorno, y considerar el soporte en aplicaciones móviles y dispositivos. Evalúa cuidadosamente si el riesgo y la normativa de tu sector justifican esta capa adicional.

Gestión de políticas de emisión con registros de autorización

Para evitar emisiones no autorizadas, publica registros DNS de tipo CAA. Con CAA, declaras qué autoridades pueden emitir certificados para tu dominio y, opcionalmente, especificas correos de reporte o directivas avanzadas. Las CAs públicas deben consultar y respetar estos registros antes de aprobar una solicitud, lo que reduce el riesgo de errores u órdenes fraudulentas.

Integración con automatización

Si utilizas ACME con múltiples CAs, establece CAA que reflejen esa realidad, y sincroniza los cambios cuando añadas o retires proveedores. No olvides probar la resolución DNS desde infraestructura externa para confirmar que la CAA es visible fuera de tu red.

Deprecaciones y prácticas a evitar

La fijación de claves pública en cabecera HTTP, conocida como HPKP, quedó obsoleta y desaconsejada por su complejidad y riesgo de bloqueo accidental. Si llegaste a usarla, retírala y confía en CT, HSTS, CAA y en la gestión adecuada de cadenas y rotación.

Pasos accionables para un despliegue profesional

Plan de ciclo de vida y automatización

Define un inventario de dominios y subdominios, declara propietarios y ventanas de mantenimiento, y habilita ACME con renovaciones automáticas. Si tu servidor es Linux con nginx o Apache, apóyate en configuradores y guías reputadas; si es Windows con IIS, considera clientes nativos para ese ecosistema; si estás en Kubernetes, usa controladores que integren emisores y certificados como recursos nativos.

Verificación continua de configuración

Somete tu endpoint a pruebas públicas y privadas. Herramientas como el generador de Mozilla y su wiki, además de verificadores de terceros, te ayudan a confirmar protocolos habilitados, suites de cifrado, HSTS, stapling y SCTs. Mantén alertas sobre expiración y revocación y registra cambios en repositorio para auditoría.

Preguntas frecuentes para contextos empresariales

Elección entre curvas elípticas y claves clásicas

Para la mayoría de despliegues orientados a público general, certificados ECDSA sobre P-256 con TLS moderno ofrecen buen rendimiento y seguridad. Si necesitas compatibilidad amplia con sistemas antiguos, aún puedes usar RSA con al menos 2048 bits y suites autenticadas y confidenciales. Revisa la tabla de compatibilidad del perfil intermedio antes de decidir.

Compatibilidad de clientes y versiones del protocolo

El objetivo mínimo debería ser TLS moderno con compatibilidad hacia atrás solo cuando sea imprescindible. Si tu negocio atiende clientes actualizados, el perfil moderno proporciona una superficie de ataque menor y un desempeño superior, con conjuntos de cifrado autenticados y con secreto perfecto hacia adelante.

Revisión previa al pase a producción

• Certificado emitido para todos los nombres en SAN, sin depender del nombre común.
• Vigencia alineada con el calendario normativo y con automatización de renovación en producción.
• Configuración de servidor basada en perfiles recomendados y validada con pruebas externas.
• HSTS activo y evaluado, considerando precarga cuando sea pertinente.
• OCSP stapling habilitado, con monitoreo de la validez de respuestas y cadena completa.
• Registros CAA publicados y probados desde fuera de tu red.
• Transparencia de certificados verificada con presencia de SCTs válidos.
• Procedimientos para revocación y rotación de claves documentados y probados.

Plan de mejora continua

La seguridad de transporte evoluciona. Reserva mantenimiento para revisar anualmente las recomendaciones de Mozilla, las políticas de CT y las actualizaciones de los Baseline Requirements. Anticípate a los cambios de vigencia recortando la dependencia en tareas manuales y expandiendo el uso de ACME en todos tus perímetros.