Another way is to create a regular DNS name, and ave it redirect to localhost. If you are unable or unwilling to do so, there are free DNS services like https://traefik.me/ that provide you with a real domain name and related certificates.
I personally use traefik.me for my hobbyist fiddling, and I have a working HTTP/2 local development experience. It's also very nice to be able to build for production and test the performance locally, without having to deploy to a dev environment.
For people worried about somehow exposing commercially or otherwise sensitive information by the registration of DNS names, a SAN certificate is out because of certificate transparency logs.
A wildcard certificate is safe from that though. Or just choosing names that don't give secrets away.
A certificate signed by a locally trusted CA would work too of course, but unless you already have that setup for other reasons it is a bunch of admin most funny want to touch.
> a SAN certificate is out because of certificate transparency logs
First, all these certificates in the web PKI have SANs in them. X509 was designed for the X500 directory system, so when Netscape repurposed it for their SSL technology they initially used the arbitrary text fields and just wrote DNS names in as text. There are a number of reasons that's a terrible idea, but PKIX, RFC 2459 and its successors, defines a specific OID for "Subject Alternative Names". The word "alternative" here refers to the Internet's names (DNS names and IP addresses) being an alternative to the X500 directory system. PKIX says the legacy names should be phased out and everybody should use SANs.
That rule (you must use SANs in new certificates) was baked into the CA/Browser Forum Baseline Requirements (CA/B BRs or just "BRs" typically) which set the rules for certificates that will actually work in your web browser and thus in practice all the certificates people actually use. Enforcement of this rule was spotty for some time but the advent of CT logging made it possible to immediately spot any cert which violates the rule and so some years ago Google's Chome began to just reject the "legacy" just write it in a text field and hope approach and other browsers followed.
So what you're actually talking about are certificates with two or more specific DNS names rather than a single wildcard.
Secondly though, that's usually all a waste of your time if you're trying to mask the existence of named end points because of Passive DNS. A bunch of providers sell both live and historical feeds of DNS questions and answers. Who asked is not available, so this isn't PII, but if I'm wondering about your "sensitive" names at example.com I can easily ask a Passive DNS service, "Hey, other than www.example.com what else gets asked in similar DNS queries?" and get answers like "mysql.example.com" and "new-product-test.example.com".
Passive DNS isn't free, but then squirrelling away the entire CT log feed isn't free either, it's served free of charge on a small scale, but if you bang on crt.sh hard you'll get turned off.
> First, all these certificates in the web PKI have SANs in them.
Yes, and technically true is the best variety of true, but… Usually people don't refer to certificates where “Subject” is equal to the one and only “Subject Alternative Name”, as SAN certificates.
> So what you're actually talking about are certificates with two or more specific DNS names rather than a single wildcard.
If we are going to nitpick over the SAN designation a basic wildcard certificate is usually a SAN cert too, by the same definition. They have (at least mine always have had):
Subject =
“CN = *.domain.tld”
Subject Alternate Name =
“DNS Name: *.domain.tld
DNS Name: domain.tld”
(or similar for a wildcard hung off a sub-domain)
> "Hey, other than www.example.com what else gets asked in similar DNS queries?"
True, but only if those queries are hitting public DNS somehow. You can hide this by having your local DNS be authoritative for internal domains — your internal requests are never going to outside DNS servers. There could be leaks if someone who normally has access via VPN tries to connect without, but if you have something so truly sensitive that just knowing the name is a problem¹ then I hope your people are more careful than that (or your devices seriously locked down).
And I still say the easy workaround for this is names that only mean something internally. projectwhatthefuck.dev.company.tld is not going to mean much other than giving an attacker compared to projectousurpcompetitor.company.tld. Yes, they'll know the server name, and if it is publicly addressable they can connect to it, but if you have it properly configured they'll have to give it auth information they hopefully won't have before it hands over any useful information beyond the meaningless (to them) name that they already know.
--------
[1] Some of our contracts actually say that we can't reveal that we work with the other party, so technically² we could be in trouble if we leak the company name via DNS (bigwellknowmultinationalbank.ourservice.tld). Though when we offer a different name, in case the link between us can leak out that way, in those cases they've always declined.
[2] Really they don't care that much. They just don't want us to use their name/logo/other in promotional material.
For example, postulate a DNS entry of myTopSecrets mapped to localhost. If you use it, it will be routed to your own computer. If someone else uses it, they would be routed to their own computer. The same follows for IP addresses within your local area network.
Unless you did extra work outside the scope of DNS, nothing in your lan is addressable from outside your lan.
You're still revealing the existence of myTopSecrets to the world, though.
Between this and certificate transparency logs, it seems insane to me that the commonly advised Correct Setup, to be able to experiment and hack random little personal stuff, and have it reliably work on modern browsers, requires you to 1) buy a subscription (domain), 2) enter into another subscription-ish contractual relationship (Let's Encrypt), and 3) announce to the whole world what you're doing (possibly in two places!).
Imagine your computer stops booting up because you repositioned your desk, and everyone tells you the Correct Way to do it is to file a form with the post office, and apply for a free building permit from the local council. That's how this feels.
I totally agree, I have long since accepted that this is how things are but.. that doesn't mean it's right.. it feels like browsers are overtly obstructing the use of the local system as a development platform and local-hosting option. This also includes base-line features like the JS localStorage API that only works when connected to a domain name (localhost is a no-go). That last one in particular just feels perverse to me - in NO WAY should that require a domain name, it feels anti-democratic and clunky as can be. It also 100% stops webapps from being local-first (i.e. I save an HTML/JS bundle to a folder and run the "app", it's automatically isolated to said folder) with network connectivity as a secondary option. If browsers could do the latter then it would be a death-blow to a lot of remaining platform-specific apps.
> You're still revealing the existence of myTopSecrets to the world, though.
Not if you only present that name in local DNS, and use a wildcard certificate to avoid needing to reveal the name via a SAN cert or other externally referable information.
Also, perhaps refrain from calling it myTopSecrets. Perhaps ProjectLooBreak instead.
Couldn't you just add the domain to /etc/hosts and have it resolve that way. No need to buy domain if you are just testing locally. Also you wouldn't be exposing anything to outside world.
Perhaps I could, but I'm afraid to do it[0]. And I'd still need a matching certificate, and generating a one that browsers won't refuse to look at and make them trust it across multiple devices (including mobile) is it's own kind of hell.
--
[0] - I'm honestly afraid of DNS. I keep losing too much of my life to random name resolution failures, whose fixes work non-deterministically. Or at least I was until ~yesterday, when I randomly found out about https://messwithdns.net, and there I learned that nameservers are required to have a negative cache, which they use to cache failed lookups, often with absurdly high timeout values. That little bit of knowledge finally lets me make sense of those problems.
I was only commenting about DNS part, self signed certificates come with their own lot of trouble. At least I havent ever run into any cache issues with local resolvers.
I have previously used https://github.com/jsha/minica which makes it at least easy to create a root certificate and matching server cert. How to get that root cert trusted on different array of devices is another story.
You can add what you want to /etc/hosts, but you need to actually control a domain to get a real cert for it that your browser will trust. Otherwise, you need to mess about with self-signed certs, browser exceptions, etc.
If you already own a domain, it's pretty convenient.
I personally use traefik.me for my hobbyist fiddling, and I have a working HTTP/2 local development experience. It's also very nice to be able to build for production and test the performance locally, without having to deploy to a dev environment.