--cafile enabling system-trust nevertheless?

[Martin Pauly]

Am 01.09.24 um 06:32 schrieb Daniel Lenski:
> The additive effect of `--cafile` is intentional and is prominently
> mentioned in the OpenConnect manual page for both options, and has
> been for several years. Not sure how we can possibly be more explicit
> than what I added in
> https://gitlab.com/openconnect/openconnect/-/commit/ceab1765db11c15a18a0c605812dbc11afd63e8b
> <https://gitlab.com/openconnect/openconnect/-/commit/ceab1765db11c15a18a0c605812dbc11afd63e8b>,
> but happy for any additional suggestions. 😬

You hardly can, but here's how me and my colleague got lost.
I had read "the" manpage, but I did the testing on an old Ubuntu 20.04 Mate LTS.
Must be a version that Ubuntu had just pulled before said commit, the explanation there simply reads:
Cert file for server verification
So I really got the semantics of --cafile wrong.
Shame on me for not using current systems, that Ubuntu laptop deserves a re-install.

Actually, the original question came from the GUI side, i.e. Network Manager.
A colleague of mine recently stumbled on our outdated documentation recommending to set CA Certificate to the old T-Telesec cert.
He figured out he could connect to my current server (presenting the new USERTrust cert)
no matter what CA element he added of left blank.
When testing, I naïvely assumed the "CA Certificate" would directly translate to --cafile.
Add the old manpage, and you have my perfect misinterpretation.

But a closer look reveals different details yet again, identical on both the old Ubuntu and a current Debian.
No matter what I specify in "CA Certificate", ps always shows this Command line being run in reality:
nm-open+   39622  0.1  0.0  62992 12672 ?        S    11:17   0:00 /usr/sbin/openconnect --servercert pin-sha256:BjvO2hCuK4pVXupG9fmwOAbdsaTc/LORPdn6Al2LRD0= --syslog --cookie-on-stdin --script /usr/lib/NetworkManager/nm-openconnect-service-openconnect-helper --interface vpn0 137.248.1.225:443/+webvpn+/index.html

The pin-sha256:BjvO2hCuK4pVXupG9fmwOAbdsaTc/LORPdn6Al2LRD0=
matches the current USERTrust cert, so Network Manager always seems to call openconnect
as if I had enabled --no-system-trust, but trusted the current USERtrust cert
explicitly -- is this correct?
If so, is this intended behavior?
And: Is there a NM/GUI setting equivalent to --no-system-trust?

(Really sorry to bother, we've turned to a "Once bitten, twice shy" mindset
after we learned that leaving a CA setting blank has proved disastrous
in the context of WiFi supplicants. With openconnect, we're obviously
apart from that kind of problems by a long shot.)

Thanks everyone
Martin

-- 
   Dr. Martin Pauly     Phone:  +49-6421-28-23527
   HRZ Univ. Marburg    Fax:    +49-6421-28-26994
   Hans-Meerwein-Str.   E-Mail: pauly at HRZ.Uni-Marburg.DE
   D-35032 Marburg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20240902/98198673/attachment.p7s>