[Bug] SSLV3_BAD_CERTS in ATAK (sometimes), not in iTAK & WinTAK

[benjamsf]

Issue (after discussion here)

Trying the PR#61, [which makes handling of LE intermediates, that would be shipped to clients via truststore, better], we noticed this "SSLV3_ALERT_BAD_CERTIFICATE" error which appears either in logs or in logs & graphically. The bug concerns some 50-80% of ATAK devices we tested. In all cases, the error seem take place when the device tries to load Device Profiles from the server.

We get connection and truststore with correct, dynamically imported R10 / R11 intermediates, but with atak we get this:

• "SSLV3_ALERT_BAD_CERTIFICATE"
• iTAK & WinTAK is not affected.
• Some ATAK users will get a graphical error like below:
  
• ...while some has that just in logs.

What was expected

Errorless connection to TAK server with ATAK.

Findings so far

• With the dirtyfix pr that makes sure the truststore has: server cert, intermediate, root in this order, got same error in log, but not graphically.
• Most users will get the error logged.
• Some get the graphical error.
• Some got no error in log & no graphical errors.
• When the error appears at log, it regards to api call about deviceprofile management at port 8443:
• Sequence start

2024-07-18T17:46:56.470Z [DeviceProfileClient]: getProfile request: tak.FQDN/false/true/true/null/na/null/35362db0-56ff-4002-a55b-d2b9ee879366
2024-07-18T17:46:56.478Z [HTTPRequestService]: onCreate()
2024-07-18T17:46:56.478Z [HTTPRequestService]: service starting.
2024-07-18T17:46:56.479Z [HTTPRequestService]: Using cached operation with request type: -84296797
2024-07-18T17:46:56.480Z [CertificateManager]: creating socketFactory for : https://tak.FQDN:8443/Marti,true

When the error is logged:

2024-07-18T14:12:36.499Z [KeyManagerFactory]: getKeyManagers called with invalid server: tak.FQDN
2024-07-18T14:12:36.501Z [DeviceProfileOperation]: Getting profile: GET https://tak.FQDN:8443/Marti/api/device/profile/connection?syncSecago=1721311956&clientUid=ANDROID-6ddb16b80f76334e HTTP/1.1
2024-07-18T14:12:36.503Z [TakHttpClient]: executing request GET https://tak.FQDN:8443/Marti/api/device/profile/connection?syncSecago=1721311956&clientUid=ANDROID-6ddb16b80f76334e HTTP/1.1
( ... )
2024-07-18T14:12:36.586Z [DeviceProfileOperation]: DeviceProfileRequest failed3
javax.net.ssl.SSLProtocolException: Read error: ssl=0x7786fbffc8: Failure in SSL library, usually a protocol error
error:10000412:SSL routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE (external/boringssl/src/ssl/tls_record.cc:587 0x773a22c308:0x00000001)

The same sequence without errors:

2024-07-18T17:46:56.601Z [CotService]: Truststore is valid for: tak.FQDN, CN=mtls.FQDN: true
2024-07-18T17:46:56.616Z [TakHttpClient]: executing request GET https://tak.FQDN:8443/Marti/api/version/config HTTP/1.1
(...)
2024-07-18T17:46:56.625Z [TakHttpClient]: executing request GET https://tak.FQDN:8443/Marti/api/clientEndPoints HTTP/1.1
2024-07-18T17:46:56.625Z [DeviceProfileOperation]: Getting profile: GET https:/tak.FQDN:8443/Marti/api/device/profile/connection?syncSecago=4004&clientUid=ANDROID-b2f477ffc0335001 HTTP/1.1
2024-07-18T17:46:56.625Z [TakHttpClient]: executing request GET https://tak.FQDN:8443/Marti/api/device/profile/connection?syncSecago=4004&clientUid=ANDROID-b2f477ffc0335001 HTTP/1.1
2024-07-18T17:46:57.002Z [GLMapRenderer]: map framerate (f/s) = 29.69121140142518
2024-07-18T17:46:57.011Z [TakHttpResponse]: Op: GET https://tak.FQDN:8443/Marti/api/clientEndPoints HTTP/1.1, response: 200
2024-07-18T17:46:57.011Z [TakHttpResponse]: Op: GET https:/tak.FQDN:8443/Marti/api/device/profile/connection?syncSecago=4004&clientUid=ANDROID-b2f477ffc0335001 HTTP/1.1, response: 204
```

After extensive testing & trying, I think the changes itself are good, if they ship the certs in correct order - last thing to check. If so, this is ATAK not liking new LE intermediates, or possibly our config error in deviceprofile loading feature. Might just be that we need to have the cert to say "CN=tak.fqdn" instead of "CN=mtls.fqdn" at port 8443. Somehow, everything works with port 8089 with no complaints & exactly same cert config, though.

Possible causes?

1. The server's cert response at tak.FQDN says "CN=mtls.FQDN" - mismatch of which some devices complain?
2. Are we double sure that the changes in PR#61 will ship the certs in correct order - LE intermediate signed servercert, LE intermediate used, LE rootX1?
3. ATAK does not like/trust new LE intermediates?
4. ATAK expects something else at the client truststore, to correctly trust our server?