[RFC] self-signed certificates for LuCI

Henrique de Moraes Holschuh henrique at nic.br
Mon Aug 31 14:17:26 EDT 2020


On 31/08/2020 14:26, Michael Richardson wrote:
> Yes, many many many devices will break.
> But browser makers don't really care about that.
> This is a no-win situation until we can find a way to give proper names and
> certificates to devices.

And offloading this into Let's Encrypt is **NOT** an answer unless 
you're on the low end of a thousand certificates, and maybe not even 
that much.

Fortunately, the sheer pain of trying to juggle the update schedule of a 
largish number of certificates with current Let's Encrypt quotas is 
already deterrent enough -- I assume most around here would agree that 
it is in the best interest of society as a whole that we do NOT 
endanger, nor allow the usual suspects to push us into endangering, 
Let's Encrypt long-term viability.

The typical enterprise-ish solution to this (which is no problem for 
Let's Encrypt or any other CA) is to have a cloud gateway, where you 
need at most a hundred browser-PKI-blessed certificates, and several 
orders of magnitudes more private-CA-issued certificates for the devices 
to talk to the backend API endpoints.

The user has no HTTPS support unless he goes through the cloud. Initial 
provisioning is http and self-signed-https, and stops working as soon as 
cloud connectivity "happens".

It is a solution makes one want to puke, but it is one of the few viable 
at the moment.

> As long as users are being trained to override certificate exceptions, then
> the certificate provides very little benefit.
Agreed, but it is mandatory in some circumstances.

It would be *nice* if we could easily deploy extremely restricted 
self-signed CAs that can only sign a numeric pattern hostname under 
<device>.iot.<your>.<domain>.  That extremely restricted CA would get 
"approved" by something from <your>.<domain> that the browser would use 
to stop pestering the user of <device>: be that a certificate chaining 
from <your>.<domain>, or DNSSEC, or whatever.

Well, one can hope and dream...

-- 
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações 
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br



More information about the openwrt-devel mailing list