Comment by seiferteric | Hacker News Reader

Comment by seiferteric | Hacker News Reader

Parent Full thread

Cool, but as others said fairly easy to do on your own already. Sort of related but a problem I have been trying to solve is, how to create a trusted certificate for a new device on a private network automatically without any configuration? For example, imagine you are turning up a new router or switch with a Web UI for management. Traditionally this is served on http initially and you can optionally install a cert and enable https. It would be nice to have a way to have this happen automatically to obviate the need for http at all. Also consider that this private network may not be connected to the internet at all and so can't rely on outside servers.

I was kicking around the idea for an rfc that would be something like this. Your DHCP server would have an option to act as a CA (or point at one), with ACME protocol enabled. Then, you add DHCP option fields telling clients to trust this new CA certificate, but only for hosts on this local network (to avoid being able to MITM outside connections). Then clients on this network would be able to request certificates from the CA using ACME automatically and others on the network would automatically trust them assuming support for this standard was added the OS or browsers etc.

There is SCEP (https://en.m.wikipedia.org/wiki/Simple_Certificate_Enrollmen...) which allows that and is often found on network devices. You need a PKI which exposes a SCEP endpoint (ejbca or dogtag supports this). That the certificate is used as certificate for the HTTPS is up to the device implementation of the scep client or something else in the client though.

On servers, certmonger can do scep iirc. On private infrastructure, FreeIPA provides a packaged dogtag and you can create your own certificate profiles. Clients enrolled in freeipa have certmonger installed to refresh certificates.

> You need a PKI which exposes a SCEP endpoint (ejbca or dogtag supports this).

Uhh...

> [...] ejbca [...]

Now you have two problems.

What I mean is, if you’ve been already running EJBCA for whatever reason then this is perhaps reasonable, but if your current setup is at the level of typing `openssl req` into a terminal (whether that’s a good idea or not), it sounds like a lot of additional complexity. (Can’t say anything about dogtag.)

I’ve been waiting forever for somebody to add an ACME backend to the Go SCEP library[1], but it doesn’t look like that has happened. In the meantime it includes a fairly competent standalone CA server at the abovementioned invoke-openssl-by-hand level.

Note that SCEP basically requires a trusted network, though, from what I remember.

[1] https://github.com/micromdm/scep

You can get somewhat close to that with getlocalcert. When the device first boots, it calls the getlocalcert API to register a free, anonymous domain name (negative: its a UUID domain, ugly). You'd need outbound connections to api.getlocalcert.net and an ACME certificate authority (Let's Encrypt) to issue a ccertificate. When the user connects to http://<ip-address> it redirects to https://<uuid>.localcert.net, which the browser trusts since the cert is from a public CA. No need to manually trust a cert. The user would bookmark it and all future use is HTTPS-only.

If I see usage like this, there's ways I can make this cleaner.

> it calls the getlocalcert API to register a free, anonymous domain name

...rather than to get an actual certificate.

I didn't dig past the front page, but as far as I can see, they don't issue HTTPS certs at all, easy or oherwise; they offer managed DNS subdomains. You want a cert, you have to get it somewhere else.

As a security engineer I'm wary of tools that offer to issue certificates for you. You've got to trust that they won't keep a copy of your private key. ACME clients [1] generate keys on your device, which is the recommended way.

But you're right. Issuing Let's Encrypt certificates on behalf of users could simplify the process even more.

[1] https://docs.getlocalcert.net/acme-clients/#setting-txt-reco...

Solved.

Solved for both Windows and Linux (Debian, Arch, Fedora). I might have unlikely solved this of OSX as well, but I am not buying Apply hardware just to test it.

What my solution does is check for certificates created by the project during a build step. If the certificates don't exist it creates them, installs them in the OS, and also installs them in the browser. Installation in the browsers is required in Linux and only for FireFox in Windows. These are cert chains containing a self-signed root, intermediary CA, and a local domain cert.

I have these certs configured to work with my own domains so that I can connect to a subdomain addressed to a loopback IP and the cert recognizes that domain, but the domain "localhost" works as well. Sometimes its nice to access a real domain to avoid any restrictions imposed upon accessing address "localhost". You just have to change the domains at the bottom of your OpenSSL option files.

Here is how I solved it with vanilla TypeScript in Node.js (also requires locally installed OpenSSL):

* OpenSSL option file 1 - https://github.com/prettydiff/share-file-systems/blob/master...

* OpenSSL option file 2 - https://github.com/prettydiff/share-file-systems/blob/master...

* Certificate library - https://github.com/prettydiff/share-file-systems/blob/master...

* Certificate interface from build tool - https://github.com/prettydiff/share-file-systems/blob/master...

* Certificate installation - https://github.com/prettydiff/share-file-systems/blob/master...

If you have any questions just open a Github issue on the project.

Sounds like you're describing a process similar to SCP over HTTPs. That is available (albeit windows hosted) and fully functional across any client OS.

Sounds like BRSKI [1].

[1]: https://datatracker.ietf.org/doc/rfc8995/

Reply on news.ycombinator.com