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