Tipos de certificados SSL: elige el adecuado
Publicado el 30 de septiembre de 2026
El certificado SSL adecuado cumple dos funciones a la vez: cifra el tráfico entre un visitante y tu servidor, y presenta la identidad que tus visitantes necesitan para confiar. Los tipos de certificados SSL se diferencian principalmente en cómo se valida esa identidad y cuántos nombres de host cubren. Para la mayoría de los sitios, elegir correctamente tiene menos que ver con la criptografía y más con adaptar la cobertura y la validación del certificado a la forma en que funciona realmente el servicio.
Un pequeño sitio informativo, una página de pago, una plataforma SaaS multiinquilino y una agencia que gestiona 40 dominios de clientes pueden utilizar los mismos estándares de cifrado TLS. No deberían utilizar automáticamente el mismo certificado. El servicio funciona de forma más tranquila cuando el plan del certificado coincide con el plan de infraestructura.
Tipos de certificados SSL según el nivel de validación
El nivel de validación determina qué comprueba la autoridad certificadora antes de emitir el certificado. Todo certificado válido cifra la conexión. La diferencia está en el grado de verificación de identidad que lo respalda y, en algunos casos, en la información que se muestra en los detalles del certificado.
Certificados validados por dominio
Un certificado validado por dominio, o DV, confirma el control de un nombre de dominio. La autoridad certificadora normalmente te pide que añadas un registro DNS, subas un archivo de verificación o apruebes un correo enviado a una dirección autorizada. Una vez superada esa comprobación, la emisión puede ser muy rápida.
DV es una opción práctica para blogs, páginas de destino, entornos de desarrollo, API, herramientas internas expuestas mediante un dominio y muchos sitios web empresariales estándar. Proporciona a los visitantes el candado HTTPS y cifra las credenciales, los formularios, las sesiones y el resto del tráfico durante el tránsito.
La desventaja es sencilla: DV no verifica la empresa legal que está detrás del sitio web. Un visitante puede ver que su conexión está cifrada y que el sitio controla el dominio, pero no recibe de la autoridad certificadora una identidad de organización verificada por separado. Para muchas empresas, esto es perfectamente adecuado.
Certificados validados por organización
Los certificados validados por organización, u OV, requieren que la autoridad certificadora compruebe tanto el control del dominio como la organización que solicita el certificado. Normalmente esto implica verificar los datos de registro de la empresa, la información de la dirección y un método de contacto confirmado.
Los certificados OV son adecuados para empresas consolidadas, portales B2B, sitios de agencias, plataformas de compras y áreas de clientes donde la identidad de la organización tiene importancia. La información de la organización verificada está disponible en los detalles del certificado, lo que puede respaldar conversaciones de diligencia debida con clientes empresariales o equipos de seguridad.
El cifrado no es más potente que el de DV únicamente porque el certificado sea OV. La protección TLS moderna depende de la configuración del servidor, las versiones de protocolo compatibles, las suites de cifrado y el tipo de clave del certificado. OV añade un proceso de garantía de identidad más exigente, no un cifrado mágico adicional. Sigue siendo útil, pero no es brujería.
Certificados con validación extendida
Los certificados con validación extendida, o EV, implican el proceso de validación más detallado. La autoridad certificadora comprueba la existencia legal de la organización, su estado operativo, su dirección física y el solicitante autorizado conforme a reglas definidas.
EV puede tener sentido para organizaciones reguladas, servicios financieros, marcas de comercio electrónico de alto valor y empresas con requisitos formales de compras o cumplimiento normativo. También puede solicitarlo un socio que tenga su propia lista de comprobación de seguridad de proveedores.
Para un sitio web de una pequeña empresa típica, EV no es automáticamente la mejor inversión. Los navegadores modernos ya no ofrecen la barra de direcciones verde y muy visible que antes hacía destacar a EV ante los usuarios habituales. Elígelo cuando su proceso de validación responda a una necesidad real de confianza, contractual o de políticas, no porque esperes un aumento espectacular y visible de las conversiones.
Tipos de certificados SSL según la cobertura de dominios
Después de la validación, la cobertura es la siguiente decisión. Aquí es donde más suelen equivocarse las compras de certificados. Un certificado puede ser válido y estar correctamente instalado, y aun así fallar para un nombre de host para el que nunca se emitió protección.
Certificados para un solo dominio
Un certificado para un solo dominio protege un nombre de dominio completo, como `www.example.com` o `app.example.com`. Según la configuración del certificado, el dominio raíz y la versión `www` pueden requerir una cobertura independiente. Nunca des por hecho que ambos están incluidos sin comprobar los nombres alternativos del sujeto del certificado, normalmente denominados SAN.
Los certificados para un solo dominio son sencillos y fáciles de gestionar para un servicio. Son adecuados cuando una aplicación tiene un nombre de host dedicado y un ciclo de renovación independiente.
Certificados comodín
Un certificado comodín protege un dominio y sus subdominios de primer nivel, como `shop.example.com`, `api.example.com` y `status.example.com`, mediante un nombre como `*.example.com`. Es útil para plataformas donde se añaden subdominios con regularidad, incluidas implementaciones de agencias, portales de clientes y entornos SaaS en expansión.
Hay un límite que suele sorprender: `*.example.com` no protege `example.com` a menos que el dominio raíz se incluya por separado, y tampoco cubre `east.api.example.com`. Los comodines cubren un solo nivel de subdominio. No es la situación DNS más agradable de descubrir durante un lanzamiento, así que asigna los nombres de host antes de realizar el pedido.
Los certificados comodín suelen requerir validación basada en DNS, porque demostrar el control de un dominio comodín necesita un desaf ío DNS. Normalmente es sencillo cuando el acceso DNS está organizado, pero debe tenerse en cuenta antes de seleccionar un flujo de trabajo de renovación automatizada.
Certificados multidominio o SAN
Un certificado multidominio, también llamado certificado SAN, protege varios nombres de host específicos en un solo certificado. Por ejemplo, un certificado puede cubrir `example.com`, `www.example.com`, `app.example.net` y `customer.example.org`.
Esto resulta útil para empresas que gestionan varias marcas, agencias que alojan servicios relacionados de clientes o equipos que necesitan un certificado controlado para un grupo definido de endpoints. Puede reducir la proliferación de certificados, pero también crea una dependencia compartida. Si sustituyes o revocas ese certificado, todos los nombres de host cubiertos pueden verse afectados.
En entornos grandes, separar los certificados por aplicación, unidad de negocio o responsable de renovación puede ser más seguro desde el punto de vista operativo. Menos certificados no siempre significa menos trabajo cuando un cambio tiene un radio de impacto amplio.
Cómo elegir el certificado adecuado
Empieza por los nombres de host, no por el nombre del producto. Enumera cada dominio público, nombre `www`, endpoint de API, portal de administración, endpoint relacionado con el correo y subdominio planificado que necesite TLS. Después, decide si esos nombres son fijos, si crecerán de forma impredecible o si los gestionan equipos diferentes.
Un certificado DV para un solo dominio suele ser suficiente para un sitio web o endpoint de aplicación. Un certificado DV comodín suele ser la respuesta más sensata para un conjunto creciente de subdominios de primer nivel. Un certificado SAN funciona bien para una colección fija de nombres distribuidos entre varios dominios. La validación OV o EV forma parte de la decisión cuando los clientes, las políticas, las prácticas del sector o las condiciones contractuales exigen la verificación de identidad.
Considera también el entorno que hay detrás del certificado. Si el tráfico termina en un equilibrador de carga, proxy inverso, CDN o servidor web gestionado, el certificado debe instalarse y renovarse en el punto donde termina TLS. Instalarlo en un servidor backend no ayudará si los visitantes se conectan primero a un proxy cuyo certificado ha caducado.
Renovación, automatización y riesgo operativo
Un certificado caducado puede detener los inicios de sesión, los procesos de pago, las llamadas a las API y la confianza del navegador, con muy poca advertencia para los clientes. La renovación del certificado debe tratarse como una tarea operativa, no como un recordatorio del calendario que alguien espera ver durante un viernes ajetreado.
Utiliza la renovación automatizada cuando el tipo de certificado y el método de validación lo permitan. La validación DNS es especialmente útil para los certificados comodín, pero la automatización necesita un acceso seguro a los registros DNS. Restringe cuidadosamente esas credenciales y documenta quién es responsable de ellas. Para la validación basada en archivos, confirma que las redirecciones, las reglas de almacenamiento en caché, los firewalls de aplicaciones web y las canalizaciones de implementación no bloqueen la ruta de verificación.
Después de la instalación o renovación, verifica algo más que el candado. Comprueba la cadena de certificados, los nombres cubiertos, la fecha de caducidad, el comportamiento de las redirecciones y el endpoint TLS que realmente sirve el tráfico público. La monitorización debe alertar con suficiente antelación a la caducidad y probar el nombre de host que utilizan los clientes, no solo una dirección interna del servidor.
Para los equipos que prefieren no asumir solos esta carga operativa, el servicio de alojamiento gestionado puede ayudar con la instalación de certificados, las comprobaciones de renovación, la validación DNS y la monitorización del servicio. En kodu.cloud, el objetivo práctico no es hacer que los certificados sean emocionantes. Es mantener disponibles los servicios cifrados mientras te ocupas del trabajo que paga las facturas.
Elige el alcance de certificado más pequeño que cubra de forma fiable tus servicios reales, automatiza las renovaciones que puedas y conserva suficiente visibilidad para que una persona detecte las excepciones. La seguridad funciona mejor cuando es aburrida de la mejor manera posible.
Andres Saar Ingeniero de atención al cliente