Si un sitio web multilingüe utiliza subdominios del mismo nivel como en.example.com, de.example.com y fr.example.com, y se prevé añadir más sitios en otros idiomas, un certificado comodín suele ser más fácil de mantener. Sin embargo, antes de comprarlo, hay que confirmar si el certificado también incluye el dominio principal example.com y si la plataforma de creación del sitio web, la CDN o el servidor permiten instalarlo.
Si solo hay unos pocos sitios en idiomas fijos, un certificado multidominio o certificados independientes para cada dominio también pueden satisfacer las necesidades. La elección no depende del número de idiomas en sí, sino de los nombres de host completos que se deben proteger, los niveles de dominio y el punto en el que termina la conexión HTTPS.
Los certificados SSL validan el nombre de host de la dirección visitada, no el idioma de la página, el directorio del sitio web ni la dirección IP del servidor. Por lo tanto, example.com/en/ y example.com/de/ comparten el mismo nombre de host y no necesitan cobertura de certificado adicional por estar en idiomas distintos; en.example.com y de.example.com son dos nombres de host diferentes.
Al recopilar los dominios, no enumere solo las páginas de inicio de cada idioma. Incluya también el dominio principal, la dirección www y los subdominios independientes que realmente se utilicen, como los de la tienda en línea y los formularios de consulta. Incluso una dirección que solo se utiliza para redirigir necesita un certificado válido: al acceder a una dirección HTTPS, el navegador completa primero el protocolo de enlace TLS y después recibe las instrucciones de redirección. Una redirección no puede corregir un certificado que no coincide.
*.example.com puede coincidir con en.example.com, de.example.com y www.example.com, pero no con example.com ni con shop.en.example.com.
Algunos productos de certificados comodín incluyen también el dominio principal, pero esto depende de la configuración de dominios al emitir el certificado y no es una capacidad inherente al comodín. Compruebe la lista de nombres alternativos del sujeto (SAN) del certificado, en lugar de fijarse únicamente en la palabra «comodín» del nombre del producto.

Si el sitio web utiliza en.example.com y la tienda en línea utiliza shop.en.example.com, será necesario cubrir ambos niveles. Para unas pocas direcciones fijas de tiendas en línea, basta con añadir los nombres de host completos; no es necesario comprar un certificado comodín para cada nivel.
Si solo hay unos pocos subdominios fijos, puede incluir el dominio principal, www y los subdominios de los distintos idiomas en un certificado multidominio. Este enumera mediante SAN los nombres de host autorizados, por lo que el alcance queda claramente definido. Sin embargo, al añadir un sitio en otro idioma, habrá que actualizar la lista de dominios, volver a emitir el certificado e instalarlo.
Si se seguirán añadiendo sitios en otros idiomas y todos están bajo el mismo nivel de dominio, un certificado comodín requiere menos trabajo de mantenimiento. Al añadir es.example.com, no será necesario volver a emitir el certificado para ese nombre, siempre que el DNS, la configuración del sitio y la instalación del certificado sean correctos. No obstante, el comodín no crea subdominios automáticamente ni habilita HTTPS de forma automática en los nuevos sitios.
Si se utilizan dominios independientes para los distintos idiomas, como example.de y example.fr, un certificado *.example.com no podrá cubrirlos. En ese caso, se puede usar un certificado multidominio o emitir certificados independientes para cada sitio. La elección debe tener en cuenta dónde se instalan y quién se encarga de su mantenimiento, no limitarse a buscar la menor cantidad de certificados posible.
Es posible que una plataforma de creación de sitios web alojada o una CDN ya admita la emisión y renovación automáticas. Si el servicio cubre todos los subdominios de idiomas, quizá no sea necesario comprar otro certificado; algunas plataformas tampoco permiten cargar certificados adquiridos por cuenta propia. Confirme primero qué dominios se admiten, si se admiten certificados comodín y si el servicio de certificados está incluido en el plan actual.
Al utilizar una CDN, hay que distinguir entre las conexiones del navegador a la CDN y de la CDN al servidor de origen. Que el certificado en el nodo perimetral de la CDN sea correcto no significa que el certificado del servidor de origen también lo sea. El certificado del servidor de origen debe cumplir los requisitos de cifrado y validación de certificados de la CDN. Un certificado de origen destinado únicamente a la conexión de retorno de la CDN no puede utilizarse directamente como certificado público de confianza para los navegadores.
Si los sitios en distintos idiomas están distribuidos en varios servidores, compartir un certificado comodín implica distribuir la clave privada correspondiente. Una filtración de la clave privada en un sitio puede afectar a otros sitios que utilicen la misma clave. Para los sitios gestionados por equipos o proveedores diferentes, los certificados independientes ayudan a aislar los riesgos y a reducir la coordinación entre equipos durante las renovaciones.
DV, OV y EV indican métodos de validación de identidad; los certificados para un solo dominio, multidominio y comodín describen la cobertura de dominios. Son dos dimensiones distintas. Comprar un certificado OV no aumenta automáticamente la cantidad de subdominios de idiomas que se pueden proteger; con la misma configuración TLS, tampoco se puede determinar la intensidad del cifrado basándose únicamente en el nivel de validación.
Si el único objetivo es que los sitios en distintos idiomas funcionen correctamente con HTTPS, un certificado DV de confianza para los navegadores y que coincida con el dominio cubre las necesidades básicas. La decisión de utilizar OV o EV debe basarse en los requisitos de verificación de la identidad de la empresa, los contratos o la gestión interna, y no en que el sitio web esté dirigido al extranjero.
Los certificados gratuitos también pueden satisfacer las necesidades de HTTPS, pero deben contar con un mecanismo de renovación fiable. Por ejemplo, la emisión de certificados comodín de Let’s Encrypt requiere la validación de DNS. Para automatizar la renovación, confirme que el servicio DNS admite la automatización correspondiente y limite adecuadamente los permisos de las credenciales de la API de DNS.
Antes de realizar el pedido o activar el certificado de la plataforma, confirme la lista real de nombres de host, el alcance de cobertura de SAN, el lugar de instalación y quién es responsable de la renovación. No basta con confirmar que «admite SSL» sin determinar quién se encargará de los fallos de emisión, las alertas de vencimiento y la reinstalación del certificado.
Después de poner el sitio en línea, visite una por una las direcciones del dominio principal, www y los subdominios de cada idioma. Compruebe que los dominios coincidan, la cadena de certificados y las redirecciones HTTPS; además, revise si alguna página sigue cargando recursos mediante HTTP. Que no aparezcan advertencias sobre el certificado no significa que la página se esté cargando completamente y de forma segura mediante HTTPS.
Para una estructura de «dominio principal más subdominios de idiomas del mismo nivel», un certificado comodín que incluya el dominio principal es una opción fácil de ampliar. Para unos pocos sitios fijos o sitios distribuidos, un certificado multidominio o certificados independientes también pueden ser más adecuados. La compra debe basarse en una lista de dominios y unas condiciones de instalación ya confirmadas, no en comprar primero el certificado y adaptar después el sitio web.
Artículos relacionados
Productos relacionados


