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: pa...@hrz.uni-marburg.de D-35032 Marburg
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
