HTTPS combines HTTP with TLS. In an ordinary browser connection, TLS protects traffic between the client and its TLS endpoint and authenticates that endpoint using a certificate. The familiar lock icon, where a browser still uses one, is shorthand for connection security rather than a character reference for the website.
The name matters
A certificate has to cover the hostname you requested. Replacing a domain with its numerical IP address is not an equivalent test: the certificate may not contain that IP, and the server may use the requested name to select a website.
SNI carries a server name during connection establishment. The HTTP hostname identifies the intended origin at the application layer. They serve different purposes, even when their values are the same.
So do the chain and the clock
A client checks more than a certificate's presence. It normally checks that the name matches, the certificate is within its validity period, and its chain leads to a trusted authority. Other checks depend on the client and its policy.
An incorrect device clock can make a valid deployment appear expired or not yet valid. A missing intermediate certificate can break a chain. A hostname mismatch is a different problem again. Read the actual error instead of treating all certificate warnings as the same event.
curl -I https://example.com/By default, curl verifies the peer certificate and hostname. A verification failure is useful diagnostic information. Adding --insecure removes a protection; it does not repair the certificate, clock or name.
Know where the protection ends
TLS protects a connection between its endpoints. If a web server passes a request to another service, that is a separate connection with its own properties. A certificate does not describe how data is later stored, who has access to it, or whether the site's claims are true.
Encryption also does not hide every connection detail. The destination IP remains observable, and a traditional TLS handshake can reveal the server name. A protected payload is not the same thing as an invisible connection.
The practical rule is to keep both questions: Is this connection authenticated and protected? And, separately, Do I trust this service with what I am sending?