Tipos de certificados SSL explicados: DV, OV, EV y cobertura de dominio
Aunque la gente suele decir certificado SSL, las conexiones HTTPS modernas usan TLS. Esta guía usa el término familiar certificado SSL cuando ayuda, al tiempo que describe el HTTPS actual basado en TLS.
Este artículo responde: ¿Cuáles son los principales tipos de certificados SSL/TLS y cuál necesito? Para marcas, opciones y precios actuales en VPSGrid, use el catálogo en vivo—no citas fijas aquí:
Qué hace un certificado SSL/TLS
Un certificado SSL/TLS es una credencial firmada digitalmente que ayuda a un cliente (normalmente un navegador) a establecer una conexión HTTPS con un servidor nombrado. Cuando la configuración es correcta, TLS proporciona:
- Cifrado en tránsito entre cliente y servidor
- Autenticación de los nombres de sujeto del certificado (y detalles de identidad organizativa cuando el certificado los incluye)
- Protección de integridad de los datos en esa conexión frente a manipulación trivial en tránsito
Las autoridades de certificación (CA) emiten certificados de confianza pública según sus políticas de validación y los requisitos del sector de navegadores/CA. Los certificados tienen una vida útil limitada y deben renovarse o reemplazarse antes de caducar.
Qué no hace un certificado SSL
Límites importantes de seguridad
- No hace un sitio web “completamente seguro”.
- No previene malware, hacking ni código de aplicación vulnerable por sí solo.
- No sustituye el parcheo del servidor, el control de acceso ni las copias de seguridad.
- No garantiza la fiabilidad de un negocio ni posiciones en buscadores.
HTTPS protege los datos en tránsito entre extremos cuando se implementa correctamente. La seguridad más amplia del sitio y del servidor siguen siendo responsabilidades separadas—especialmente en hosting VPS no gestionado.
Dos dimensiones de clasificación (no las mezcle)
Los “tipos” de certificado suelen describirse a lo largo de dos ejes independientes:
- Nivel de validación — DV, OV o EV: cuánto control del dominio e identidad organizativa valida la CA antes de emitir.
- Cobertura de dominio — dominio único, multidominio (SAN) o comodín: qué nombres de host puede proteger el certificado.
Estas dimensiones se superponen. Por ejemplo, puede tener un comodín DV o un certificado OV multidominio. DV, OV, EV, comodín y multidominio no son cinco alternativas mutuamente excluyentes.
Niveles de validación: DV, OV y EV
| Tipo de validación | Qué se valida típicamente | Caso de uso típico | Notas de decisión |
|---|---|---|---|
| DV (Domain Validation) | Control del nombre de dominio | La mayoría de sitios web, blogs, APIs y apps que necesitan HTTPS | Camino más rápido a HTTPS de confianza para un dominio que controla; no demuestra la identidad legal del negocio |
| OV (Organization Validation) | Control del dominio más comprobaciones de identidad de la organización | Organizaciones que quieren detalles organizativos asociados al certificado | Elija cuando la validación de identidad de la organización sea un requisito—no porque “refuerce mágicamente” el cifrado frente a DV |
| EV (Extended Validation) | Verificación organizativa más estricta bajo políticas EV | Entornos donde se solicita EV por compras o política interna | No asuma que EV está “técnicamente más cifrado” que DV; tampoco confíe en afirmaciones obsoletas de la barra verde del navegador |
La capacidad de cifrado de los certificados modernos de confianza pública no es el diferenciador útil entre DV y EV. Lo son la profundidad de validación y los metadatos del certificado.
Cobertura de dominio: dominio único, multidominio y comodín
| Cobertura | Qué cubre | Uso típico | Límites importantes |
|---|---|---|---|
| Dominio único | Un nombre de host según se emite (por ejemplo un FQDN específico) | Sitios sencillos con un hostname principal | El apex (example.com) y www.example.com son nombres distintos—confirme que ambos estén incluidos si necesita ambos |
| Multidominio / SAN | Varios hostnames listados explícitamente (Subject Alternative Names) | Varios hostnames distintos en un certificado | Solo se cubren los nombres listados (y permitidos por el producto)—los dominios no relacionados no se incluyen por defecto |
| Comodín (wildcard) | Típicamente una etiqueta como *.example.com para coincidir con subdominios de primer nivel |
Muchos subdominios bajo un dominio padre | No cubre automáticamente todos los nombres posibles; la cobertura del apex y las reglas de subdominios anidados dependen de cómo se emita el certificado—verifique el alcance antes de comprar |
Un comodín sirve para la proliferación de subdominios bajo un dominio que controla. No es un atajo para proteger dominios no relacionados ni para corregir errores de aplicación.
Emisión y renovación a alto nivel
Antes de emitir un certificado de confianza pública, la CA valida el control del dominio (y la identidad de la organización para OV/EV) con métodos como comprobaciones de archivo HTTP, registros DNS TXT u otros desafíos aprobados. Los fallos suelen venir de DNS que no apunta donde se espera, rutas de desafío HTTP bloqueadas o desajustes de hostname—no de un diagnóstico vago de “SSL roto”.
Los certificados caducan. Planifique la renovación o el reemplazo automatizado. Dejar caducar los certificados HTTPS provoca avisos del navegador e interrupciones de conexiones de confianza.
¿Un VPS incluye automáticamente un certificado SSL?
En general no—un VPS proporciona cómputo y red para su SO invitado. Un certificado SSL/TLS es una decisión separada sobre cómo termina HTTPS para sus hostnames. En productos VPS no gestionados, normalmente instala y renueva certificados en el stack web usted mismo (o usa automatización que usted opera). Los productos de creador de sitios pueden integrar el manejo de certificados de otra forma; siga la documentación de ese producto.
El DNS debe permitir que los desafíos de validación tengan éxito. Si su dominio se gestiona en VPSGrid, empiece por la Base de conocimientos de DNS y dominios para procedimientos de nameservers y registros. Para el contexto de endurecimiento del SO invitado en servidores no gestionados, vea Hosting VPS no gestionado explicado y la Base de conocimientos de Seguridad y buenas prácticas (las guías de procedimientos como Certbot pertenecen ahí—no en esta comparación).
Cómo elegir
Trabaje estas preguntas antes de pedir:
- ¿Qué hostnames exactos deben cubrirse (apex, www, APIs, hosts de administración)?
- ¿Necesito un certificado para muchos subdominios de primer nivel (candidato a comodín) o una lista SAN fija?
- ¿La validación de identidad organizativa (OV/EV) es requerida por política, o basta DV para HTTPS en dominios que controlo?
- ¿Dónde se instalará el certificado y quién lo renueva?
- ¿Mi DNS está bajo mi control para que los desafíos de emisión puedan completarse?
Evite reglas simplistas como “toda empresa necesita EV” o “el comodín siempre es mejor”. Ajuste la validación y la cobertura a requisitos que pueda enunciar con claridad.
Errores comunes
- Comprar un certificado antes de que el DNS esté bajo su control
- Emitir solo para
wwwmientras los usuarios llegan al apex (o al revés) - Tratar DV / OV / EV / comodín / multidominio como una sola lista mutuamente excluyente
- Asumir que HTTPS equivale a una aplicación segura
- Ignorar la caducidad y la renovación
Cómo empezar con certificados SSL de VPSGrid
En resumen
Elija el nivel de validación y la cobertura de dominio de forma independiente, luego verifique el producto exacto en el catálogo SSL en vivo. Use HTTPS para el cifrado en tránsito—y mantenga el parcheo, el control de acceso y la seguridad de la aplicación como trabajo separado.
