The HTTPS certificate does not cover your WordPress domain: correct the name and destination

Recognise a name error before changing WordPress

You open your site and the browser interrupts the connection with a message such as “NET::ERR_CERT_COMMON_NAME_INVALID” or “SSL_ERROR_BAD_CERT_DOMAIN”. The certificate presented may not match the requested name. The aim is to serve a trusted certificate appropriate for every address used, without asking visitors to ignore a warning.

The certificate is presented while the HTTPS connection is established, before WordPress can display its page. A theme setting or redirect plugin therefore cannot repair the server’s certificate. The correction is generally made through the hosting account, domain management, or the service in front of the site.

Treat the warning as a stopping point. Do not enter credentials at that address, add a security exception, or disable TLS validation. TLS is the current protocol used to secure HTTPS; panels still often use the term SSL. To manage the repair, open your provider’s usual customer area directly.

Record the exact address, error code, time, and last known change: a new domain, migration, addition of www, or activation of a CDN. Remove private parameters from screenshots. These initial details are already enough to choose a useful check.

Read the covered names rather than only the main name

In the certificate details offered by the browser, look for “Subject Alternative Name”. This SAN list contains the covered DNS names. The Common Name field, abbreviated CN, may have another label: it is not enough to conclude that the certificate is wrong. Compare the name actually entered with the SAN entries.

Take a fictional example: a certificate covering example.com does not automatically cover www.example.com. The first is the root domain, also called the apex; www is a subdomain. The address shop.example.com is another name again. By contrast, /contact and /blog are paths on the same site: they do not require separate certificates.

A wildcard entry such as *.example.com can cover www.example.com and shop.example.com, but not example.com itself or paiement.shop.example.com. A certificate may combine several entries to cover the required names. Wildcards in DNS records and certificates do not have exactly the same rules.

Even if www only redirects to the main domain, HTTPS access to it first requires a valid certificate for www. The HTTP redirect is sent after TLS negotiation. Correcting only the final address would therefore leave visitors arriving through the other variant facing the same warning.

Separate an incorrect name from other certificate errors

Check validity dates and the detailed message. An expired certificate may cover the correct domain: renewal then needs attention. An incorrect date on the device may also cause a validity error. An unknown authority or incomplete chain concerns trust in the certificate; the chain connects the site certificate to a recognised authority.

These problems can occur together. If the requested name appears in the SANs but the connection is still refused, do not add the name repeatedly: send the complete code to the provider so it can check dates, the chain, and the certificate actually served.

An HTTPS page that displays but blocks an HTTP image or script generally involves mixed content. This guide does not propose replacing content links. Similarly, a redirect loop between two addresses needs a different investigation once the certificates are valid.

If the fault appears only on one device or network, compare observations with an up-to-date browser on a known connection, without bypassing the warning. A corporate network or security software may intervene in the connection. Have its administrator examine the case before changing a site that works elsewhere.

Prepare access and retain the current configuration

On self-hosted WordPress, a WordPress administrator account does not necessarily provide certificate access. Identify the hosting account, DNS manager, and any CDN. A CDN is an intermediary service that receives visitors before contacting your server. The domain seller may differ from the service managing its DNS.

Before a change, record the names associated with the site, selected certificates, and relevant DNS values, including their cache duration, called TTL. Export the DNS zone to a private location if the interface allows it. A screenshot of each targeted record is preferable to a value recalled from memory.

During a migration, retain access to the old hosting until the new destination has been verified. Ask the provider to preserve the previous TLS configuration. Do not delete a certificate or private key to “start clean”; the private key must never be published on a forum or copied into an ordinary ticket.

Then choose the approach matching the facts. An incorrect DNS destination calls for the second approach; a correct destination with a name missing from the certificate calls for the first. If traffic passes through a CDN, the third identifies the connection actually failing. These approaches are not three mandatory changes.

Approach 1: have the host cover the correct domain

Use this approach when the host confirms that the domain reaches the correct installation. In its customer area, select the affected site and check its attached domains or aliases. Adding an alias tells the server to accept that name; it does not by itself guarantee that a certificate has been issued.

In cPanel, the check is under Security, then SSL/TLS Status, or under SSL/TLS Certificates and its Status tab in the unified interface. Filter for the domain and also examine www. Read the details, status, and any AutoSSL error. Issuance buttons depend on features enabled by the host; a missing button does not justify changing system files.

In cPanel’s unified interface, the Wizard tab may offer a Let’s Encrypt button when the host has enabled that option. If you see only a purchasing flow, ask it to confirm AutoSSL availability before ordering.

If a required name is missing, use the automatic SSL flow supplied for this site, selecting the exact names to protect. A name absent from the SANs requires a new certificate covering the intended scope, not a manual change to the text of the existing certificate. Prefer the mechanism included with your hosting where suitable; you do not need to buy a certificate solely to add www.

Read the summary before confirming. Selected names must match the addresses used and be verifiable. Do not select every service in the account out of habit: webmail, panel, and other-site names may belong to another configuration.

• Check that the domain and www are associated with the correct site.
• Record the current certificate and SSL manager message.
• Request issuance or reissuance for only the required names.
• Wait for confirmation, then check the certificate actually presented to the browser.

If the certificate is issued but the browser receives another one

An “issued” status does not prove that the certificate is installed in the right place. Compare SANs and dates visible in the browser with the panel details. If these are different certificates, ask the host to check their assignment to the HTTPS site and deployment on responding servers.

Several sites may share an IP address. The browser normally sends the requested name during connection using Server Name Indication, called SNI, and the server selects the corresponding certificate. An incorrect association may show another site’s certificate or the provider’s default. Testing only the IP address in the browser bar does not faithfully reproduce domain-based access.

If the domain is correctly covered but incorrectly assigned, have that assignment corrected rather than repeatedly requesting certificates. The provider may also need to reload configuration or align several servers. Purging WordPress page caching does not change this selection.

If a change fails, request restoration of the last assignment known to be valid, provided its certificate is still usable. Do not deliberately restore an expired certificate or one that fails to cover the name just to create an appearance of working.

Unblock domain validation before requesting issuance again

The certificate authority must verify control of the requested names. The service may prove this through a file accessible on the site or a specific DNS record. A pending request may therefore indicate an incorrect destination, an unconfigured name, or inaccessible validation.

For Let’s Encrypt HTTP-01 validation, the server must respond on port 80 at the intended path under .well-known/acme-challenge/. The host must check that route, including when several servers or an intermediary are involved. Do not disable all site protection to make a single path accessible.

For DNS-01, follow the exact name and value supplied under _acme-challenge. Do not replace other TXT records: they may serve email or another validation. Also check who will handle future validations; a successful manual operation today is not enough to organise renewal.

A CAA check failure may result from an authority restriction or a DNS response error. CAA records limit which authorities may issue certificates. Have the cause and the authority actually used identified, then adjust the rule if needed with the domain manager, without deleting every restriction. A DNSSEC error, involving verification of DNS response signatures, also needs diagnosis by the DNS provider. Correct the stated cause before retrying: repeated requests may reach an issuance limit.

Approach 2: correct a DNS destination shown to be wrong

Use this approach after migration or when domain variants reach destinations different from those intended. Open the zone at the manager actually designated by the nameservers. Changing an old zone still visible at the domain seller has no effect if it is no longer authoritative.

Examine the root domain and www separately. An A record specifies an IPv4 address, AAAA an IPv6 address, and CNAME another name to follow. Compare their values with site-specific instructions in the hosting or CDN account. Do not use an address found in a tutorial.

An address different from the WordPress server’s may be perfectly normal behind a CDN. Have the expected destination confirmed before replacing anything. Several addresses may also belong to legitimate infrastructure; their number alone does not demonstrate an error.

Pay particular attention to AAAA: an old IPv6 server may respond with the wrong certificate while IPv4 access works. Let’s Encrypt may also attempt IPv6 validation. Have the incorrect address corrected; remove the record only if the responsible person confirms that this name should no longer use IPv6.

Preserve existing MX and TXT records. MX records direct email, and some TXT records serve email authentication among other purposes. Even an A-record change needs checking if mail uses that name as a destination. An HTTPS repair must not turn into resetting the entire DNS zone.

• Record the old value, type, full name, and TTL of the record to correct.
• Apply only the confirmed value for that record, then record the time.
• Have the effective DNS response checked before requesting a certificate again.
• Then check every domain variant over HTTPS.

Wait for consistent DNS responses and plan rollback

After a DNS change, resolvers may retain the old response for its cache duration. Results can therefore vary by network. The delay depends on configuration and caches already populated; clearing the site’s page cache does not speed up their refresh.

Do not keep making changes while waiting. Ask the manager to compare the authoritative zone with observed responses. If the published value remains wrong, waiting will not fix it. If it is correct but not yet seen consistently, retain the time and check results to distinguish transition from a new failure.

Returning to the old value must be decided with the person managing the migration: the old server must still host the correct site and have a valid certificate. Restoring a DNS value does not restore content received on the new site since then. Rollback is also affected by DNS caches; it is not instantaneous.

Compare two HTTPS destinations while retaining the name

If two destinations confirmed by the provider respond differently, compare them from a workstation authorised to contact them directly. Keep the domain name in the URL. The --resolve option forces an address for that name and port within the command concerned, while preserving the name used for TLS negotiation and certificate verification. The first call uses normal resolution. Replace the fictional name and documentation-reserved addresses with approved destinations. The IPv6 call applies only if the workstation and destination have that route.

Run the example in a POSIX-compatible shell. On Windows, use Git Bash, for example. In PowerShell, rewrite each call with curl.exe, NUL instead of /dev/null, and a braced variable before the colon in --resolve. -q must remain the first argument to ignore curl’s configuration file. Requests use HEAD, leave headers out of the record, and do not follow redirects. If the status is 3xx, examine the Location header separately on the authorised workstation. If a proxy intervenes, the remote address may be the proxy’s and it may resolve the destination. In that case, have the approved route established before comparing addresses.

For each call, compare the remote address, HTTP status, and displayed exit code. On a direct route, the remote address of forced calls must match the requested address. A 405 response indicates that the exchange reached HTTP, even if HEAD is refused. HTTP status 000 means that no response status was obtained. Read curl’s error to distinguish a name, trust, resolution, or connection problem. The script displays each call’s output for diagnosis. Keep TLS validation enabled. If a CDN protects the origin or uses trust specific to its route, ask the provider to verify that route instead of drawing a conclusion from direct access.

hote=www.recette.example

sonde() {
  if curl -q -sS --head --connect-timeout 8 --max-time 15 \
    --output /dev/null --write-out 'ip=%{remote_ip} http=%{http_code}\n' \
    "$@" "https://${hote}/"; then
    printf 'sortie=0\n'
  else
    printf 'sortie=%s\n' "$?"
  fi
}

sonde
sonde --resolve "${hote}:443:192.0.2.10"
sonde --resolve "${hote}:443:[2001:db8::10]"

Approach 3: check the CDN and origin server separately

When a CDN receives visitors, two connections may be secured separately: browser to CDN, then CDN to origin server. The origin is the server where WordPress resides. The certificate shown to a visitor may therefore be the CDN’s, even if the hosting panel displays a correct certificate.

In Cloudflare, select the domain, then SSL/TLS and Edge Certificates. Check that the public certificate is active and covers the failing name. Also check the name’s status in DNS without changing it at random: the Cloudflare certificate serves traffic passing through its proxy, not direct origin access.

With Universal SSL in a zone fully managed by Cloudflare, the root domain and first-level subdomains are covered; a deeper name may need different coverage. Have the solution and any cost confirmed before changing the architecture. Do not assume that a wildcard certificate protects every level.

If the browser reaches Cloudflare correctly but Cloudflare reports error 526, have the origin certificate checked: its name, validity, and trust must match the connection used. Do not reduce validation to hide the defect. Other negotiation failures need their own diagnosis.

A Cloudflare Origin CA certificate is intended for the connection between Cloudflare and the origin; browsers do not grant it the same public trust. Disabling the proxy to “test” may therefore create a new error. Have the provider check the origin while retaining the requested name, without suddenly exposing an unprepared route.

On WordPress.com, use domain management

WordPress.com automatically supplies certificates for domains hosted on its platform. In the hosting dashboard, open Domains, select the name, then Settings and Domain security. Record the status and stated problem.

Provisioning may take up to twenty-four hours. Once the domain connection and blocking issues are corrected, the Provision certificate button allows the request to be retried where offered. If it is missing or the error returns, contact support with the exact status.

During provisioning, the WordPress.com address may serve as a temporary primary address depending on site configuration. If it already redirects to the failing domain, have this choice checked before sharing it. Restore the custom domain as primary only after certificate activation. Do not apply cPanel procedures or a private certificate installation to this platform.

Check domains in a multisite network

A WordPress network may use subdomains or several custom domains. The main site’s certificate does not guarantee one for every network site. With the network manager, list the public names and administration addresses actually used.

Each custom domain must be associated with the correct site at the hosting or CDN level and covered by a suitable certificate. A subsite presented in a path under the main domain does not create that same requirement. A multilevel subdomain, however, may exceed a wildcard’s scope.

Check the affected site after every correction and keep a few other network sites in the checks. Do not make a global change to WordPress addresses to resolve the certificate for a single domain.

Confirm the repair and retain a follow-up procedure

Open every HTTPS address used in an up-to-date browser without security exceptions. Check the main domain, www if used, and older names still offered to visitors. The certificate must cover the initial name, then any redirect must reach the expected site. Check a public page and the login display before entering credentials.

Repeat the check from another known connection if the defect varied by network. An isolated success is not enough to explain intermittent results. If the panel and browser still show different certificates, or some variants fail, keep the ticket open.

Send support the affected names, exact codes, times, observed SANs and dates, recent change, and intended route with or without a CDN. Add results already obtained and useful DNS values through the provider’s private channel. Do not attach a private key, password, or complete account export.

After repair, record who manages issuance and renewal, covered domains, and alerts to monitor. Before the next domain addition, prepare its association and certificate before distributing its address. This check avoids discovering a forgotten variant when a visitor uses it.

Do not publish a certificate from the ACME staging server

For administrators automating renewals, Let’s Encrypt offers a separate staging environment. It lets you check the ACME flow without repeatedly issuing public certificates during troubleshooting. It is not a “less complete” free certificate to present to visitors: certificates from that environment are not intended to establish normal browser public trust.

When the hosting panel manages issuance, use its tools and support; do not add Certbot alongside it. When you manage an ACME client yourself, first prepare the validation scenario in the staging environment according to its documentation, keeping the production configuration. The staging server choice, accounts, and generated files must remain identifiable to avoid assignment to the wrong domain.

A useful success has two distinct stages: technical validation of the flow, then issuance and deployment of the appropriate public certificate. After switching to production, check again the SANs, dates, and chain actually received for each name. If a staging certificate was assigned accidentally, have the known valid public certificate restored or the correct issuance completed; do not install trust exceptions for visitors. This preparation mainly concerns automated renewals and is not a reason to delay repairing an expired certificate.