# Preauthorizing devices based on root certificate?

**URL:** <https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365>\
**Category:** General Discussions\
**Created:** [December 17, 2019, 12:46am UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365 "2019-12-17T00:46:40Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![samlewis](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/samlewis/32/393_2.png) [@samlewis](https://hub.mender.io/u/samlewis)\
**Post date:** [December 17, 2019, 12:46am UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365/1 "2019-12-17T00:46:40Z")

</div>

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](https://docs.aws.amazon.com/iot/latest/developerguide/jit-provisioning.html) 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.

---

<div class="post-metadata">

**Author:** ![eystein](https://avatars.discourse-cdn.com/v4/letter/e/e5b9ba/32.png) [@eystein](https://hub.mender.io/u/eystein)\
**Post date:** [December 17, 2019, 6:19pm UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365/2 "2019-12-17T18:19:04Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![grandfield](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/grandfield/32/949_2.png) [@grandfield](https://hub.mender.io/u/grandfield)\
**Post date:** [December 15, 2020, 1:03pm UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365/3 "2020-12-15T13:03:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![grandfield](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/grandfield/32/949_2.png) [@grandfield](https://hub.mender.io/u/grandfield)\
**Post date:** [December 15, 2020, 1:06pm UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365/4 "2020-12-15T13:06:30Z")

</div>

@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 ?

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [December 15, 2020, 2:52pm UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365/5 "2020-12-15T14:52:45Z")

</div>

Just an FYI, this is something we support today, [Mutual TLS authentication | Mender documentation](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.

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [December 15, 2020, 2:54pm UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365/6 "2020-12-15T14:54:43Z")

</div>

> [@grandfield](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![grandfield](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/grandfield/32/949_2.png) [@grandfield](https://hub.mender.io/u/grandfield)\
**Post date:** [December 15, 2020, 4:44pm UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365/7 "2020-12-15T16:44:43Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![eystein](https://avatars.discourse-cdn.com/v4/letter/e/e5b9ba/32.png) [@eystein](https://hub.mender.io/u/eystein)\
**Post date:** [December 15, 2020, 7:10pm UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365/8 "2020-12-15T19:10:04Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![tranchitella](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/tranchitella/32/606_2.png) [@tranchitella](https://hub.mender.io/u/tranchitella)\
**Post date:** [January 4, 2021, 9:11am UTC](https://hub.mender.io/t/preauthorizing-devices-based-on-root-certificate/1365/9 "2021-01-04T09:11:54Z")

</div>

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.
