All domains using the cert of a subdomain for no apparent reason?

My domain is: molytov.xyz
My web server is (include version): nginx/1.26.0
The operating system my web server runs on is (include version): Ubuntu 24.10
I can login to a root shell on my machine (yes or no, or I don't know): Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.11.0

While I can seemingly access the main domain molytov.xyz and other subdomains from my desktop (fndm.molytov.xyz, u.molytov.xyz, paste.molytov.xyz), my phone and other devices on my local network or on mobile connections get common name cert errors, saying they're using the u.molytov.xyz subdomain's cert, and then directing to the u.molytov.xyz page.

I have no clue why this is happening or how to fix this. All the domains/subdomains use their own certs. All nginx configurations are set to use the proper certificates, and I don't notice anything when checking my domain on viewdns.info or mxtoolbox. My phone and other devices on my network think all my subdomains are u.molytov.xyz and point to it.

Also PS, is the python CryptographyDeprecationWarning still not being fixed? : |

This is why I ask for help. Every time something goes wrong, I find the issue on my own that completely unrelated to what I thought the issue was, and I look like an idiot for wasting people's time by asking : p

The issue was that, for whatever reason, the lines to listen on 443 were missing from my nginx configs, except for the one for u.molytov.xyz, making it seemingly the only secure site and thus the one that gets the connection.
I don't know why my desktop specifically could still access all the other subdomains even when clearing caches and stuff, but I suppose this isn't a problem anymore for now.

3 Likes

Were you missing just a listen for IPv6, or just IPv4?

We see plenty of people who accidentally put just a listen for IPv4, forgetting IPv6, and yet have an AAAA record for it in their DNS (like you do).

Otherwise, yeah, it probably is not worth the effort to find the underlying reason other than as a learning experiment.

2 Likes

Maybe in v3.0.1? See: certbot/certbot/CHANGELOG.md at main · certbot/certbot · GitHub

2 Likes