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