Hi,
We are having problems with PF 10.3 (Debian 9) not being able to de-associate
clients from UniFi controlled APs, with the following being logged in
packetfence.log:
Aug 9 08:42:51 packetfence pfqueue: pfqueue(14988) INFO:
[mac:c8:3d:d4:ac:e3:11] [c8:3d:d4:ac:e3:11] DesAssociating mac on switch
(10.0.238.187) (pf::api::desAssociate)
Aug 9 08:42:51 packetfence pfqueue: pfqueue(14988) ERROR:
[mac:c8:3d:d4:ac:e3:11] Can't login on the Unifi controller: 500 Can't connect
to 10.0.0.3:8443 (certificate verify failed)
(pf::Switch::Ubiquiti::Unifi::_connect)
Aug 9 08:42:51 packetfence pfqueue: pfqueue(14988) ERROR:
[mac:c8:3d:d4:ac:e3:11] Error handling desAssociate : Can't connect to
10.0.0.3:8443 (certificate verify failed)
SSL connect attempt failed error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed at
/usr/share/perl5/LWP/Protocol/http.pm line 47.
...propagated at /usr/local/pf/lib/pf/Switch/Ubiquiti/Unifi.pm line 204.
(pf::api::can_fork::notify)
We have 3 separate pairs of Packet Fence instances integrated with their own
Ubiquiti UniFi controllers to do HTTPS de-association, the switches.conf file
is configured to use HTTPS as I understand the new CoA method to only work for
a single SSID:
[group Ubiquiti]
controllerIp=192.168.1.49
description=Default Ubiquiti UniFi Settings
type=Ubiquiti::Unifi
uplink_dynamic=0
deauthMethod=HTTPS
useCoA=N
wsPwd=****************
wsTransport=https
wsUser=packetfence
radiusSecret=****************
This all works perfectly for the one integration where the UniFi controller has
a real SSL certificate, even though the connection is to the IP of the
controller and not the hostname matching the real certificate. This presumably
works due to /usr/local/pf/lib/pf/Switch/Ubiquiti/Unifi.pm setting
'verify_hostname' to zero:
my $controllerIp = $self->{_controllerIp};
my $transport = lc($self->{_wsTransport});
my $username = $self->{_wsUser};
my $password = $self->{_wsPwd};
my $ua = LWP::UserAgent->new();
$ua->cookie_jar({ file => "$var_dir/run/.ubiquiti.cookies.txt" });
$ua->ssl_opts(verify_hostname => 0);
$ua->timeout(10);
The problem we have is the other two integrations where UniFi is running with
self-signed certificates. Debian 9 provides libwww-perl v6.15 and
ca-certificates provides the Mozilla CA certificates. I presume the problem
here to be that we need to disable both CA validation as well as disable
hostname validation (already done by default). If I subsequently add
',SSL_verify_mode => 0x00' to the ssl_opts it skips CA chain validation.
To reproduce I created the following simple perl script:
#!/usr/bin/perl
use warnings;
use LWP::UserAgent;
my $ua = LWP::UserAgent->new();
$ua->cookie_jar({ file => "/tmp/temp-cookies.txt" });
$ua->ssl_opts(verify_hostname => 0 ,SSL_verify_mode => 0x00);
$ua->timeout(10);
my $base_url = "https://172.31.250.3:8443";;
my $response = $ua->post("$base_url/api/login", Content =>
'{"username":"packetfence", "password":"****************"}');
unless($response->is_success) {
print "Can't login on the Unifi controller: ".$response->status_line."\n";
die;
}
print ($ua, $base_url."\n");
I seriously doubt many people get real CA certificates for an internal UniFi
controller, could I submit a patch to alter the behaviour?
Regards
David Herselman
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
