--cafile enabling system-trust nevertheless?

[Cline, Wade]

On Mon, Sep 02, 2024 at 01:56:44PM +0200, Martin Pauly wrote:
> 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?

As I recall, openconnect via NM uses a two-step process in order to
establish the VPN connection and what you're seeing is the second step
of that process.  The first step runs as a regular user and does the
authentication while the second step runs as root and actually establishes
the VPN connection.  Part of the first step is verifying the server's
certificate; the verified certificate is then passed on to the second
step explicitly via --servercert.  Though this can result in a rather
unfortunate log entry (3rd line):

	NetworkManager[3427]: Connected to REDACTED
	NetworkManager[3427]: SSL negotiation with REDACTED
	NetworkManager[3427]: Server certificate verify failed: signer not found
	NetworkManager[3427]: Connected to HTTPS on REDACTED with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)

When I tested it, server cert vertification was working correctly when
I specified an invalid fingerprint (see the --authenticate option for
details).

Regards,
Wade

> (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