Seaf-cli skip ssl verification broken or what?

The instructions say to run this command in order to use selfsigned certs on your seafile server. I use selfsigned certs on my seafile server.

seaf-cli config -k disable_verify_certificate -v true

The command doesn’t produce any output. What’s happening is that I have seafile server installed on a home server (debian 9.2) and seaf-cli (only) installed on a Digital Ocean VM (also debian 9.2). I’d like to sync some folders from the VM to my home server … but when I run this command:

seaf-cli create -n folderName -t digitalOceans -s https://serverUrl -u myUserName -p myPasswd

I get this error:

urllib2.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)

As a matter of fact I get the same error when I use the seaf-cli download command or any other seaf-cli command. I’ve tried to run other seaf-cli config commands, they don’t produce any output either and I can’t seem to find a conf file that they are writing to (if they are writing to any file).

I need some help getting this working. I followed the installation instructions at:

I’ve seen similar problems mentioned on this forum, but no solutions except to not use selfsigned certs which is not an solution I can use.


[Solved] As it turns out I got some help from a similar topic on this forum and despite what I thought was impossible, one can use letsencrypt to work around this issue. You need a dyanmic domain name ( and a real domain name ( and a way to configure them. Add a cname record (subdomain) to the real domain that points to the dyamic domain ( -> The dynamic domain will point to your local ip. Install certbot on your local computer and use it to setup the ssl cert for your real subdomain (

That’s essentially it. You can then address the seafile server on your local computer using something like:

Just to have it said: In the end of doing what @henrythemouse described, skipping SSL verification is not required anymore as letsencrypt is part of the operating systems trust /certfiicate store.

Could you explain “part of the operating systems trust /certificate store”?
Do you mean all operating systems? And that letsencrypt is by default one of the installed trusted cerrificates? How would that work? I’m just not familiar with these terms and I’d like to know if there is someting here that I’m not understanding. I certainly don’t feel like I have a good understanding.


Most operating systems do have a trust store with certificates they trust. The private keys for the trusted certificates are owned by certificate authorities (which usually keep them within some hardware security module).

When you receive a certificate from letsencrypt, they first do a domain validation to check whether your authorized to get a certificate for the domain and then sign your certificate request. This builds a trust chain where one can say that because letsencrypt is trusted by your OS your certificate for your domain is trusted as well because letsencrypt validated that you actually own the domain.

here is some additional information: (there is way more on the internet of course)

Here’s another, quite straightforward solution (I’m too lazy to implement getting the verify through, but you’ll get the gist):

import ssl

def urlopen(url, data=None, headers=None, verify=False):
    if data:
        data = urllib.parse.urlencode(data).encode('utf-8')
    headers = headers or {}
    req = urllib.request.Request(url, data=data, headers=headers)

    if not verify:
        # Create an SSL context that does not verify certificates
        context = ssl.create_default_context()
        context.check_hostname = False
        context.verify_mode = ssl.CERT_NONE
        context = None

    resp = urllib.request.urlopen(req, context=context)


This goes into /bin/seaf-cli and replaces the function urlopen that’s already there.