Remove authenticating LoRaWAN Backend Interfaces clients with TLS client authentication. This removes the validation logic for the certificate authority (CA) per SenderID.
Current Situation
Currently, interop.sender-client-ca contains CA configuration per SenderID. When a LoRaWAN Backend Interfaces client presents a certificate, The Things Stack validates it against the trusted CA with the given SenderID.
Why do we need this? Who uses it, and when?
We don't use this anymore; The Things Stack is no longer intended to be used as a stand-alone Join Server or roaming server.
Proposed Implementation
Remove certificate validation logic from the server pkg/interop.
The client should still support presenting TLS client certificates as other products likely require TLS client authentication.
Contributing
[X] I can help by doing more research.
[X] I can help by implementing the feature after the proposal above is approved.
[X] I can help by testing the feature before it's released.
Summary
Remove authenticating LoRaWAN Backend Interfaces clients with TLS client authentication. This removes the validation logic for the certificate authority (CA) per
SenderID
.Current Situation
Currently,
interop.sender-client-ca
contains CA configuration perSenderID
. When a LoRaWAN Backend Interfaces client presents a certificate, The Things Stack validates it against the trusted CA with the givenSenderID
.Why do we need this? Who uses it, and when?
We don't use this anymore; The Things Stack is no longer intended to be used as a stand-alone Join Server or roaming server.
Proposed Implementation
Remove certificate validation logic from the server
pkg/interop
.The client should still support presenting TLS client certificates as other products likely require TLS client authentication.
Contributing
Code of Conduct