0

I have developed an application that consists of various parts, each part communicating either via http and / or gRPC to one another.
All communication has been switched over to TLS using a self-signed cert (CN=localhost) for development.

However, this application will go into production and it will ONLY EVER run on localhost (Windows machines).
Self-signed certificates are not really an option then, so I'd request an "official" certificate (signed with the org's CA or subordinate CA) which I could then install in the operating sys's certificate store.

Now my question: Is this something that can be done? I know it is awkward to use an officially CA-signed cert for localhost, but that's just what I need. Or is there something else I could do instead?

2
  • Stop. Using. Loopback. Sockets. For. IPC! They are far and away the least secure common form of IPC, they aren't even very performant, they're way more hassle to configure securely, and these days they aren't even meaningfully more portable than local (a.k.a. Unix) domain sockets as those work on Windows as well as *nix. Or if you're Windows-only, you can use named pipes (far more powerful than the *nix feature of the same name). Network sockets should only be used when there's nothing else that will work, almost never true for connecting to "localhost" (which might not even be loopback!)
    – CBHacking
    Sep 1 at 3:50
  • Thanks, I get it ;-) This project is in preparation of another one and it is therefore very over-engineered to have an experimental playground (my v1 is just a console app). In fact, the application can switch over to using IPC (AF_UNIX). In the future the "server" part might get put somewhere else (linux container). However, none of the machines will ever get proper internal DNS names, ip addresses only. Named pipes are an additional option that I might implement for the Windows-only environment.
    – Chris B
    Sep 1 at 5:38

1 Answer 1

1

One can only get a publicly signed certificate for a domain which one controls. The domain localhost is not controlled by somebody, it is on every computer, i.e. controlled by everybody. Therefore it is not possible to get a publicly signed certificate for it.

Self-signed certificates are not really an option

Why? The local browser will ask once if the certificate should be accepted and then remember the choice.

Or is there something else I could do instead?

One hack in the past was to get a domain and get a certificate for it, then map the DNS for this domain to 127.0.0.1 (localhost). But this way you rely on internet connectivity to get the DNS mapping or the domain must be resolved by some internal DNS. And you'll face the problem that you need to regularly install an updated certificate since it will expire after a while. And the certificate might also be revoked because it might be considered compromised - see When are public applications embedding certificates pointing to 127.0.0.1 OK?. Thus, bad idea.

Another option is to not get a publicly issued certificate but to get a company issued one, in case there is already a PKI established in the specific production environment. But also don't use localhost as name here, but the actual DNS name of the machine in this specific environment.

1
  • OK thank you, this confirms my research. I will stick with self-signed certificates then since no one can guarantee any DNS resolving infrastructure whereever the actual deployment will happen (we have some installations w/o any network connections due to security reasons). However, as mentioned above, it is mainly an experimental app testing out gRPC on http/2 vs IPC performance. Thank you for the input.
    – Chris B
    Sep 1 at 5:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.