SSL Certificates for Internal Server Names: The Four Options Left

Can you get an SSL certificate for an internal server name?

Not from a publicly trusted CA, and not from any of them. The CA/Browser Forum Baseline Requirements prohibit issuing a certificate whose subject alternative name or common name contains an internal server name or a reserved IP address. That rule took effect on 1 November 2015 and it applies to every CA in every browser trust store, so shopping around does not help.

This catches people out because the restriction is invisible until you try to order. Nothing on your network is misconfigured; the name works perfectly for your users and resolves cleanly on your own resolver. The problem is that it works equally well for several thousand other organisations who also named a machine intranet, and a certificate is a statement about who owns a name. There is nobody to make that statement about.

The good news is that the workaround is smaller than most teams expect. In the majority of cases it is a DNS change rather than a new certificate authority, and the rest of this page is mostly about telling those two situations apart.

What counts as an internal server name?

Any name that cannot be uniquely owned in the public DNS. That covers four groups: bare labels with no domain attached, names under a top-level domain reserved by standard, names under a top-level domain that has never been delegated, and names under a domain somebody else owns. If you cannot point at a registrar record proving the name is yours, a CA cannot either.

In practice you will run into these:

• Bare hostnames. server01, exchange, nas, fileserver. Not fully qualified, therefore not unique, therefore not certifiable.
• Anything under .local. RFC 6762 reserves it for Multicast DNS, and defines names ending in .local as link-local: meaningful only on the segment where the question was asked. There is no registry, so there is no ownership to verify.
• Anything under .internal. ICANN reserved this top-level domain in July 2024 precisely so it would never be delegated in the root, giving private networks a DNS equivalent of the 10.0.0.0 and 192.168.0.0 address blocks. That permanence is exactly what makes it uncertifiable.
• Habitual choices that were never delegated. .corp, .lan, .home and similar strings do not exist in the DNS root, so no CA has a way to validate them.
• Reserved IP addresses. 192.168.1.10, 10.0.4.20, 127.0.0.1 and the IPv6 unique local range. Our companion piece on certificates for IP addresses covers which addresses do qualify.

One case sits in the middle and is worth naming, because it is the most common source of a surprise refusal. A name like server01.corp.example.com is perfectly certifiable if your organisation registered example.com. The same name is refused if example.com belongs to a parent company, a former partner or an agency that registered it on your behalf years ago. The CA is checking the registration, not your intent, so track down who holds the domain before you plan around it.

Why did public CAs stop issuing them?

Because a certificate for a non-unique name is a working attack against everyone else who uses that name. If a CA issued you a certificate for mail.corp, that certificate would validate on every other network in the world where a machine is called mail.corp. You would hold a credential that lets you impersonate other organisations' mail servers, and so would everyone else who bought one.

The CA/Browser Forum worked through this over several years and landed on two dates. From 1 November 2015, no CA could issue a certificate containing an internal name or reserved address with an expiry beyond that date. By 1 October 2016, every certificate of that kind still in circulation had to be revoked. Both deadlines have long passed, which is why old vendor pages describing how to buy one are describing a discontinued product rather than a supplier you have not found yet.

It is worth being clear about what was not banned. Putting a publicly trusted certificate on a machine that lives entirely inside your network remains completely legitimate, and it is what a large share of internal estates do today. The rule is about the name in the certificate, not the location of the server, and that distinction is the whole basis of the approach below.

The four options, and which one fits you

Four routes remain, and two questions pick between them: whether your organisation owns a public domain, and whether every device that must trust the service is one you manage. Most teams that answer yes to the first and no to the second belong on public certificates with real subdomains. Most teams that manage every device have a genuine choice.

Remote Desktop is where this choice usually gets made badly, because the gateway is reached by contractors and home machines that never trusted your internal CA; certificates for Remote Desktop works through which of its four roles that actually affects.

The fourth row deserves more attention than it usually gets. Plenty of .local estates exist because somebody followed a Small Business Server wizard in 2008, not because anything depends on the name. If that is your situation, the cheapest long-term answer is to fix the naming once and never think about this page again.

How do you put a public certificate on a host nobody outside can reach?

You validate the domain rather than the host. With the ACME dns-01 challenge, the proof of control is a TXT record placed in your public DNS zone, so the CA never contacts the server at all. The host's A record can live only on your internal resolver, pointing at a private address, while the certificate it receives is an ordinary publicly trusted one that every browser accepts without a warning.

The arrangement has a name: split-horizon DNS, sometimes called split-brain. Your public zone answers the outside world, your internal resolver answers your staff, and the two return different records for the same name. The public zone holds the _acme-challenge TXT record and a CAA record if you use one; it deliberately holds no A record for the internal host. Nothing about the private address ever becomes public.

Three practical notes from doing this at scale. First, dns-01 is the only challenge type that can issue a wildcard, which matters here because a wildcard removes the need to run a fresh order every time somebody builds a server. If you are covering an internal estate, a wildcard certificate over your internal label is usually the shape that fits, and it has a second benefit that the next section gets into.

Second, the failure you will actually hit is not a refusal from the CA. Most ACME clients run their own pre-flight lookup to confirm the TXT record is visible before they ask the CA to check. On a split-horizon network that lookup goes to the internal resolver, which knows nothing about _acme-challenge and answers differently from the public zone, so the client gives up while the public record was correct the whole time. The fix is to point the client's resolver at a public one, or to use its skip-self-check option; cert-manager exposes this as waitInsteadOfSelfCheck, and other clients have an equivalent. Teams lose entire afternoons to this before finding the setting.

Third, delegate the challenge zone rather than handing your production DNS credentials to every server that needs a certificate. A CNAME from _acme-challenge.corp.example.com to a dedicated zone limits what a compromised host can rewrite. It is a five-minute change and it keeps the blast radius of an ACME credential to the challenge record alone.

What does certificate transparency reveal about your internal hosts?

Every hostname you certify publicly is published permanently in public logs that anyone can search. Certificate transparency is not optional: Chrome has required log inclusion for certificates issued after 30 April 2018, so a certificate that is not logged is a certificate browsers reject. Order one per internal host and you have published a searchable inventory of your estate.

This is the real cost of the public-certificate route, and it is the argument that most comparisons leave out. Names are descriptive by convention, which is the problem: hr-payroll, sap-test, vpn-prod and backup-nas tell a stranger what runs where and which systems are worth a closer look. Reconnaissance against transparency logs is routine, on both sides of the security profession, and log entries cannot be withdrawn once written.

The mitigation is a wildcard. A certificate for *.corp.example.com is logged once under the wildcard name and never discloses which hosts sit beneath it, so you keep public trust and give up nothing. The trade is real and you should price it in: one private key now covers everything under that label, so it belongs somewhere with proper handling rather than copied to a dozen servers by hand. Our guide to what a wildcard does and does not cover walks through where the boundary sits, including the fact that one wildcard level does not cover the level below it.

Before you decide either way, spend two minutes searching your own domain in a transparency log viewer. It is a genuinely useful audit regardless of which route you pick, and most teams find at least one forgotten staging host they did not know was ever certified.

When is a private CA the right answer?

When you control every trust store that matters, or when the hostnames themselves are sensitive. A private CA lets you issue for any name you like, including server01 and .internal, and nothing it issues appears in a public log. The price is that you now operate a certificate authority, and the part that bites is not issuance. It is distribution.

Getting a root certificate onto a domain-joined Windows laptop is straightforward. Getting it onto everything else is where these projects stall. A partial list of the places a private root has to be installed separately: the Java keystore of every JVM application, container images that ship their own CA bundle, Python and Node.js runtimes with their own trust handling, network appliances with a web console and no import mechanism, mobile devices under a BYOD policy, and any contractor or customer device you have no authority over. Each of those is a small task and there are more of them than the initial plan assumed.

None of that makes a private CA the wrong choice. Microsoft Active Directory Certificate Services, step-ca, HashiCorp Vault and the managed private CA services from the major cloud providers all do the job well, and for an estate that is fully managed and internally named they are a better fit than trying to force public certificates onto names that cannot have them. Go in knowing that you are taking on revocation, renewal and root rollover as ongoing work rather than a one-time setup.

One case leaves you no choice at all: a firewall doing TLS inspection has to hold a CA that signs certificates on the fly, and no public CA is permitted to issue one for that purpose, so a private CA is the only supported route. Which FortiGate certificate slot needs which kind of certificate works through where the line falls on a typical appliance.

A hybrid is common and sensible: a private CA for machine-to-machine traffic where you control both ends, and public certificates on the handful of internal services that humans open in a browser. That way the trust-store problem stays confined to systems you already configure centrally, and nobody is teaching staff to click through warnings. Our note on self-signed certificates covers why the third route is narrower than it looks.

Shorter certificate lifetimes change the internal maths too

If you take the public-certificate route for internal hosts, you are also signing up for automation. Under ballot SC-081v3 the maximum lifetime of a publicly trusted TLS certificate fell to 200 days on 15 March 2026, drops to 100 days on 15 March 2027, and reaches 47 days on 15 March 2029. Domain validation reuse periods shrink on the same schedule.

For a public web server that is a known change. For an internal estate it lands differently, because internal certificates are exactly the ones that historically got renewed by hand, by whoever remembered, on a three-year cycle. Forty internal hosts on a 47-day clock is roughly 300 renewals a year, and no calendar reminder survives that. Whatever you choose, the renewal has to run without a person in the loop.

This tilts the decision in a useful direction. Because dns-01 validation needs nothing from the host itself, it automates cleanly for machines that have no inbound path from the internet, which is the exact population that used to be renewed manually. A wildcard renewed once by an automated client and distributed internally turns hundreds of renewals back into one. If you are mapping this across a mixed estate, our overview of DV, OV and EV certificate options sets out which validation level each internal service actually needs, and preparing for 47-day certificates covers the automation side in more depth.

Frequently asked questions