failed to connect just with a certificate

[nixx-geek]

Our server supports only authentication with a certificate. We don't have usernames and passwords. Is it possible to bypass the verification for a username and pass?
The error that I receive is:
VPN connection: failed to connect: 'Missing required option “user”.

[mrbaseman]

I don't find the error message in the source (at least not the current one). Are you using the network manager applet?
But anyhow, it's true that openfortivpn currently requires that username and password are specified. However, maybe it works fine if just empty values for username and password are passed to the server. You could give it a try to comment out lines 403-416 in main.c.

[nixx-geek]

Yes I'm using the network manager applet. Thanks for the tip, I'll give it a try.

[nixx-geek]

I managed to skip over asking for a username and password, but now I have the same error as in issue #366.

[DimitriPapadopoulos]

The error in #366 is probably unrelated (it's not a Fortinet gateway).

[DimitriPapadopoulos]

It would be best to provide your own verbose log (use openfortivpn -v).

[nixx-geek]

DEBUG:  openfortivpn 1.7.1
DEBUG:  Loaded config file "config".
DEBUG:  Config host = "xxx.xxx.xxx.xxx"
DEBUG:  Config realm = ""
DEBUG:  Config port = "443"
DEBUG:  Config username = ""
DEBUG:  Config password = "********"
DEBUG:  server_addr: xxx.xxx.xxx.xxx
DEBUG:  server_port: 443
DEBUG:  gateway_addr: xxx.xxx.xxx.xxx
DEBUG:  gateway_port: 443
Enter PEM pass phrase:
DEBUG:  Gateway certificate validation succeeded.
INFO:   Connected to gateway.
ERROR:  Could not authenticate to gateway (Bad HTTP response code).
INFO:   Closed connection to gateway.
DEBUG:  server_addr: xxx.xxx.xxx.xxx
DEBUG:  server_port: 443
DEBUG:  gateway_addr: xxx.xxx.xxx.xxx
DEBUG:  gateway_port: 443
Enter PEM pass phrase:
DEBUG:  Gateway certificate validation succeeded.
INFO:   Logged out.

[mrbaseman]

Ok, it could not authenticate you with an empty password. I can't test it easily, because local users always have a password, so your account is probably an external one (LDAP or Radius, ...).

Maybe we are lucky and it is sufficient just to drop the parameter for the password from the request that is sent out. Try out this branch.

It will interactively ask you for a password - just hit enter and in the case of an empty password it is just not sent (that's the most simple implementation I can imagine, and probably good enough for a first test).

[nixx-geek]

I cloned the branch, commented out lines 403-416 in main.c. (this was recommended by mrbaseman) After that I run autogen.sh, ./configure and make.
I'm still receiving the same error Could not authenticate to gateway (Bad HTTP response code).
Any other ideas?
Thank you!

[mrbaseman]

Does authentication with certificate only work with the proprietary Forticlient? Do you have a chance to capture the packets? Probably this is difficult, because you would have to break up https, which in turn lets the authentication fail ;-)

[mrbaseman]

I'm sorry, it seems I forgot to push my commits upstream. @Claudiuion could you retry, please? Probably you have to git pull --force then.

[nixx-geek]

I have this error when I try to compile.
make
CC src/openfortivpn-config.o
CC src/openfortivpn-hdlc.o
CC src/openfortivpn-http.o
src/http.c: In function ‘auth_log_in’:
src/http.c:537:6: error: ‘cfg’ undeclared (first use in this function)
if (cfg.password[0] == '\0') {
^~~
src/http.c:537:6: note: each undeclared identifier is reported only once for each function it appears in
make: *** [Makefile:541: src/openfortivpn-http.o] Error 1

[mrbaseman]

I think, somehow I was in the middle of merging in the latest commits from master. I have just pushed another correction which makes this compile error go away.

[mrbaseman]

@Claudiuion were you able to test this again after I have fixed the compile error?

[nixx-geek]

yes, but I have the same problem:

DEBUG:  openfortivpn 1.7.1
DEBUG:  Loaded config file "config".
DEBUG:  Config host = "xxx.xxx.xxx.xxx"
DEBUG:  Config realm = ""
DEBUG:  Config port = "443"
DEBUG:  Config username = ""
DEBUG:  Config password = "********"
WARN:   This process was not spawned with root privileges, this will probably not work.
DEBUG:  server_addr: xxx.xxx.xxx.xxx
DEBUG:  server_port: 443
DEBUG:  gateway_addr: xxx.xxx.xxx.xxx
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation succeeded.
INFO:   Connected to gateway.
ERROR:  Could not authenticate to gateway (Bad HTTP response code).
INFO:   Closed connection to gateway.
DEBUG:  server_addr: xxx.xxx.xxx.xxx
DEBUG:  server_port: 443
DEBUG:  gateway_addr: xxx.xxx.xxx.xxx
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation succeeded.
INFO:   Logged out.

[mrbaseman]

well, it would have been too easy... Probably one would have to know more about how this login process is handled. Probably the account is in an LDAP or Radius server, and the certificate or its subject is also part of the user profile, and it is somehow taken by the VPN and forwarded to the server that handles the authentication. But that's quite speculative, too. I fear that I can't help much more.

[nicolaerosia]

If you have any other ideas, I'm willing to test since I have the same issue

[mrbaseman]

Hmm... the connection mechanism would be interesting to inspect, e.g. using wireshark. But by design of the SSL encrypted connection you can only do this if you control both, the server and the client (or the CA that issued the certificates that are involved).
Or, if you dont't, you could ask the administrator of the Fortigate if he can point us to the documentation how to configure a Fortigate such that it accepts login with a client certificate and without password.
Maybe an interesting side note: the client certificate is completely handled by the libraray calls to OpenSSL. There is almost no code in openfortivpn (except for passing the p12 file path to OpenSSL), and this works if also user and password are required. therefore, my hope was, if the client certificate handling in openfortivpn is that much lightweight as it is, we could focus on what's happening inside the ssl channel during authentication. The first guesses were "leave the password simply empty" and " just don't send a password value in this case", but both attempts didn't work.
Maybe we have to pass different parameters or call a different URL for logging in (or skip that whole part of the login process for this configuration)... A bit of knowledge how it works with Forticlient would be helpful to decide which way to go.

[mrbaseman]

With the recently released version 1.8.0 we have improved the debugging output. I have rebase my cert-only branch, and then openfortivpn might give more hints about the login process when started with -v -v. I don't expect it to work, but the whole http traffic of the authentication process is shown.
Please be careful when posting it here, because clear text passwords are probably contained. Make sure you anonymize this data appropriately.

[martinetd]

FWIW I have another fortigate vpn that is certificate only auth, it works if I just provide whatever random password (I have "notused"); it looks like the server just ignores this part of the handshake

[martinetd]

Ah: the username I use isn't random, it's the Subject CN of the client certificate.
e.g. with

$ openssl x509 -noout -text -in /path/to/cilentcert | grep Subject
Subject: C = xx, ST = Stuff, L = More, O = Stuff, OU = And, CN = This, emailAddress = [email protected]

I would use This

[mrbaseman]

@Claudiuion could you double-check that the username matches the CN of the certificate?

[nixx-geek]

DEBUG:  openfortivpn 1.8.0
DEBUG:  Loaded config file "config".
VPN account password: 
DEBUG:  Config host = "xxx.xxx.xxx.xxx"
DEBUG:  Config realm = ""
DEBUG:  Config port = "443"
DEBUG:  Config username = "Claudiu Ion"
DEBUG:  Config password = "********"
DEBUG:  Resolving gateway host ip
DEBUG:  Establishing ssl connection
DEBUG:  server_addr: xxx.xxx.xxx.xxx
DEBUG:  server_port: 443
DEBUG:  gateway_addr: xxx.xxx.xxx.xxx
DEBUG:  gateway_port: 443
Enter PEM pass phrase:
DEBUG:  Gateway certificate validation succeeded.
INFO:   Connected to gateway.
ERROR:  Could not authenticate to gateway. Please check the password, client certificate, etc.
DEBUG:  HTTP status code 405
INFO:   Closed connection to gateway.
DEBUG:  server_addr: xxx.xxx.xxx.xxx
DEBUG:  server_port: 443
DEBUG:  gateway_addr: xxx.xxx.xxx.xxx
DEBUG:  gateway_port: 443
Enter PEM pass phrase:
DEBUG:  Gateway certificate validation succeeded.
INFO:   Logged out.

Test made on openfortivpn 1.8.0, cert-only branch
Username matches the CN of certificate
I don't have any VPN account password, so I just hit Enter when being asked for it.
I enter the password that protects my privatekey when being prompted on the console (Enter PEM passphrase:)

[martinetd]

Thanks for trying... My CN doesn't have a space, I wonder if they have some way of escaping it (we don't do urlencoding right, might be worth trying %20?)

That aside I don't have much idea, I don't have access to the fortigate config either :/

[DimitriPapadopoulos]

@martinetd Indeed url_encode() converts space into +, not %20. Both can be correct, depending on the context as far as I can see:

• URL encoding the space character: + or %20?
• HTML URL Encoding Reference

Is + not right in this context?

[martinetd]

Ah we do urlencode the username as well, then it'll be a pain to test at user level.
I have no idea, both might work; this kind of stuff is difficult to test without access to any server :/

[mrbaseman]

it would perhaps help to know how this is implemented on the server-side at all. Is it an LDAP, Radius, AD, ...?
And how are the certificates linked to the user names?
A tutorial how to set up such an environment would help to build a testing platform where we can debug the problem on the server side.
Log entries about the failing login from the server side might also help (although the authentication logs on FortiOS from my experience are sometimes misleading... - logs from the LDAP or whatever it is are probably more helpful)

[nixx-geek]

hello. i made a new test using the last commits on cert-only branch.

The log:
openfortivpn.log

As a username I used the CN from the certificate. The username also contains a space between first and lastname (CN = firstname lastname).
The error received is http 405 Method Not Allowed.

[mrbaseman]

Oh, then it could be #351 for which we have included the fix #458 recently on the master branch.
I have rebased my cert-only branch on the current master. Could you retry, please?

[nixx-geek]

:( the same error. The proprietary client works without issues. Please check this log maybe it gives you an idea...
forticlientsslvpn.log

[martinetd]

the foritclientsslvpn's log say "realm enabled" but don't list anything after it, there might be something to set for openfortivpn? (we have a --realm option too)

That aside if your username is now properly listed with a %20 in the new openfortivpn's log with the new branch I really am out of idea... I no longer have access to my cert-only vpn btw so can't help anymore with that.
At this point asking nicely to your admins for their side of the logs might be the way forward....

[mrbaseman]

My cert-only branch that I have mentioned above went into the 1.11.0 Release.

We haven't heard back anything here, maybe the --realm option that martinetd has mentioned was the important hint?

[mrbaseman]

Dimitri has found a problem with a commit originally from my cert-only branch in #496
I have merged the fix for it on the current master branch.
When using a user-cert in the config file you can try removing the line for password from the config file and keep username and set that to the CN of the certificate or remove both lines (password and username) from the config. It uses two different requests (unfortunately, we have to find it out experimentally as long as we don't have a tutorial how to set up such an environment on the remote side)

[mrbaseman]

@Claudiuion would you mind testing once more with the current master branch?

[nicolaerosia]

@mrbaseman I'm getting a segfault

bin$ sudo gdb --args ./openfortivpn -v vpnhost:443 --user-cert=mycert.pem --user-key=mykey.key
GNU gdb (GDB) Fedora 8.3-6.fc30
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./openfortivpn...
(gdb) r
Starting program: openfortivpn -v vpnhost:443 --user-cert=mycert.pem --user-key=mykey.key
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.29-27.fc30.x86_64
warning: Loadable section ".note.gnu.property" outside of ELF segments
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: Loadable section ".note.gnu.property" outside of ELF segments
DEBUG:  openfortivpn 1.11.0
DEBUG:  Loaded config file "/etc/openfortivpn/config".
DEBUG:  Config host = "vpnhost"
DEBUG:  Config realm = ""
DEBUG:  Config port = "xyz"
DEBUG:  Resolving gateway host ip
DEBUG:  Establishing ssl connection
DEBUG:  server_addr: xxx
DEBUG:  server_port: xyz
DEBUG:  gateway_addr: xxx
DEBUG:  gateway_port: xyz
DEBUG:  Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4
DEBUG:  Gateway certificate validation succeeded.
INFO:   Connected to gateway.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000406f48 in auth_log_in (tunnel=tunnel@entry=0x7fffffffc710) at src/http.c:576
576		if (tunnel->config->use_engine
Missing separate debuginfos, use: dnf debuginfo-install libgcc-9.2.1-1.fc30.x86_64 libgcrypt-1.8.5-1.fc30.x86_64 libgpg-error-1.33-2.fc30.x86_64 lz4-libs-1.9.1-1.fc30.x86_64 nss-mdns-0.14.1-3.fc30.x86_64 openssl-libs-1.1.1d-2.fc30.x86_64 systemd-libs-241-12.git323cdf4.fc30.x86_64 xz-libs-5.2.4-5.fc30.x86_64 zlib-1.2.11-19.fc30.x86_64
(gdb) bt
#0  0x0000000000406f48 in auth_log_in (tunnel=tunnel@entry=0x7fffffffc710) at src/http.c:576
#1  0x000000000040da10 in run_tunnel (config=config@entry=0x7fffffffda20) at src/tunnel.c:1005
#2  0x000000000040457c in main (argc=5, argv=<optimized out>) at src/main.c:544

Later edit:
After editing the config to

username = 
password = 

I can now connect

[DimitriPapadopoulos]

I have initiated a Coverity scan by pushing the latest master branch into the coverity_scan branch.

"Your build is in the queue to be analyzed. There are 292 builds ahead of it" unfortunately.

[nicolaerosia]

it fails to add the nameservers to /etc/resolv.conf, I'm not sure which way is recommended now since resolv.conf is managed by NetworkManager.

INFO:   Got addresses: [xyz], ns [xxx1, xxx2]
INFO:   negotiation complete

INFO:   Adding VPN nameservers...
DEBUG:  resolvconf_call: /usr/sbin/resolvconf -a "ppp0.openfortivpn"
Failed to set DNS configuration: Could not activate remote peer.

[DimitriPapadopoulos]

@nicolaerosia How is this related to connection with a certificate? If unrelated please create a new issue.

[nicolaerosia]

@DimitriPapadopoulos I don't know - it is the first time I'm using openfortivpn, I just wanted to report that auth with cert works fine but with this small issue.

[DimitriPapadopoulos]

@nicolaerosia Please create a new issue.

[mrbaseman]

the segfault should be fixed on master with #513 now

[mrbaseman]

I have opened the separate issue for the DNS resolution topic, please see my answer there

[DimitriPapadopoulos]

@nicolaerosia Have you seen the new issue we have created regarding the error you experienced (#514)?

[DimitriPapadopoulos]

@Claudiuion This should be fixed in current versions. If not please do not hesitate to reopen. I'm also closing this issue because it has grown too complicated and references multiple issues.