Installing VPN software on a web host can rearrange services, but an unexpected certificate does not prove the Apache files were rewritten. Something presented that certificate to your browser, and the first task is naming it. Until the listener and the virtual host are identified, every repair is a guess applied to the wrong layer. The whole check below is read-only.

Nothing gets restarted, uninstalled or overwritten while you gather the facts that decide the case.

Read the Certificate the Browser Actually Got

Record the hostname, the resolved address for each family, the port, and the certificate details the browser complained about. A name that resolves to both an A and an AAAA record can reach two different front ends, and only one of them may be the host you have shell access to. A browser behind a proxy can take a third path again. Guessing which one produced the warning wastes the only observation you have.

Then reproduce the handshake from a machine on the same path, naming the address explicitly and sending the intended server name so the answer reflects the site rather than the default host.

openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltName

Compare the subject alternative names and the fingerprint against the certificate you expect, not against a familiar issuer. Connecting to a bare address without the server name can select a default certificate, which then looks like the wrong file when it is really the wrong question.

Identify the Process Bound to That Port

On the host that should receive the connection, list the listeners and note the bind address, the address family and the process owner. A service bound to the loopback address is not the same as one bound to every interface, and a container publish can put the public listener somewhere else entirely.

sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'

If TLS is terminated by a load balancer or a proxy sitting in front, stop here and inspect that front end instead. The Apache instance behind it may never present a certificate to a public browser, so editing its configuration changes nothing that the browser sees. The socket view and the external handshake have to describe the same path, and that is what this comparison establishes.

Match the Virtual Host Before the File

When Apache is the terminator, ask it which virtual host wins for that address and name. The control command prints the effective layout, including the group matched to each socket, the server names declared, and the host that is treated as default. Editing a certificate file without that answer is how the wrong site ends up being served from a correct file.

sudo apachectl -S

The Apache SSL FAQ explains how server name indication selects a certificate. The HTTP Host header arrives after the handshake and cannot retroactively change what was already presented, so an unmatched or absent name falls back to the default host.

A named virtual host with a typo in ServerAlias produces exactly this symptom, and so does a second configuration file that loads a catch-all host first. Both are visible in that layout listing.

Verify the Fix on Every Path You Claim

After an approved change, repeat the hostname-specific check for each address family and finish with the browser's ordinary validation rather than a bypass flag. Preserve a separate administration path before touching shared listener settings, because a mistake there removes the access you would use to undo it. Then write down which listener answered, which virtual host matched, and which certificate was served before and after.

A package removal can change the layout and leave the original mismatch unexplained, which is why that record outlives the repair.

What you want is the intended site at the intended entry point. A different certificate after an unrelated service disappeared is not that result, even when the browser stops complaining.

ተዛመድቲ ጽሑፋት