Thanks again for your work @Diss31 and sorry for not merging your pull-request. The reason for this is that I would like to avoid merging features in that are really specific.
I did have some thinking about this and one way I could see this working in a more generic way is by generating a client certificate instead of a MQTT token. How this would look like:
- In the
chirpstack-network-server.toml you configure a CA certificate & key file which is used for signing (optional). I believe this config belongs here and not in the AS configuration because there could be different network servers with different MQTT brokers and thus different CA certificates.
- The gateway client certificate contains the gateway EUI as common-name.
- In the web-interface, there is an option to download the gateway client certificate. I think this should be independent of creating a gateway. E.g. when the CA certificate changes, you want to download a new certificate. Or when you are upgrading to the new version, you want to be able to get the certificate without upgrading again.
I believe this could also work together with the GCP and Azure integrations, as it is possible to configure a CA certificate in Cloud IoT Core and Azure IoT Hub to validate the client certificates. It should also be possible to use this client certificate when using the BasicStation.
In case of Mosquitto, it is possible to use the client certificate CN as username, so this could work nicely with @iegomez his plugin too.
I could even see an option for a simplified plugin which could work independently of a database. When it knows the gateway ID (from the certificate CN), it can use a template to authorize on which topics the client can publish and subscribe.
What do you think about this?