Which SSL Certificate Should You Buy for a Multilingual Website Using Subdomains?

If a multilingual website uses same-level subdomains such as en.example.com, de.example.com, and fr.example.com, and more language sites may be added later, a wildcard certificate is usually easier to maintain. Before purchasing, however, confirm that the certificate also includes the apex domain example.com and that the website platform, CDN, or server supports deploying the certificate.

If there are only a few fixed language sites, a multi-domain certificate or separate single-domain certificates can also meet the requirements. The deciding factors are not the number of languages itself, but the full set of hostnames that need protection, the domain levels, and where the HTTPS connection terminates.

List All the Domains That Need Protection

An SSL certificate validates the hostname in the address being accessed, not the page language, website directory, or server IP. Therefore, example.com/en/ and example.com/de/ share the same hostname, so different languages do not require additional certificate coverage; en.example.com and de.example.com are two separate hostnames.

When compiling the domain list, include not only the homepages for each language, but also the apex domain, the www address, and any separate subdomains actually used for the online store, inquiry forms, and other services. Even an address used only for redirects needs a valid certificate: when an HTTPS address is accessed, the browser completes the TLS handshake before receiving the redirect instruction, so a redirect cannot fix a certificate name mismatch.

A Wildcard Covers Only the Specified Level, Not the Entire Domain Tree

*.example.com can match en.example.com, de.example.com, and www.example.com, but it cannot match example.com or shop.en.example.com.

Some wildcard products include the apex domain as well, but this is a domain configuration specified when the certificate is issued, not an inherent feature of wildcard certificates. Check the certificate's Subject Alternative Name (SAN) list rather than relying solely on the word “wildcard” in the product name.

If the website uses en.example.com and the online store uses shop.en.example.com, both domain levels need to be covered. For a small number of fixed store addresses, simply add each full hostname; there is no need to purchase a wildcard certificate for every level.

Are the Language Sites Fixed, or Will More Be Added?

For just a few fixed subdomains, you can add the apex domain, www, and the language subdomains to one multi-domain certificate. It lists the permitted hostnames individually in the SAN, making the coverage clearly defined. However, when adding a language site, you will need to update the domain list, reissue the certificate, and deploy it again.

If language sites will continue to be added and all are under the same domain level, a wildcard certificate requires less maintenance. When adding es.example.com, you do not need to reissue the certificate for that hostname, as long as the DNS, site configuration, and certificate deployment are set up correctly. However, a wildcard certificate does not automatically create subdomains or enable HTTPS for new sites.

If different languages use separate domains such as example.de and example.fr, a single *.example.com certificate cannot cover them. In this case, you can use a multi-domain certificate or issue separate certificates for each site. The choice should take deployment locations and maintenance responsibilities into account, rather than simply aiming to minimize the number of certificates.

Before Purchasing, Check Whether the Platform Already Provides a Certificate

A hosted website platform or CDN may already support automatic certificate issuance and renewal. If the service covers all language subdomains, purchasing an additional certificate may not be necessary; some platforms also do not allow you to upload certificates purchased independently. First confirm which domains are supported, whether wildcard certificates are supported, and whether certificate services are included in your current plan.

When using a CDN, distinguish between the connection from the browser to the CDN and the connection from the CDN to the origin server. A valid certificate at the CDN edge does not mean the origin server's certificate is also configured correctly. The certificate used by the origin server must meet the CDN's encryption and certificate validation requirements. An origin certificate intended only for CDN-to-origin connections cannot be used directly as a public certificate trusted by browsers.

If language sites are hosted on different servers, sharing a wildcard certificate means distributing the associated private key. A private key leak in one place could affect other sites using the same key. For sites managed by different teams or service providers, separate certificates help isolate risk and reduce the coordination required for renewals across teams.

Do Not Confuse Validation Level with Coverage

DV, OV, and EV refer to validation methods, while single-domain, multi-domain, and wildcard describe domain coverage. These are two different dimensions. Purchasing an OV certificate does not automatically increase the number of language subdomains that can be protected; with the same TLS configuration, encryption strength cannot be determined solely by the validation level.

If the only goal is to enable HTTPS for language sites, a DV certificate trusted by browsers and matching the domain names can meet basic needs. Whether to use OV or EV should depend on corporate identity verification, contractual, or internal management requirements—not on an assumption that a website targeting overseas markets must have a higher validation level.

Free certificates can also meet HTTPS requirements, but a reliable renewal mechanism is essential. For example, Let's Encrypt requires DNS validation for wildcard certificates. To automate renewals, confirm that the DNS service supports the required automation and properly restrict permissions for DNS API credentials.

Check Each Address During Launch Acceptance

Before ordering a certificate or enabling one provided by the platform, confirm the actual hostname list, SAN coverage, deployment location, and renewal responsibilities. It is not enough to confirm that “SSL is supported” without clarifying who will handle issuance failures, expiration alerts, and redeployment.

After launch, visit the apex domain, www, and each language subdomain individually. Check hostname matching, the certificate chain, and HTTPS redirects, and also look for resources on the pages that are still loaded over HTTP. The absence of certificate warnings does not mean that the page has been fully and securely loaded over HTTPS.

For a structure consisting of an apex domain and same-level language subdomains, a wildcard certificate that includes the apex domain is an option that makes expansion easier. For a small number of fixed sites or sites hosted in separate locations, a multi-domain certificate or separate certificates may be more suitable. Purchase a certificate only after confirming the domain list and deployment requirements, rather than buying one first and then changing the website to fit it.