HTTPS to a private IP: certificate identity or hostname?

Your service at https://10.60.0.25 can have authenticated TLS even without a DNS name. The address is the identity the client must validate, and the certificate has to describe it exactly. The decision is whether that address is stable enough to be an identity, or whether a hostname would be easier to maintain. The VPN answers reachability; it does not answer this.

Get the identity and the trust right, and an IP-based URL is a legitimate design.

What the client actually validates

The client checks the reference identity in the URL against the certificate's subject alternative names. For an IP address, that means an iPAddress entry equal to the address. A friendly common name is not a substitute.

RFC 9525 separates IP-address identities from DNS names and defines the matching rule. Putting the address only in the subject label, or as a DNS-type entry, does not produce a match. That is why the SAN is the field to inspect when a warning appears.

Trust is a second, independent check. A name match does not fix an untrusted chain, an expired certificate or a certificate issued for another purpose.

Decision one: is the address stable enough to be an identity

If the address is fixed for the life of the deployment, an IP SAN certificate is simple and honest. If the service may move, every move becomes a certificate replacement and a coordinated client update.

A stable hostname reduces that coupling. Clients use the name, approved DNS maps it to the current address, and an address change stops being an identity change. The certificate still needs renewal, but the URL does not change.

A managed hosts-file entry can supply the mapping in a small environment. It adds a distribution responsibility; it does not replace TLS verification.

Decision two: how the client will trust the issuer

For a private CA, distribute the trust anchor to the intended devices through an approved mechanism. Do not train users to click through warnings or install a certificate handed to them by a sign-in page. If you want a publicly trusted certificate, check the issuer's current rules for private addresses before you plan around one. Most public issuers will not validate a private IP as a public identity.

Review the actual browser or application. Its trust store and validation behavior matter more than the operating system's general certificate documentation. Check it on the actual device, not only in the console.

The VPN gateway may not be the machine running the web application, so do not assume the tunnel's certificate has anything to do with this one.

Plan the address change before it happens

If 10.60.0.25 becomes 10.60.0.40, the old certificate no longer describes the URL. Plan the replacement and the client update together, and never disable verification during the move.

Choose the identity users will type or applications will configure, then align issuance, trust, deployment and renewal around it. A reachable page with a dismissed warning is not the same result as a service whose identity the client verifies.