Idiomas

Certificados SSL/TLS

DV vs OV vs EV, wildcard vs SAN, Let's Encrypt y la emisión gratuita automatizada, fallos de la cadena de certificados, caducidad y renovación automática, y qué se rompe para las personas frente a los rastreadores cuando un certificado no es válido: el análisis a fondo a nivel de certificado dentro del hub de HTTPS.

Publicado por primera vez: 3 jul 2026 · Última actualización: 21 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2

Google no documenta ninguna diferencia de posicionamiento entre los certificados DV, OV y EV, ni entre los certificados gratuitos de Let's Encrypt y los de pago: mientras el HTTPS sea válido, todos reciben el mismo trato; un certificado más caro compra confianza humana u organizativa, no posicionamiento. La profundidad de validación (DV/OV/IV/EV) y el alcance de cobertura (un solo dominio, wildcard, SAN) son decisiones separadas, y ninguna es un factor de posicionamiento documentado. Donde los certificados sí afectan al SEO es en el fallo: un certificado caducado, autofirmado, con nombre de host que no coincide o con la cadena rota provoca advertencias del navegador que espantan a las personas, puede invertir la preferencia canónica habitual de Google por HTTPS frente a HTTP y devolverla a HTTP (HSTS no puede anularlo) y, si los errores de HTTPS se acumulan, puede llevar a Google a dejar de rastrear por completo sus páginas HTTPS. Con los periodos de validez de los certificados reduciéndose hacia un máximo de 47 días para 2029, la renovación automatizada ya es obligatoria, no opcional.

TL;DR — Google no documenta diferencias de posicionamiento entre los niveles de validación DV, OV y EV ni entre certificados gratuitos y de pago: un certificado más caro compra confianza humana u organizativa, no mejores rankings. La profundidad de validación (DV/OV/IV/EV) y el alcance (dominio único, wildcard o SAN) son decisiones independientes; ninguna es un factor de posicionamiento documentado. Let’s Encrypt y la emisión gratuita automatizada mediante ACME ofrecen el mismo cifrado y reciben el mismo trato. El SEO se resiente cuando el certificado falla: uno caducado, autofirmado, emitido para otro nombre de host o con la cadena incompleta impide el acceso de los usuarios, puede hacer que Google vuelva a preferir la versión HTTP como canónica —HSTS no lo evita— y, según la documentación de Google, “can prompt Google to stop crawling your HTTPS pages” (Traducción) «puede llevar a Google a dejar de rastrear sus páginas HTTPS». Como el CA/Browser Forum reducirá la validez máxima a 47 días en 2029, la renovación automatizada ya es obligatoria. El hub de HTTPS explica que un DV gratuito recibe la misma señal que OV o EV; aquí se desarrolla el tema completo.

El hub de HTTPS defiende que HTTPS es, como máximo, una señal de desempate, que Google comprueba el esquema y no el certificado, y que un certificado DV gratuito obtiene la misma señal que uno OV/EV caro. Este artículo retoma exactamente ahí donde ese lo deja y baja una capa más: al certificado en sí. No voy a volver a discutir si HTTPS ayuda al posicionamiento; doy por supuesto que ha leído el hub. Aquí quiero responder a las preguntas que el hub solo insinúa: qué significan realmente DV/OV/EV, cómo funciona el alcance de cobertura, por qué los certificados gratuitos automatizados están bien, cómo se rompen las cadenas de certificados de formas que se esconden de sus propias pruebas y qué le ocurre de verdad al rastreo —no solo a las personas— cuando un certificado se estropea.

«Certificado SSL» es en realidad un certificado TLS

SSL es terminología obsoleta para los despliegues modernos de TLS. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 8446: TLS 1.3 La documentación de búsqueda se centra en un HTTPS válido y accesible, no en el nivel comercial del certificado. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: HTTPS

Nota rápida de nomenclatura y sigo: SSL (Secure Sockets Layer) es el protocolo obsoleto; todo lo que se emite hoy funciona sobre TLS (Transport Layer Security). «Certificado SSL» sobrevive como nombre coloquial: los propios textos de Search Console de Google siguen diciendo “SSL certificate problems”. Usaré «certificado» en el resto de este texto.

Profundidad de validación: DV vs OV vs IV vs EV

Los certificados se emiten con distintos niveles de validación, que describen cuánto comprobó la autoridad de certificación (CA) antes de dar fe de usted. Según el desglose de SSL.com:

  • DV (Domain Validation) es “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (Traducción) «el nivel de validación más bajo, y verifica que quien solicita el certificado controla el dominio que el certificado protege». Es rápido, barato o gratuito, y normalmente automatizado (demuestre que controla el dominio mediante un registro DNS o un archivo que la CA pueda descargar).
  • OV (Organization Validation) “verifies the identity of the organization (e.g. a business, nonprofit, or government organization) of the Subject listed in the certificate, along with the location where the organization operates.” (Traducción) «verifica la identidad de la organización (por ejemplo, una empresa, una entidad sin ánimo de lucro o un organismo público) del Subject que figura en el certificado, junto con la ubicación donde opera la organización».
  • IV (Individual Validation) “verifies the identity of the individual person listed as the Subject of the certificate.” (Traducción) «verifica la identidad de la persona física que figura como Subject del certificado».
  • EV (Extended Validation), “like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (Traducción) «igual que OV, verifica la identidad de una organización. Sin embargo, EV representa un estándar de confianza superior a OV y exige comprobaciones de validación más rigurosas».

Este es el punto relevante para el SEO: Google no documenta ninguna diferencia de posicionamiento entre niveles de validación. El hub establece que la señal base lee el esquema de la URL; Illyes lo describió como mirar los cinco primeros caracteres que van delante de la URL. Mientras el HTTPS sea válido y funcione, un certificado DV, uno OV y uno EV reciben todos el mismo trato. La diferencia de precio entre ellos refleja el esfuerzo de comprobación y la responsabilidad de la CA, no una preferencia de Google: web.dev dice claramente que “different CAs charge different amounts of money for the service of vouching for your public key.” (Traducción) «distintas CA cobran cantidades de dinero distintas por el servicio de dar fe de tu clave pública». El dinero extra compra confianza ante las personas y organizativa, y nada más.

Y el único argumento que quedaba de cara a las personas a favor de EV se ha evaporado en gran medida: el tratamiento especial de EV en la barra de direcciones del navegador ha desaparecido en la práctica. Chrome eliminó la interfaz verde con el nombre de la empresa a partir de Chrome 77 (2019), y Firefox 70 hizo lo mismo ese año. Así que el argumento de venta de «los clientes ven el nombre de nuestra empresa en la barra», que antes justificaba el precio de EV, ya no se sostiene en los navegadores mayoritarios; verifique el comportamiento actual de los navegadores si va a tomar una decisión de compra, pero, a día de hoy, esa señal visual no está.

Alcance de cobertura: un solo dominio vs wildcard vs SAN

La profundidad de validación es un eje. El alcance de cobertura —qué nombres de host protege realmente un certificado— es otro completamente distinto. En general, cualquier alcance puede emitirse en DV u OV (los wildcard normalmente no se ofrecen en EV según la política del CA/B):

  • Un solo dominio: cubre exactamente un nombre de host, por ejemplo www.example.com.
  • Wildcard: cubre un patrón de nombre de host con una sola etiqueta DNS de profundidad. web.dev es preciso sobre el límite: “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” (Traducción) «En un certificado wildcard, el asterisco sustituye únicamente una etiqueta DNS. Por eso, *.example.com incluye foo.example.com y bar.example.com, pero excluye foo.bar.example.com». Esa última cláusula es la trampa: un wildcard no cubre subdominios de segundo nivel.
  • SAN / multidominio (UCC): una lista explícita de nombres de host concretos en los Subject Alternative Names del certificado. web.dev señala que se tienen “options for mapping your key to more than one DNS name, including several distinct names (e.g. all of example.com, www.example.com, example.net, and www.example.net).” (Traducción) «opciones para asociar su clave a más de un nombre DNS, incluidos varios nombres diferentes, como los cuatro hosts citados en el ejemplo». Un certificado SAN puede abarcar incluso dominios completamente diferentes, lo que lo hace útil cuando se tiene un puñado de propiedades relacionadas y no se quiere sobredimensionar la cobertura wildcard.

El modo de fallo práctico para el SEO se esconde en el límite de una sola etiqueta del wildcard. Suponga que usa *.example.com y alguien crea staging.blog.example.com: son dos etiquetas de profundidad, queda fuera del wildcard y servirá un error de certificado o recurrirá a un certificado que no coincide. Si Google o una persona llega ahí, se encuentra con una experiencia de certificado roto en una página que usted creía cubierta.

Otra trampa de cobertura: que la prueba pase en el nombre de host raíz no demuestra que haya cobertura en todas partes. Un cliente tiene que solicitar exactamente el nombre de host al que se conecta y recibir un certificado que nombre realmente ese host (mediante SNI); en CDN, balanceadores de carga y alojamiento compartido basado en SNI, distintos nodos de borde, regiones u orígenes detrás del mismo dominio pueden servir legítimamente certificados diferentes. Pruebe cada nombre de host público de forma independiente en lugar de suponer que un resultado limpio de SSL Labs en example.com habla por www., por un nodo de borde regional o por un subdominio detrás de otro origen.

Let’s Encrypt y la emisión gratuita automatizada

Let’s Encrypt y otras CA gratuitas emiten certificados DV mediante el protocolo ACME: un ciclo automatizado de solicitud, desafío y emisión que ejecutan por usted clientes como Certbot. Aquí hay dos cosas que se suelen entender mal:

  1. Gratuito no significa más débil. Un certificado de Let’s Encrypt ofrece la misma fuerza de cifrado TLS que uno de pago y, como la señal de Google se basa en el esquema, exactamente el mismo trato de posicionamiento. Las únicas contrapartidas reales son que solo es DV (sin comprobación de identidad OV/EV) y que tiene una vida corta.
  2. La vida corta es una ventaja en cuanto está automatizada. Los certificados de vida corta implican una ventana de exposición menor si alguna vez se compromete una clave y, algo fundamental, que ninguna persona tenga que acordarse de renovar. La automatización convierte el periodo de validez más corto en el más seguro.

Ese segundo punto está a punto de importar a todo el mundo, no solo a quienes usan Let’s Encrypt.

El cambio en los periodos de validez de los certificados (2026–2029): automatice ya

El sector está reduciendo drásticamente los periodos de validez de los certificados según un calendario fijo. El CA/Browser Forum aprobó la Ballot SC-081v3 (la votación se cerró el 11 de abril de 2025), que recorta por fases la validez máxima de los certificados TLS:

  • 398 días hoy
  • 200 días a partir del 15 de marzo de 2026
  • 100 días a partir del 15 de marzo de 2027
  • 47 días a partir del 15 de marzo de 2029

Let’s Encrypt también avanza por su propia vía, más rápida: según su actualización de febrero de 2026, está reduciendo el periodo de validez predeterminado de sus certificados en dos pasos a lo largo de los dos años siguientes —“from 90 days to 64 days, and then 45 days” (Traducción) «de 90 días a 64 días, y después 45 días»—, con el momento de renovación pasando de alrededor del día 60 de un certificado de 90 días hoy a alrededor del día 30 cuando los certificados bajen a 45 días. Esa actualización sustituyó a un calendario anterior más concreto; considere que las fechas exactas de despliegue de cada paso aún no están fijadas y consulte el propio changelog de Let’s Encrypt antes de basarse en una fecha concreta.

La conclusión operativa es contundente: si su renovación no está ya automatizada, arréglelo antes de 2027. Una cadencia de renovación manual que era sobrellevable con 398 días se convierte en una caída casi garantizada con 47–100 días. La cobertura que DigiCert hizo de la votación lo expresa bien: la revalidación manual sigue siendo técnicamente posible, pero “doing so would be a recipe for failure and outages.” (Traducción) «hacerlo sería una receta para el fracaso y las caídas de servicio». La automatización deja de ser algo deseable y se convierte en la única opción sensata.

Fallos de la cadena de certificados / del certificado intermedio

Este es el punto que menos se explica, y la documentación de Google no lo cubre a nivel mecánico, así que aquí va cómo funciona en realidad.

Un navegador solo confía en un pequeño conjunto de certificados raíz integrados en su almacén de confianza. El certificado de su servidor —el certificado hoja (leaf) o de entidad final— casi nunca está firmado directamente por una raíz. En su lugar hay una cadena: hoja → uno o más certificados intermedios → raíz de confianza. Para que un cliente confíe en su certificado hoja, el servidor tiene que enviar la hoja más el o los intermedios, de modo que el cliente pueda construir la ruta hasta una raíz en la que ya confía.

La configuración incorrecta clásica es un servidor que envía solo la hoja y omite el intermedio. Y por esto es insidioso: en Chrome de escritorio a menudo sigue funcionando, porque este guarda en caché los intermedios que ha encontrado en otros sitios y puede rellenar el hueco. Así que quien hace la prueba en su portátil ve un candado verde y da por hecho que todo está bien. Mientras tanto, los navegadores móviles, muchos clientes de API/HTTP y otras herramientas que no tienen ese intermedio en caché fallan el handshake sin más. Es un error de «en mi máquina funciona» en la capa TLS.

Para detectarlo, no confíe en una comprobación rápida con Chrome de escritorio. Use una herramienta que construya la cadena desde cero:

  • SSL Labs’ Server Test señala explícitamente los problemas de “extra download” / cadena incompleta.
  • openssl s_client -connect example.com:443 -showcerts en la línea de comandos muestra todos los certificados que el servidor envía realmente, para que pueda confirmar que el intermedio está ahí.

Qué ocurre cuando un certificado es inválido, ha caducado o está autofirmado

Esta es la sección que más importa, y se divide limpiamente en dos, porque las personas y los rastreadores experimentan de forma distinta un certificado roto.

Qué hacen las personas y los navegadores. Un fallo grave de certificado —caducado, autofirmado, nombre de host que no coincide, CA no confiable— dispara una advertencia intersticial a pantalla completa, no la etiqueta tranquila “Not Secure” que recibe HTTP. Las personas se van. El caso mejor documentado es “A Wolf in Panda’s Clothing”, de Glenn Gabe: el tráfico de un sitio de ecommerce se hundió en una fecha que coincidió con una actualización Panda de Google, y el propietario dio por hecho que era una penalización. La causa real era un certificado caducado que provocaba advertencias del navegador; las personas abandonaban antes de llegar al sitio. Como lo expresó Gabe: “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” (Traducción) «Hay ocasiones en que los problemas de SEO no son realmente problemas de SEO. Los problemas técnicos que aparecen al mismo tiempo que llegan las actualizaciones de algoritmo pueden ser confusos». Renovó el certificado y el tráfico se recuperó en unos ocho días. Los certificados autofirmados se comportan igual en la práctica —un intersticial duro—, así que están bien para entornos internos, de desarrollo o de staging, y nunca son apropiados en un sitio público de producción.

Qué hace Google. Este matiz suele faltar en las páginas de la competencia y tiene más consecuencias de las que sugiere la idea de que «la señal se basa en el esquema». Las directrices de Google para elegir la URL principal dejan claro que un certificado defectuoso no pasa inadvertido para el buscador: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals,” (Traducción) «Google prefiere las páginas HTTPS a sus equivalentes HTTP como versiones principales, salvo cuando existen problemas o señales contradictorias», y mencionan expresamente los certificados defectuosos: “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (Traducción) «Evite los certificados TLS/SSL defectuosos y las redirecciones de HTTPS a HTTP, porque hacen que Google prefiera HTTP con mucha intensidad. HSTS no puede anular esta fuerte preferencia». Por tanto, un certificado realmente roto puede hacer que Google considere principal la versión HTTP sin cifrar. Eso afecta a lo que aparece en los resultados, no solo al presupuesto de rastreo.

Por separado, el informe HTTPS de Google documenta una consecuencia para el rastreo: un certificado no válido “typically affects an entire site,” (Traducción) «suele afectar a todo un sitio», y “if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (Traducción) «si un sitio presenta muchos problemas de HTTPS, puede llevar a Google a dejar de rastrear sus páginas HTTPS». Las URL restantes se etiquetan entonces como “HTTPS not evaluated.” (Traducción) «HTTPS no evaluado». Hay, por tanto, dos mecanismos distintos: el regreso de HTTP como versión canónica y una limitación independiente del acceso de rastreo. Ambos pueden hacer que las páginas desaparezcan del índice sin modificar la señal de posicionamiento básica de https://. Hay que reparar el certificado; no existe una palanca de ranking que optimizar, pero tampoco es un fallo inofensivo.

La propia lista de Google de lo que provoca estos errores coincide con la taxonomía de fallos: que el nombre de host no coincida con los nombres del certificado —“The host name of your site does not match any of the Subject Names in your SSL certificate” (Traducción) «El nombre de host de tu sitio no coincide con ninguno de los Subject Names de tu certificado SSL»— y certificados que “not recognized by major web browsers” (Traducción) «no reconocidos por los principales navegadores web» (autofirmados, de una CA no confiable, corruptos o desactualizados / todavía no válidos).

Supervisión de la caducidad y renovación automática

La caducidad es el fallo de certificado más común y más evitable, y su radio de impacto es asimétrico: normalmente rompe todo el sitio a la vez (Google: “Typically this affects an entire site” (Traducción) «Normalmente esto afecta a todo un sitio»), no una página cada vez. La solución nunca es un recordatorio de calendario. Configure automatización real:

  • ACME / Certbot en su propio servidor, o el equivalente que incluya su plataforma.
  • Certificados gestionados por el proveedor de alojamiento o el CDN (Cloudflare, la mayoría de los alojamientos gestionados, muchas plataformas PaaS) que los emiten y renuevan automáticamente por usted.
  • Un servicio externo de supervisión de certificados y de disponibilidad que avise de caducidades próximas y de fallos de handshake, como red de seguridad incluso cuando la renovación está automatizada.

A medida que los periodos de validez bajan hacia los 47 días, los recordatorios manuales se vuelven matemáticamente insostenibles: la automatización es el único enfoque que escala.

Configuraciones con certificados mixtos entre subdominios

Esto es distinto del contenido mixto (una página HTTPS que carga subrecursos HTTP; se trata en el hub). Los certificados mixtos son cuando distintas partes de su sitio están protegidas por certificados diferentes, con calendarios o plataformas diferentes. El patrón habitual: su dominio principal tiene un certificado impecable, pero blog.example.com funciona en otra plataforma con su propio certificado que caduca según su propio calendario, o un subdominio de marketing en un CDN aparte nunca quedó cubierto por el límite de una sola etiqueta del wildcard, o un alojamiento multiinquilino basado en SNI rompe silenciosamente la renovación de un subdominio mientras el dominio principal se ve perfecto en una comprobación rápida.

La lección: un candado válido en su página de inicio no dice nada sobre la cobertura en el resto. Haga un inventario de subdominios, confirme que cada host tiene cobertura de certificado válida y supervisada (mediante su propio certificado, un wildcard que lo alcance o un certificado SAN que lo liste) y no se fíe de una comprobación de SSL Labs sobre un único nombre de host para certificar toda la propiedad.

Mitos habituales

  • «Un certificado de pago o EV posiciona mejor que un DV gratuito.» No: la señal se basa en el esquema; la profundidad de validación es invisible para Google.
  • «Los certificados wildcard cubren todos los subdominios, incluidos los sub-subdominios.» No: solo una etiqueta DNS; *.example.com no cubre foo.bar.example.com.
  • «Un certificado caducado perjudica directamente mi posicionamiento.» No a través de la señal de posicionamiento base, pero puede invertir la preferencia canónica habitual de Google por HTTPS frente a HTTP y devolverla a HTTP (HSTS no puede anularlo) y, por separado, un número suficiente de problemas de HTTPS puede llevar a Google a dejar de rastrear por completo sus páginas HTTPS. Ambos efectos son reales; ninguno pasa por la señal de posicionamiento en sí.
  • «Los certificados de Let’s Encrypt son de menor calidad que los de pago.» No: mismo cifrado, mismo trato de posicionamiento; la diferencia es la validación solo DV y los periodos de validez cortos (que pronto serán el estándar del sector).
  • «Si mi página de inicio muestra un candado válido, los certificados de todo mi sitio están bien.» No: los subdominios llevan certificados independientes con calendarios distintos.
  • «Los errores de cadena son raros o un problema heredado.» No: son habituales en cualquier stack que sirva solo la hoja, y la caché de Chrome de escritorio los oculta a quien hace la prueba.

Este es el análisis a fondo a nivel de certificado dentro del hub de HTTPS; para el manual de migración, el contenido mixto y HSTS, empiece por ahí.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.