[Bug] Get valid LE intermediate certs to tak client zip

[benjamsf]

Bug

Get valid LE intermediate certs to tak client zip, in deployments using LE to sign certs.

What I expected

Working connection using ATAK, WinTAK and iTAK.

What I got

Working connection with iTAK, scratch DataSync; ATAK & WinTAK giving errors.

Why

ATAK and WinTAK has to be explicitly told on what LE intermediate CAs they trust for connection (apparently - working to confirm this, at least on Fall 2023 when working on it, this seem to be the case).

Python-tak-rmapi, at the moment of finding the bug, got the LE intermediate CA to be dropped into the zip, from here: https://github.com/pvarki/python-tak-rmapi/tree/613a9ff56194bd2661771ae25057a9072a2e54fd/src/takrmapi/templates. In there is/was just the LE's "RN3" intermediate CA: https://github.com/pvarki/python-tak-rmapi/blob/613a9ff56194bd2661771ae25057a9072a2e54fd/src/takrmapi/templates/isrg-r3_x1.pem.

Starting from June 2024, LE started to use the RN10 intermediate CA. Thus new deployments got RN10-signed certs in them. The outcome is a mismatch between server and ATAK client trusted certs: server presents LE RN10 while client trusts LE RN3. This problem is/was not evident on any cli or iTAK as for those (for iTAK, apparently) trust whatever certs system trusts.

Error flow

1. When loading takclientzip to ATAK or WinTAK, I expected a working connection. Instead got the error (on ATAK, similar on WinTAK):

Remote host's certificate not trusted; check truststore

2. Loading takclientzip to iTAK, everything worked well.
3. Trying manually to connect using openssl, got to the CoT stream aswell and found that server presents LE RN10 intermediate CA:

Connecting to REDACTED...
CONNECTED(00000005)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R10
verify return:1
depth=0 CN="mtls.OUR-SERVER-REDACTED.com"
verify return:1
---
Certificate chain
 0 s:CN="mtls.OUR-SERVER-REDACTED.com"
   i:C=US, O=Let's Encrypt, CN=R10
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jul 10 10:39:29 2024 GMT; NotAfter: Oct  8 10:39:28 2024 GMT
-----BEGIN CERTIFICATE-----
...
read R BLOCK
<?xml version="1.0" encoding="UTF-8"?>
<event version="2.0" uid="(my uid here)" type="t-x-takp-v" time="2024-07-12T14:50:39Z" start="2024-07-12T14:50:39Z" stale="2024-07-12T14:51:39Z" how="m-g"><point lat="0.0" lon="0.0" hae="0.0" ce="999999" le="999999"/><detail><TakControl><TakProtocolSupport version="1"/><TakServerVersionInfo serverVersion="5.1-RELEASE-11-HEAD" apiVersion="3"/></TakControl></detail></event>^C

4. Examining client certs, there is LE RN3 cert present.

How to Fix

We need to make python-tak-rmapi templates zip to work so, that all relevant LE intermediate CA chains get inside the client zip / the selection is somehow sane instead of fixed files "dropped" here.

[benjamsf]

This will be closed with #61, as soon we merge it (and that happens when we zero out that pr's effect in the SSLV3 bad cert bug #63