This won't work either, btw: You'd have to request from Let's Encrypt a new certificate for each individual device. LE has several rate limits that will prevent that from working for anything more than a trivial number of devices: https://letsencrypt.org/docs/rate-limits/

The only way I see how this would work is if you not just purchase a domain but also an internet-facing server and do the renewal and certificate management centrally for all devices - at which point, your device is definitly not standalone anymore.

This will work fine. LetsEncrypt will raise ratelimits for you. I've done it for a commercial CDN and they were very accommodating and helpful.

Plex does this, for example, though they use DigiCert's free certificates: https://www.plex.tv/blog/its-not-easy-being-green-secure-com...

The LE rate limits are (mostly?) for new cert issuance. I’ve never run into a rate limit on automated renewals and seem to recall it was either non-existent or comically far away from anything any individual would hit.

You can do wildcard certs with LE, I run hundreds of k8s services all secured with LE and wildcard certs.

We're talking about customer hardware. If someone looks at the insides of the device and finds, of course, the private key for your one shared wildcard certificate, the issuer is required to invalidate it immediately.

You can, but that wouldn't quite work for the prosumer router manufacturer case the OP mentioned: LE would revoke the cert once you distributed it.

You can, but, you can't (by policy) distribute keys across multiple customers.

I have a nasty habit of requesting revocation of such compromised keys whenever I find them. CAs are required to revoke within 24 hours, I think, though unfortunately revocation is surprisingly ineffective.

Do you actually find those often? I've actually never seen one. I will admit I've also never specifically looked very hard.

I'd say one every couple of years.

https://letsencrypt.org/docs/certificates-for-localhost/ has great documentation on that topic, including more examples.

This is a ridiculous requirement that is not at all practical.

How is it not practical? It's really not hard to set up and there is great documentation out there

I get the feeling you have no real experience either running a company network or dealing with end users and home networks. Any of these solutions work fine for a majority of people who just use their laptop in Starbucks, but they really break down when you need to start doing anything more complicated than that.

Please, educate me as to what I am overlooking. The requirements of buying a domain name and getting a LE wildcard cert should be trivial to someone with the experience you seem to have.

Why would the average customer of IoT products have the same expertise as the person you are replying to?

All of these juvinile "It's easy! just implement ${SUPER COMPLICATED INFRASTRUCTURE WITH SPECIFIC REQUIREMENTS AND LIMITATIONS I'M GOING TO TO PRETEND AWAY}" replies from eager-idiot hacker tweens is just trolling.

You can also run your own CA.

> This is a ridiculous requirement that is not at all practical.

Really. This: https://jamielinux.com/docs/openssl-certificate-authority/ gives you a CA in about an hour. HashiCorp Vault will give you a CA in 5 minutes. certstrap will give you a CA in 15 seconds. It’s 2020, it ain’t voodoo anymore.

Just spinning up a CA is a couple of commands. Running one sanely (to include security of the private keys, availability and auditability of the signing machine, keeping backups, publishing a CRL, setting up ACME if you want any kind of automation) is significantly more involved.

But this is silly. If this isn’t completely trivial to add to your app then something has gone horribly wrong.

* Every machine in your infra already has backups, right? Nothing about your signing boxes are special in this regard.

* All your services are already HA, right? The API servers that now have to run some glorified OpenSSL commands aren’t any different than your normal API endpoints.

* You already have to protect secrets on your machines. DB passwords, API keys. What’s one more?

* You don’t have to implement ACME. These are your devices talking to your devices.

Nothing different than any long lived component in any infrastructure. There is no reason to look for reasons not to use a CA.

For a company? Absolutely not. In private? Probably not worth the effort, just skip the cert warning.

Most hardware in this category really needs to be set-and-forget, whether online or not. You can't have every random sound system and light controller having to dial out to a third party every month. You need to be able to come back five years later and still be able to configure the hardware.

Without buying a domain. (and continously spending money to keep it owned)

Run your own CA internally and handle the CA distribution problem with MDM tools.

I admit, that's a solution, even if a very unpleasant one: Installing a custom root CA is intentionally complicated, so this is hardly doable as an onboarding experience. The setup must be repreated for every single client device that should access the server.

There remains the question how I would get the CA certificate onto client devices in the first place.

Lastly, with asking consumers to install a CA certificate, I ask for a significantly more powerful permission than if I could just have them trust my certificate. This seems like a step backwards security-wise.

> Lastly, with asking consumers to install a CA certificate, I ask for a significantly more powerful permission than if I could just have them trust my certificate.

CA certificates can be constrained. https://tools.ietf.org/html/rfc5280#section-4.2.1.10

Are common certificate validation libraries honoring these constraints?

When I tried to use this many moons ago, most things ignored the constraints; although I could mark the extension critical, and then some (but not all, yay) of the things that didn't understand would refuse the CA.

IDK NSS seems to have code to verify it:

https://searchfox.org/mozilla-central/source/security/nss/li...

As does webpki:

https://github.com/briansmith/webpki/blob/482627c40dad2148da...

But haven't tested it (or checked other libraries).

Update: tested it with openssl and webpki. both claim to have support but it only works with openssl. For webpki I had to file two bugs:

https://github.com/briansmith/webpki/issues/134

https://github.com/briansmith/webpki/issues/135

Can you name and shame those that ignored the critical extension? Sounds CVE-worthy. A date to guess the versions you used would also help.

No, it was on the order of 5 years ago; everybody was garbage back then. But, if this had become usable, I would expect to have seen articles about using it since then.

How do you actually generate a constrained CA certificate? I have tried to do this for a long time but openssl is inscrutable.

There seems to be a guide for openssl here [0] but it seems kinda complicated. This discussion inspired me to add name constraints support to rcgen [2]. If you aren't afraid to write Rust, you should give using it a try.

[0] https://www.marcanoonline.com/post/2016/09/restrict-certific...

[1] https://tools.ietf.org/html/rfc5280#page-41

[2] https://github.com/est31/rcgen/commit/059cc19fcd1b8bb57feed5...

Thanks!

It is no more complicated than a self signed certificate. Two clicks in Firefox, 4 taps in iOS

Every time and no tracking if device indentity changes.

That is also an insane and unrealistic suggestion.

~$5/year (US) for a domain, and a one time investment of setting up a few scripts might save you a lot of time in the long run.

Honestly, my main issue is not even the price, it's that devices cannot be stand-alone anymore. Even if my device is purely for LAN use and wouldn't need the internet at all, I now need to ensure it has an internet connection and I have to keep a domain owned that must be constantly renewed.

The device will also only be accessible if an internet connection is present, even if both the device and the client are in the same LAN - because the client has to access the device through the domain.

This means, should I ever lose the capacity to support the device and renew the domain, the device will become useless, even if technically, it is still completely functional.

> Honestly, my main issue is not even the price, it's that devices cannot be stand-alone anymore.

That’s not true at all. I’ve created a CA and a script to generate and sign server certificates and I generated them left right and centre now for my very standalone, local network only with no access to the internet whatsoever services. I added my CA to my browsers and my iPhone and everything works perfectly.

Will you also add it to the iPhones of other people that would want to use the device? (Or more realistically, would they let you add it?)

Depends on them I guess. If it's a corporate phone then it's no problem. The rest can either add it or get used to cert warnings.

If you're in a context where you can personally install it on phones of friends and relatives, that will work, I agree.

I'm thinking of an example to illustrate what I mean. (Sorry if this appears to be moving the goalposts)

Imagine some small business is selling a home surveillance camera, or a network printer or whatever else. The thing is that it's a product intended for perivate, layman consumers and intended for LAN use.

With HTTP, you could add a local web server as a simple way to manage the device pretty easily: Just open a server, communicate the IP address to the user, done. No internet connection required, no continuing support from the company required. Even if the company went bust, the existing units continued to work and the web interface stayed accessible.

There seems to be no good way to replicate this with HTTPS. The closest seems indeed to be a custom root CA - however, then you need to communicate to your users how to install the CA certificate on their own devices, clicking through all kinds of scary warnings and dismissing "this section is for admins only" notices. I predict that not a lot of people would do that.

This also leaves you with the challange to safely get the certificate to your users. You could serve the certificate from the device over HTTP - however, then you'll require that your customers download a root certificate, over an unencrypted connection without any integrity checks and install it on their device. This seems like ripping open a mojor security hole.

Meanwhile, even if the company purchases a domain and attempts to get a certificate from a public CA, deployment will be difficult as described in all the other branches of this thread.

In short, I think you can pick any three of the following four conditions, but I see no way to archieve all four at the same time.

(1) use modern web features (all recently added and all future features require https)

(2) have your site usable on a client device that does not belong to you

(3) present a non-confusing user experience (no cert warnings, etc)

(4) have the device stay accessible even after you stop actively supporting it (by purchasing domains, running cloud services, having deals with CAs, etc etc)

> This also leaves you with the challange to safely get the certificate to your users.

Because the hardware vendor does not own nor configure the private network, they are not able to certify to the network’s users that a particular network node is the device it’s supposed to be, and not an impersonator. Only the network administrators can do that, and so it is the network administrators that must generate the certificate and install it on the device. In this way the admins bestow a programatic declaration of trust on the network node.

The device manufacturers can only provide tools for showing that the device was not tampered with. TLS/SSL certificates are not for that purpose.

This only applies if they want to access internal services without cert warnings, so asking them to install a cert seems reasonable?

> Honestly, my main issue is not even the price, it's that devices cannot be stand-alone anymore.

I'm wondering where the impression fo" not any more" comes from. Really the situation hasn't changed much. You can have your HTTP webinterface. You can have HTTPS with a selfsigned cert and click away the warning. The only thing that really has changed is that for your HTTP connection you will get a warning that the connection is not secure.

I don't think the ability of browsers to load HTTP pages will go away any time soon.

Aren't browsers preventing submission of form data over http now?

No. Your DNS can also be locally, so you have no Internet dependence.

A .net is 83 cents a month.

That's usually a limited special offer. Not everyone wants to change domains every year.

There’s always the .local TLD, which is reserved for this use case:

https://en.m.wikipedia.org/wiki/.local

That works, but you can't get public certs for it, because you can't prove you own that domain (indeed, you don't :))

Please remind me where I said anything about public certificates. ;-)

xg15 is going to have to run a self-hosted Certificate Authority (CA) and generate certificates himself.

That article goes on to state that .local is reserved by RFC6762 (multicast DNS), which if you use that domain on your network, will cause problems with any services using it, usually Macs or iPhones.

This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. [...] Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB).

I'd recommend using something like .lan instead.

I think you’re talking about running DNS locally (not sure) and resolving .local addresses by DNS. In that case, yes, the devices that do lookups by mDNS will experience a delay caused by first querying mDNS before falling back onto DNS. The solution is to set up mDNS for the internal resources.

Using an unregistered domain like .lan has serious security implications. See here: https://serverfault.com/a/17566

.lan is called out in appendix G of the MDNS RFC as "not recommended, but many people do this".

Personally speaking, I'm not too worried about .lan getting registered as a gTLD anytime soon. I'm a lot more worried about forgetting to renew my domain and having things horrifically break if/when that domain gets picked up by someone else. This is a lot more likely...

I’m not sure I understand... What would break on your local network if a public domain you own and use only for internal resources is registered by someone else? How is this different from making up a domain name? In both cases you have to set up something to resolve the names to IP addresses on your local network, be it a hosts file or DNS. I would expect that to keep working regardless of the ownership of the domain name.

I would have said the same about .dev, and did, until Google came along and registered it.

Why not just use mDNS too and stick with .local?

I haven't heard about that yet. this sounds interesting indeed. But how would I get a valid certificate for a .local domain?

You need to set up your own “chain of trust” to verify your self-generated certificates. You can run your own Certificate Authority for example. (There are other approaches too.)