Why does the same certificate work on a private CA but fail with a public one?

Because the rule isn't about your certificate's quality — it's about who vouched for a name that isn't globally unique. The CA/Browser Forum's Baseline Requirements forbid any publicly-trusted CA from issuing a certificate for an internal name or a reserved IP. Public CAs stopped issuing them in November 2015 and had to revoke the rest by October 1, 2016. So a certificate for `mail`, `intranet`, `server.local`, or `192.168.1.10` that chains to a public root is a certificate that, by policy, should not exist — and Chrome refuses it with NET::ERR_CERT_NON_UNIQUE_NAME. The exact same name in a certificate you signed with your own internal CA, one you installed into the trust store yourself, is fine. You took responsibility for that name; a public CA is not allowed to. That difference is the whole error.

Why are internal names banned in public certificates at all?

Because they're not unique, and a certificate's entire job is to bind a key to a name only one party can claim. Thousands of separate networks all have a host called `mail` or `intranet` or a box at `192.168.1.1`. If a public CA could certify `mail`, then any of those thousands of organizations could obtain a valid, publicly-trusted certificate for `mail` — and use it to impersonate the `mail` server on any other network its traffic happened to cross. A non-unique name has no single legitimate owner for a CA to verify, so a certificate over it is a ready-made man-in-the-middle tool. The ban closed that hole. Chrome enforcing it at the browser is the last line of that same defense.

How do I actually fix it for an internal server?

Two honest paths. If the service can have a real, globally-unique name, give it one — a subdomain of a domain you own, like `git.internal.example.com`, resolved privately if you don't want it public — and get a normal certificate for that. Public CAs will issue for a name you can prove you control, even if it only resolves inside your network. If you'd rather keep internal-only names or certify a private IP, run your own internal CA, issue the certificate from it, and distribute that CA's root to every client that needs to trust it (this is exactly what tools like mkcert automate). What you cannot do is get a public certificate for `intranet` or `10.0.0.5` — that door was closed in 2016, and clicking past the warning isn't a fix, it's turning off the check.

Views: 27

NET::ERR_CERT_NON_UNIQUE_NAME: Internal Name Cert

NET::ERR_CERT_NON_UNIQUE_NAME means the cert covers an internal name or private IP no public CA may certify. Fix in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome refuses the page with NET::ERR_CERT_NON_UNIQUE_NAME and a “Your connection is not private” screen. The certificate might not be expired. The name might match perfectly. The chain might resolve. None of that matters here, because this error isn’t about whether the certificate fits the host — it’s about the host name itself being one that no publicly-trusted certificate is allowed to cover.

Chrome’s own error table is blunt about it: error code -210, “The host name specified in the certificate is not unique.” A non-unique name is one that more than one network can legitimately claim — an internal hostname like intranet or server.local, a single-label name with no public domain behind it, or a private/reserved IP address like 192.168.1.10 or 10.0.0.5. Those names aren’t yours in any way a certificate authority can verify, so the rules forbid certifying them, and Chrome enforces the rule.

Symptoms

The error is NET::ERR_CERT_NON_UNIQUE_NAME, not the more common ERR_CERT_COMMON_NAME_INVALID — the distinction matters, because here the name may match the cert exactly and still be rejected.
It shows up on internal tools reached by short names (https://git, https://wiki) or by private IP (https://192.168.x.x).
The certificate looks otherwise valid — correct name, unexpired, complete chain — which is what makes it confusing.
The same certificate is accepted when it chains to a CA you installed yourself, and rejected when it chains to a public root.
It often appears after moving an internal service behind a public certificate, or after a corporate device shipped with a cert minted for a bare internal name.

Why the Name Is the Problem

Every other certificate error is about a property of the certificate: it expired, the chain is broken, the signature is weak, the name doesn’t match. NET::ERR_CERT_NON_UNIQUE_NAME is different. The certificate can be flawless and still be refused, because the thing that’s wrong is that a public CA vouched for a name that belongs to no one in particular.

The CA/Browser Forum Baseline Requirements settled this years ago. Internal server names and reserved IP addresses were deprecated in publicly-trusted certificates: CAs stopped issuing them in November 2015 and were required to revoke any outstanding ones by October 1, 2016. The reason is the one a security tool cares about most. A name like mail is not unique — countless networks have a mail host — so a CA has no way to verify that the party asking for a mail certificate is the “real” one, because there is no real one. Issue that certificate and you’ve handed out a publicly-trusted credential that impersonates mail on every network it touches. That’s a man-in-the-middle kit with a valid padlock.

So the fix is never to force a public CA to do the forbidden thing. It’s to make the name unique (a real subdomain of a domain you own) or to certify it from an authority you control and trust yourself (a private/internal CA). Chrome accepts a non-unique name from a locally-installed root precisely because you took responsibility for it; it refuses one from a public root because no public authority is permitted to.

Top Causes

A short internal hostname reached over HTTPS - https://git, https://wiki, https://nas — single-label names with no public domain. There is no globally-unique name for a certificate to bind to, so any public cert over it is invalid by policy and Chrome throws NON_UNIQUE_NAME.
HTTPS straight to a private IP - Hitting https://192.168.1.20 or https://10.0.0.5 directly. RFC 1918 addresses are reserved and shared by every private network on earth, so they’re the definition of non-unique. Public CAs can’t certify them.
An old certificate minted for an internal name before the 2016 cutoff - Legacy appliances, corporate PKI exports, or a device that shipped with a factory certificate for a bare internal name. It may still be installed and served, but modern Chrome now rejects the non-unique name it covers.
A public certificate mistakenly issued or expected for an internal endpoint - Someone tried to secure an internal-only service with a normal public certificate and put the internal name in it. The name, not the issuance, is the blocker.

Diagnose with DechoNet

SSL Check inspects the certificate the host actually presents and shows the names it covers and the chain it builds. That’s the fast fork: if the certificate names a bare internal label or a private IP, you’ve confirmed the non-unique name is the problem and the fix is a real name or a private CA — not a reissue from a public one.
DNS Check confirms what the name resolves to. If the hostname points at an RFC 1918 private address, that’s the reserved-IP case; if it’s a single label with no domain, that’s the internal-name case. Knowing which one you’re in decides whether you rename the service or stand up an internal CA.

Resolution Checklist

Identify the name in the certificate. Run an SSL check and read the subject and SAN entries. A bare label (git), a .local/internal-only name, or a private IP is the non-unique name Chrome is refusing.
Decide the target name. If the service can carry a real, globally-unique name, give it a subdomain of a domain you own (e.g. git.internal.example.com) — it can still resolve only inside your network.
For a real unique name, get a normal certificate. Public CAs will issue for a name you control even if it resolves privately; internal DNS handles the resolution.
For internal-only names or private IPs, stand up an internal CA. Issue the certificate from it and distribute that CA’s root to every client’s trust store. Tools like mkcert automate exactly this for dev and small internal fleets.
Never try to buy a public certificate for intranet, .local, or a private IP — no public CA can issue one, and any that exists is a policy violation that will keep failing.
Don’t just click through the warning. Bypassing NON_UNIQUE_NAME disables the check that stops a shared, impersonable name from being trusted. Fix the name or the issuer instead.

When to Escalate

If the name belongs to a managed appliance or corporate PKI you don’t administer, escalate to whoever owns it — the certificate or the CA has to be reissued at that layer, and you can’t fix a non-unique name from the client side.
If an internal service genuinely needs to be reachable by a private IP with a trusted certificate, that’s an internal-CA project, not a one-off cert purchase. Loop in whoever manages your trust-store distribution before piling on per-device workarounds.