SSL Error?

[Jeppedy]

Why am I getting SSL errors when I try to make the first connection? When cert param isn't supplied at all: OpenSSL.SSL.Error: [('system library', 'fopen', 'Broken pipe'), ('BIO routines', 'BIO_new_file', 'system lib'), ('x509 certificate routines', 'X509_load_cert_crl_file', 'system lib')]

When cert=None is set: requests.exceptions.SSLError: HTTPSConnectionPool(host='192.168.2.126', port=8443): Max retries exceeded with url: /api/s/default/stat/sta (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')])")))

[nickovs]

Without the cert argument explicitly set this should work with a self-signed certificate. Are you using the default (auto-generated) certificate or something that you loaded yourself? Setting cert=None will result in an error unless the certificate on the device is issued by a CA that is trusted by your client's operating system.

Can you tell me on what platform and OS are you running this? It would also be helpful to know what version of OpenSSL you have installed and to have the output of pip freeze. A stack backtrace would also be helpful; please could you do an import traceback before your test and then after you get the error send the output of traceback.print_last()? That will give some more context.

[Peerkersezuuker]

Hi Nickovs, I have a simular problem. this is the test code i used : `from unificontrol import UnifiClient import ssl

cert = ssl.get_server_certificate(("192.168.0.32", 8443)) client = UnifiClient(host="192.168.0.32", port="8443", username="admin", password=, site="default", cert=cert)

target_mac = '40:98:AD:0B:54:91'

client.list_clients(client_mac=target_mac)

client.get_client_details(target_mac)`

I get following error : Exception has occurred: SSLError HTTPSConnectionPool(host='192.168.0.32', port=8443): Max retries exceeded with url: /api/s/default/stat/user/40:98:AD:0B:54:91 (Caused by SSLError(PermissionError(13, 'Permission denied'))) File "D:\SVN_Checkout\Test\test_unifi_api.py", line 13, in <module> client.get_client_details(target_mac)

I am running the controller on a Pi, latest version with the default certificate installed by Unifi event with the ,cert=cert removerd from the client= line it wil not work

Regards Peer

[nickovs]

Yes, this likely is the same or a related problem. Did you install from PyPI or from Github? There has been a patch that probably fixes this on the master branch on Github for a while but since I don't have a Windows machine I've not been able to test it, so I had not pushed that update to PyPI. Since so many people have been seeing this issue in Windows, and since the patch doesn't seem to cause any trouble on other platforms, I have just pushed the new version out anyway.

Please upgrade with pip3 install --upgrade unificontrol and see if it helps. If it doesn't them please send me a stack backtrace and list of your installed packages and version (as described above) and I'll see if I can identify the problem.

[Peerkersezuuker]

Hi Nickovs, This was the solution, the error has gone, and i can query my devices.

Thanks,

[nickovs]

Excellent. Thank you for your testing and feedback.

[a1ad]

@nickovs Same problem with latest version:

Max retries exceeded with url: /api/s/default/stat/health (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)'),))

Code used is check_unifi nagios command: client = UnifiClient(host=args.hostname, username=args.user, password=args.password, site=args.sitename,cert="FETCH_CERT")

also tried: cert = ssl.get_server_certificate((args.hostname, 8443)) client = UnifiClient(host=args.hostname, username=args.user, password=args.password, site=args.sitename,cert=cert)

First i thought it was because the ubnt cert was expired, but i created a new self signed cert (real PITA) and still got the error.

[nickovs]

@a1ad Are you running the Unifi service on a CloudKey, on a Dream Machine or UDP Pro, or on your own server? Also, what is the version number of the server that you are running, and what platform are you running the client code on?

[a1ad]

@nickovs

• Cloudkey V2 with server version 5.13.32 (Build: atag_5.13.32_13646).
• Client code: CentOS7 with python 3.6

[nickovs]

@a1ad Thanks for the details. I am having trouble reproducing the problem here but it's hard to separate out if its a problem with your CentOS setup or the CloudKey. If you have Docker handy then perhaps you might try an experiment.

I was testing from CentOS7 using the following Dockerfile:

FROM centos:7
ENV LANG=en_US
RUN yum update -y && yum install -y python3
RUN pip3 install unificontrol click
COPY unifitest.py /

You will need the following file saved as the unifitest.py program:

#!/usr/bin/env python3                                                                                                                                                          

import json
import click
import unificontrol

@click.command()
@click.option('--host', '-h', default='localhost', help="Hostname of Unifi controller")
@click.option('--port', '-p', default=8443, help="Port number for Unifi controller")
@click.option('--site', '-s', default='default', help="Site ID")
@click.option('--username', '-u', default='admin', help="User name")
@click.option('--password', '-P', prompt=True, hide_input=True, help="Controller password")
def unifi_test(host, port, username, password, site):
    c = unificontrol.UnifiClient(host=host, port=port, username=username, password=password, site=site)
    sysinfo = c.stat_sysinfo()
    print(json.dumps(sysinfo, indent=4))

if __name__ == "__main__":
    unifi_test()

You should then be able to test access to your CloudKey with:

$ docker build -t centos-unifi . && docker run --rm -it centos-unifi
[root@0350fc0bbae0 /]# ./unifitest.py --host 192.168.1.251
Password: 
...

and hopefully get an output that looks something like:

[
    {
        "timezone": "America/Denver",
        "autobackup": false,
        "build": "atag_6.0.41_14327",
        "version": "6.0.41",
        "previous_version": "6.0.36",
...

If that works then the problem is likely to do with something at your CentOS configuration. If it doesn't work then the problem is likely due to the way your CloudKey is configured. Either way it will help narrow down what's wrong.

[a1ad]

Thanks for the lengthy response. Ill try it next week on Tuesday.

The setup did work for a couple months but ofcourse ill keep the OS up to date.