[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