HTTPS is easiest to reason about when its pieces are checked separately. The server presents an identity, the client decides whether to trust it, and both sides negotiate a secure connection.
Check the name
The certificate must cover the hostname that the visitor requested. An address that reaches the right machine is only part of the story: the hostname still needs to match the certificate.
Keep the requested hostname visible in your test. Replacing it with a bare IP address changes what you are testing, especially when several sites share a server.
Keep verification enabled
Check the certificate chain with a normal trust store. If a test succeeds only after certificate verification is disabled, that test has skipped the identity check it was meant to exercise.
Also inspect the validity period. A correct hostname on an expired certificate is still a broken deployment. Renewal should be treated as part of the service, with a repeatable test and a clear way to load the renewed certificate.
Check the negotiated protocol
The protocol in use belongs to the connection, not just the certificate file. Test the running endpoint and record what the client actually negotiated. A configuration file is useful evidence, but it is not a substitute for a handshake.
curl --head https://mypage.366766.xyz/This small request checks that the site can answer an ordinary HTTPS request. More detailed diagnostics can then separate DNS resolution, certificate validation, connection setup, and the HTTP response.
Test the renewal path
After a renewal, confirm that the application is serving the new certificate. Some services reload files; others copy credentials when they start. The renewal procedure needs to account for the service that actually reads the key.