My domain is serving the wrong TLS certificate — need help diagnosing and correcting it

Hello, I’m trying to diagnose a TLS/HTTPS issue with my domain and would appreciate guidance from the community.

Domain: endpoint.blackcorp.me Problem: When I connect to this domain over HTTPS, the server presents a certificate for a completely unrelated domain (*.legacycommunityhealth.org). This results in a hostname mismatch and prevents proper HTTPS access.

Important context:

  • I did not configure this certificate myself.
  • I attempted to run Certbot locally on my Chromebook, but I now understand that Certbot must run on the actual server that terminates TLS for the domain.
  • The IP currently serving my domain is 8.40.154.2, but I’m not sure whether I control that server or whether a hosting provider, proxy, or upstream system is terminating TLS on my behalf.
  • I need to determine:
    1. Why a certificate for another organization is being served on my domain.
    2. Where TLS termination is actually happening.
    3. What steps I need to take to replace the incorrect certificate with a Let’s Encrypt certificate that includes my domain.

What I’m asking the community:

  • How can I confirm who controls the server or load balancer at 8.40.154.2?
  • If I do control it, what is the correct way to install a Let’s Encrypt certificate for my domain?
  • If I don’t control it, what are my options for regaining control of HTTPS for my domain?

Any help diagnosing or correcting this mismatch would be greatly appreciated. Additional Context / Reference Summary

For anyone assisting: Here is a concise summary of the issue and diagnostic steps already explored, so you can understand the current status of the domain and certificate behavior.

Reference Summary: https://gist.github.com/placeholder/endpoint-blackcorp-me-tls-summary (gist.github.com in Bing)

What the summary contains:

  • The domain endpoint.blackcorp.me currently resolves to 8.40.154.2.
  • When accessed over HTTPS, the server presents a certificate for *.legacycommunityhealth.org, which does not match the domain.
  • This indicates that TLS termination is happening on a server or load balancer that I may not control.
  • Certbot was previously run locally, but not on the server that actually terminates TLS.
  • I am trying to determine:
    • Who controls the server at 8.40.154.2
    • Why it is serving a certificate for another organization
    • How to correctly install a Let’s Encrypt certificate for my domain
  • No private keys, credentials, or sensitive data are included in the summary.

This link provides a neutral, technical overview so the community can better understand the mismatch and help identify the correct next steps.

When you say that blackcorp.me is your domain, did you buy it or was someone else managing it before you?

8.40.154.2 serving another website would indicate that you stopped paying for the server/IP address and your provider has reused the IP address.

The next steps might be to recreate the setup on a new IP address (and most likely a new server), and then update the IP address listed in DNS.

1 Like

The 8.40.154.0/24 netblock is assigned to Legacy Community Health Services (ASN 395630) -- I'm presuming that isn't you!

Who have you purchased the blackcorp.me domain through? I'm presuming Ionos, as the MX records for the domain point to Ionos mail servers and the DNS servers are Ionos as well. Are you sure that 8.40.154.2 is the correct IP address? I think it might not be ...

I see that www.blackcorp.me resolves to 212.227.172.253 and blackcorp.me to 217.170.0.10, both of which are Ionos IPs. 212.227.172.253 is shared hosting, because it requires Server Name Identification -- if I ask for www.blackcorp.me then I get a certificate back for *.blackcorp.me issued by Sectigo. 217.170.0.10 doesn't answer connections to port 443 at all.

You also appear to have a wildcard DNS with the IP address 123.45.67.89, by the way.

If you're using your provider's shared hosting and they're providing the certificate then you don't need an LE certificate, but I think we need to know more about what you're trying to do here.

2 Likes

...and that IP looks suspiciously like a placeholder.

5 Likes

Unless our correspondent works for Samsung, I agree :slight_smile:

1 Like