Some clients report SSL errors

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version): nginx/1.14.2

The operating system my web server runs on is (include version): debian 10

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.20.0


I'm making a Python plugin for Autodesk Maya and I've started receiving reports of my clients getting SSL errors whenever it tries to contact the API server at the domain provided above. However just going to that domain in the browser always works and shows correct API response without any certificate warnings from a browser.

Unfortunately it does not seem like this issue is universal. I am unable to recreate this issue, I've tried doing so on Windows, Mac and Linux from physical and virtual machines, from 2 different locations and networks. And from API logs I can confirm that most people don't seem to get this error. But reports are coming from different people from different countries, so the issue is there. So far I've had to instruct them to set the plugin to ignore SSL errors, which is not ideal at all.

At first I used certbot --nginx to issue the certificate, after this issue and reading about Let's encrypt root exipty I tried certbot --nginx --preferred-chain "ISRG Root X1" --force-renew but I am still getting reports of these issues.

Requests are being made by urllib libraries in Python 2 and 3 (depending on Autodesk Maya version).

I am using Cloudflare DNS, and I tried it both with Proxy on and Proxy off - it seems it does not affect the issue (which is a bit odd, since Cloudflare is supposed to have their own certificates for their proxies).

At the moment I am at a loss, being unable to recreate the issue I'm not sure how to approach it further. Any advice would be welcome.

Thank you.

1 Like

Hi @Nixellion and welcome to the LE community forum :slight_smile:

I see that the the site is now serving the shorter/alternate chain.
I presume that you've switched to it because the longer/default chain also gave you trouble.
If so, then both may be unable to meet your needs.
But fear not, there are choices left...
Like: Using a chain from another (free and ACME friendly) CA.

An aside: How much control do you have over the clients accessing this site?


Hello @rg305 , thank you :slightly_smiling_face:

Yes, I've switched to the shorter chain as part of my trial-and-error approach. But it's basically - so a change, then wait if any new reports come in after that, which is very inefficient to say the least. I might switch back to the longer chain if that should in theory be better.

How could I switch to another CA? Would I still be able to use certbot for this? Any pointers to documentation or advice?

What I love about certbot and let's encrypt is how easy it is to issue and renew certificates. I also use it on my other domains and services, both public and more personal (like self hosted nextcloud and such) and it would be good if I could keep everything unified. But if switching to another CA is the only solution for this problem then so be it.

I only have control over the Python code that they run. I can push updates but that's about it. But they would still be unable to even get notified about updates without contacting the server, which they can't if they get SSL errors. Ideally I would like to solve the issue without requiring any actions from my end-users.

EDIT: Also I wonder why does this even happen? Why some clients report errors and some don't? With everything else being the same.

For example, one of the latest reports came from someone from my own country, same city even, using same Windows version, same Maya version and inherently same Python interpreter version. Only he gets SSL error and I don't. Why could that be?

That depends on the ACME client in use.

That depends on the version in use.

Use the latest version (whenever possible).

[ignore the SEO answers]
I see that you have certbot version 1.20.0.
Honestly, I've never done it... but the docs say that it can:
User Guide — Certbot 1.21.0.dev0 documentation (
All you need is the other ACME server URL.

which for ZeroSSL might be:

1 Like

Thank you, I'll check it.

I've also had some other edits in my post, but because of those edits it got flagged for spam. Oops. Says staff member has to review it before it gets back.

Anyway, the question was - why would this even happen? One of the latest reports comes from a person from same city as me, and I tested it on same Windows, Maya and Python versions as he has. And he gets the error and I don't. How and why would that be? Is there any way for me to recreate the issue?

Because otherwise even if I switch to another CA I have no way of telling if it helped.

That is usually far from certain.
No two people use Windows in the exact same way.
A few will do Windows Updates every week - most never do it at all.

You will know it helped when no one is complaining - LOL


That is usually far from certain.
No two people use Windows in the exact same way.
A few will do Windows Updates every week - most never do it at all.

Well, yes, as much as I can tell anyway: sys.getwindowsversion(major=10, minor=0, build=19042, platform=2, service_pack='')

You will know it helped when no one is complaining - LOL


Looks like zerossl has their own... bot on top of certbot GitHub - zerossl/zerossl-bot: The repository for the ZeroSSL certbot wrapper

And yet it still creates config file /etc/letsencrypt/renewal/ that says:

authenticator = nginx
installer = nginx
server =


@Nixellion The zerossl bot script is just a small wrapper for Certbot. And, it has some bugs. There are pending fixes but for some reason are not being applied to the main branch. I am not an expert on this by any means - I just explored their github and saw the various issues.

It looks like using this forked copy would fix the problem you saw.

Or, manually apply the same updates by changing last line in script to:
certbot ${CERTBOT_ARGS[@]}.

Or, just use Certbot directly and set the parameters for Zero SSL. I am not sure which are required apart from --server. As noted, I am not a Zero SSL expert :slight_smile:


Thank you, yes, I've seen those issues to and been able to get a certificate and documented my steps:

1. Get credentials for email:

curl -s --data "email=your_email"

It will return json with eab credentials required in next step

2. Create cli.ini file anywhere with this contents:

# Certbot config
server =
eab-kid = insert_key_here
eab-hmac-key = insert_key_here

3. Run command (adjust path to file if needed)

certbot -c cli.ini

After that domain now returns ZeroSSL certificates and .conf file has correct server= directive leading to zerossl server.

Guess we'll now have to wait and see if anyone else reports any SSL errors. I might have to ask people who already reported them before to adjust configs back to not ignore SSL errors.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.