--cafile enabling system-trust nevertheless?
Cline, Wade
wade.cline at intel.com
Thu Sep 5 11:03:18 PDT 2024
On Thu, Sep 05, 2024 at 10:13:16AM +0200, Martin Pauly wrote:
> Hi Wade,
>
> Am 03.09.24 um 19:22 schrieb Cline, Wade:
> > 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).
>
> Looks like you are completely right. The behavior of NM comes a bit unexpected,
> but there is nothing insecure with it. Thanks everyone for clarifying things.
> One _might_ think about renaming --cafile to something like --add-ca-file
> to avoid a misunderstanding like ours in the first place, but you still
> you have to read the docs if you want to pin the server cert or similar.
> So not sure this would help at all.
Hi Martin,
Glad things are clarified!
It's worth noting that "CAfile" and its variants are a de facto standard
name (from the OpenSSL library implementation?) used across many programs;
for example, the OpenSSL 's_client' command and InspIRCd OpenSSL module,
as well as numerous other programs, all use the same parameter name.
Regards,
Wade
> Luckily, there are no current attacks I know of trying to mimic our VPN gateway,
> so no immediate danger from that direction.
>
> Regards,
> 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
More information about the openconnect-devel
mailing list