Sensor+ configuration
Sensor+ offers advanced integrations with third-party servers.
- TAK
- Sapient
- Flytbase
TAK (Tactical Awareness Kit)

TAK offers unsecured and secured communication. Secured communication uses certificates that come in three possible ways to the Scout client
- as separate PEM files (one for CA - the server certificate, one for client certificate, and one for client's private key);
- as P12 bundle - this file contains all three mentioned PEM files bundled together;
- from enrollment process (will be described later)
Basic settings

URL: specify host (e.g. tak.example.com) or ip (e.g. 10.1.1.25). If your server uses standard ports (8088 unsecured, 8089 secured) then you don't need to specify the port. If you want to use unsecured UDP version, use "Force UDP" switch.
SOURCES: you should keep drones and status messages. The only meaningful change is (un)checking aviation if
you don't want to see surrounding airplanes in your TAK.
Force UDP: if your server supports only UDP protocol then check this option. UDP cannot be secured nor verified ( connection failure will never be reported).
Security settings

The suggested setup is to have all security features enabled (security, verify server cert, verify server domain). This will ensure server certificate is enforced and thoroughly checked. If the server certificate doesn't have its domain/IP correctly filled in, then you can disable the domain/IP check to accept even such certificate and keep your comms secured. In this case, either your server needs to use globally recognized CA such as Let's Encrypt or you need to supply your CA's certificate into the first field "Server CA Certificate" in PEM format. There is the option to use p12 bundle with "P12 Trust Bundled RootCA" that will take CA certificate from the last certificate from the bundle.
CERTIFICATE VERIFY FAILED

The image on the right shows the error when Scout cannot verify server's certificate. Please note that the CA certificate must be server's root CA. It cannot be an intermediate CA. You have a few solutions
- If you are using p12 bundle and the server's certificate has the same RootCA as the certificate in the bundle then use "P12 Trust Bundled RootCA". This will extract the top-level certificate from the p12 bundle and use it as trusted certificate for verifying the server.
- If you are using p12 bundle (and have "P12 Trust Bundled RootCA" to "No") or not using the p12 at all - in both cases the "Server CA Certificate" will be used in you have checked "Verify Server Cert". Make sure it is the top-level rootCA.
- As a temporary fix, you can uncheck "Verify Server Cert" and "Verify Server Domain/IP" in case of problems and the client will simply accept any certificate that the server gives you. This is not secure at all of course.
Client Certificates

For secured communication from client to server, you must specify "Client Certificate" and "Client Key" either as separate PEM files or in a P12 bundle. If you upload both PEM and P12, only the P12 will be used. Optionally, PEM Key can be password protected. In this case use the "Client Key Password" field. Keys in P12 must not be password protected. Usually the bundle itself is protected hence the field "P12 Bundle Password".
If any of those displayed errors appear that means your client certificates were rejected by the server or are outright invalid.
[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error[SSL: TLSV13_ALERT_CERTIFICATE_REQUIRED] tlsv13 alert certificate required
ENROLLMENT

If you don't have certificates but you were given username, password and optionally a passphrase then you should use those in the authentication section together with setting Enroll to "yes". Those credentials are used in standard enrollment process using Marti API on port 8446. We currently do not support custom certificates for secured communication during enrollment but it will be part of the next release. If your enrollment server is running at a different port or even url then use provided Enrollment URL.