Closed Taomyn closed 5 years ago
It's shoddy URL parsing. It wipes the port number if the protocol is https because I erroneously assumed https would be port 443.
I'll look into replacing it with a proper URL parser.
Cool, let me know if you want me to test a new version, although all my installs are https pn that port, so I can't test basic http or another port so easily.
This should do the trick: https://github.com/Pectojin/duplicati-client/commit/20c7c27d5693e898dacfaac3202ad279e3f8fca1
It works in all scenarios i tried:
# duc login localhost
Connecting to http://localhost:8200...
# duc login http://localhost
Connecting to http://localhost:8200...
# duc login http://localhost:8200
Connecting to http://localhost:8200...
# duc login https://localhost:8200
Connecting to https://localhost:8200...
# duc login https://localhost
Connecting to https://localhost:443...
The original error was in embedding "8200" as a port default. Made it impossible to reliably parse all the options correctly, which I originally corrected by assuming HTTPS -> 443.
Excellent, I'll watch for a new .exe release for Windows and give it a go
Let me know if it causes any trouble 😄 https://github.com/Pectojin/duplicati-client/releases/tag/0.4.21_beta
Thanks, now it connects but it complains that it cannot verify the certificate, so not sure where it's looking and I presume not the Windows computer certificate store. I could not find info on what "--certfile" needs as I don't like the idea of using --insecure
I've never tested with self signed certificates, but it relies entirely on the Python Requests module.
The input for certfile should just be a path, which the client then passes directly to Requests like here: https://2.python-requests.org//en/master/user/advanced/#ssl-cert-verification
>>> requests.get('https://github.com', verify='/path/to/certfile')
So this should work:
duc login https://localhost:8200 --certfile=/path/to/certfile.crt
Thing is it's not really self-signed, it's signed by my Windows domain CA and is thus internally trusted.
Is the .crt just the public certificate for it to compare against?
Yep, if you have a copy of the domain CA or intermediate public cert you should be able to just point it to that.
Usually you can even get a copy of it just opening a domain-signed website in your browser, inspecting the cert, and exporting the parent.
Thanks, I'll try that and see what happens - will probably store it in the same folder with the Duplicati server certificate.
I believe you can also just point it at the duplicati certificate directly, since that's how it would work with a self signed cert.
But that's a PFX with a password
I tried using the CA's certificate and the server's certificate exported without keys as ".crt" and it doesn't work:
C:\>"C:\Program Files\Duplicati 2\duplicati_client.exe" login https://homer.com:8200 --certfile="C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati\SELMA-CA.crt"
Provided certificate is invalid or does not match the server certificate
I'm not having any luck with it either... Doesn't help using server cert, intermediate, or root ca cert...
I've even been using the Requests library directly attempting to get it working, but something is going wrong.
I have Duplicati running on a mix of Windows and Linux (Raspbian, Fedora), and all their GUIs are connectable via https on port 8200. None of my instances can be logged into with duc:
I'm running Duplicati 2.0.4.22_canary_2019-06-30, I'm also using local CA signed certificates so they should be trusted on the machine I am running on - at least Firefox/IE seem to think so.