Error for certain users with corporate firewalls

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:

My web server is (include version): NGINX v1.16.1

The operating system my web server runs on is (include version): Ubuntu 16.04

My hosting provider, if applicable, is: DigitalOcean

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): 0.27.0

I'm having an issue where various users of my site are unable to access my site's REST API, Both domains are secured using certbot but the configurations are completely separate. Only is inaccessible.

In particular, it's only users who have some kind of corporate WiFi enabled who are experiencing the problem - for some reason these users are getting an error like "net::ERR_CERT_INVALID" in Chrome.

I've tried a LOT of adjustments to my Certbot and NGINX setup and now get an "A" rating from the Qualys SSL checker, but still having users who are consistently getting this error when they use their company wifi. In fact, if they try accessing via their company wifi it will throw this error, but if they they then use their mobile service it will then work.

Thanks for any help or suggestions!

1 Like

Hi @YPCrumble

your configuration is buggy, see your check - ~~40 minutes old.

That subdomain has ipv4 and ipv6.

Ipv4 has the correct certificate, ipv6 has the wrong certificate.

So if these users use ipv6, the wrong result is expected.

Your main domain has only ipv4.


Thank you!!! Just updated these with 1m TTL. Hoping this is the correct solution :D:D:D:D.

Thank you so much for your help. I'll look again in an hour and let you know if the issue persists.


I don't see an update. Your ipv6 sends again the wrong certificate. "check-your-website" must show the correct certificate.

Check your nginx configuration.

nginx -T

PS: Ah, I see, you have changed the ipv6. With the new ipv6 2604:a880:800:10::3a61:a001, it works.

1 Like

Thanks for your help!

I've gone ahead and updated further and my rating has improved for - but users are still being blocked by services like Plume ( that are part of their router service. Interestingly, these users are not blocked when they try to visit On plume this is showing users a 511 error.

I believe this was because I was 302 redirecting my home page to a different page which must have messed up these intermediary SSL checkers. Now, however, I've removed the 302 redirect at and still many users are able to see my staging api at but are getting this SSL error at normally uses encryption to protect your information. When Google Chrome tried to connect to this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.

You cannot visit right now because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.

Thanks again for all the help in diagnosing this!!!


See Certificated created but chrome returns “Privacy Error” - #6 by joseluislandivars - same problem.

I couldn't see any problem, but users from a WiFi had the same error message.


The IT department has whitelisted the site and I can access to it.

There was something that has blocked.


It looks like the idea that these wifi routers have blocked my site due to the redirect I had on is correct. Is this something that should be flushed out with time now that I've updated, or should I try renaming my API to something like

Thanks again for all your help with this!

[EDIT] Or, is the block more likely at the IP address level, and changing that would allow users' browsers to access my API again?

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