Preauthorizing devices based on root certificate?

My devices have device certificates that are generated from a root certificate that I control. I use the device certificates as the certificate that devices use to authenticate to the Mender server with (mender-agent.pem)

Rather than needing to upload each device’s certificates in order to preauthorize devices, would it be possible to preauthorize all device certs generated from my root certificate? This is similar to the AWS IoT ‘JIT’ provisioning flow.

This would make preauthorization much easier for my use case, as it wouldn’t be necessary to keep a record of each generated device certificate.

1 Like

Hi @samlewis!

Mender does not currently support Client-side certificates, and authentication is based on public keypairs for the client (and certificates for the server).

What you are describing requires support for Client certificates. The reason Mender is using keypairs to authenticate the client instead of certificates is that managing a PKI (issuing client certificates, managing root CAs, intermetidate certificates, expiry, revocation, etc.) is a big undertaking that we did not want to force every Mender user to take on.

All that said we are looking into adding support for Client certificates as well. There is currently no ETA (being researched) and it might be that at least part of this support will be commercial-grade feature because it is typically a problem that relates to scaling & a use case for larger fleets.

So hopefully you will manage with the more “manual” approach until this support is in place.

Hope that makes sense and let us know if you have any questions or feedback on this.

This would be very useful for preventing DOS attacks by allowing an external loadbalancer to verify the client cert before passthrough to the mender-api-gateway. @samlewis, in my research… (i’m not affiliated with mender)… I have disabled the “pending” feature in the device auth. Its a single line change. This will greatly reduce the computational load when it comes to preventing DOS attacks because the auth db will not get spammed.

@eystein you mentioned this support as more applicable to commercial fleets, but for small businesses or hobbyists hosting their own server, DOS attacks are still a possibility. Are there mitigations to prevent spamming of the “pending” feature in the self hosted versions ?

Just an FYI, this is something we support today, https://docs.mender.io/server-integration/mutual-tls-authentication (Mender Enterprise only)

Are there mitigations to prevent spamming of the “pending” feature in the self hosted versions ?

Mender Enterprise is available in self-hosted as well, but for open-source I am aware not of anything preventing this, unless there is something done on network level. Though not my area of expertise.

Maybe @tranchitella or @peter have some ideas.

1 Like

This I also find interesting, and wonder it should be considered to be a “configuration feature”. @eystein?

apologies for my misunderstanding. I only recently jumped from mender 2.3 and didn’t spot the new SSLengine

You might be more interested in rate limiting as a general solution to this (DoS attacks do not only apply to Pending devices).

We do have rate limiting support in hosted Mender, though I am not an expert on how to configure this, I think it is a quite standard configuration and approach. Does that make sense?

Rate limiting is an enterprise feature, and it is not available in the open-source version.

The Mender client supports client-side certificate since the 2.5 release (which maps Mender Client version 2.4). You can set up your own reverse proxy in front of the Mender Server, which does the client-side certificate verification if you don’t need mTLS and auto-approval of devices whose certificates are signed by the known CA.