A Certificate for a VPN-Only Site: DNS-01 or Private CA?

Three conditions decide how a VPN-only website should get its certificate: whether you control a public DNS zone, whether the hostname may appear in public logs, and whether every client can be given a private trust anchor. The public and private routes both produce a working padlock and they answer different questions. Picking one without settling those conditions is how a site ends up with a public certificate it did not want, or an internal one that half the clients reject.

The certificate proves the name; the VPN and the internal DNS provide the path.

Two Routes to a Trusted Name

A public issuer with DNS-01 validation proves control of a name through a TXT record in a zone you control, so the web service never has to accept a public HTTP connection. A private CA issues leaf certificates for internal names and distributes its trust anchor through device management, so no public log learns the name. Both are legitimate, and the choice follows from those three conditions rather than from convenience. Neither route supplies the route or the resolver entry a client needs.

A public certificate also publishes the hostname in certificate-transparency logs. If the name itself is sensitive, that disclosure is a design decision rather than a side effect to discover later.

DNS-01 Without Exposing the Service

The challenge record is a TXT entry under a reserved prefix in the zone, and the issuer reads it from authoritative DNS. Choose an ACME client and DNS integration that can create and remove that record, and authorise the update narrowly: a scoped API credential for the zone, or a controlled host used only for validation. Giving the application server an unrestricted registrar credential to renew one certificate is far more authority than the task needs. When several orders share a name, keep their TXT values distinct so cleaning up one does not remove a value another still needs.

Wait for propagation with a check against the authoritative servers rather than a fixed sleep. Propagation behaviour is provider-specific, and a sleep that works today is not evidence about tomorrow.

Managed Clients and Deliberately Private Names

Managed devices and deliberately private names fit an internal CA well. Distribute the trusted issuer through device management, then issue leaf certificates for the intended names. Check which store each client actually uses, because one operating-system import is not a universal claim about every browser and application. Leaf pinning is another option where explicitly supported, at the cost of another trust update whenever the leaf changes.

The distribution channel matters as much as the key: a root that nobody installs protects nothing.

Renewal Is Part of the Design

Whatever route you choose, renewal needs an owner and a procedure. Refreshing the validation proof, installing the new material and reloading the listener through its supported mechanism are three separate steps, and only the first is automated by most ACME clients. A certificate that renews correctly but is never loaded produces the same outage as one that expired.

The certificate does not install the VPN route or create the internal DNS record. Clients still need a resolver that maps the name to the private address and a route to reach it. Test the site by name from a client that has both.

Record the issuer, the validation method, the trust distribution channel and the reload mechanism. Those four are the renewal plan.