SonicWall Cert Issue

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: "Install Certificate" Through YunoHost. Have also run cmds through Dietpi Certbot function

It produced this output: " `"500" Internal Server Error"
Challenge did not pass for {'identifier': {'type': 'dns', 'value': ''}, 'status': 'invalid', 'expires': '2023-08-25T18:58:46Z', 'challenges': [{'type': 'http-01', 'status': 'invalid', 'error': {'type': 'urn:ietf:params:acme:error:unauthorized', 'detail': ' Invalid response from 403', 'status': 403}, 'url': '', 'token': 'zxXpHTMVMHQcjvDicRpy67VP78fEGru9jywcC5tgUeQ', 'validationRecord': [{'url': '', 'hostname': '', 'port': '80', 'addressesResolved': [''], 'addressUsed': ''}], 'validated': '2023-08-18T18:58:46Z'}]}

My web server is (include version): Yunohost and/or Dietpi both utilizing NGINX

The operating system my web server runs on is (include version): YunoHost and/or Dietpi

My hosting provider, if applicable, is: GoDaddy

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

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

From what I can tell my request is getting blocked at the firewall level. We are Using SonicWalls TZ350. In speaking with Sonicwall they believe that LetsEncrypt is not registered as a CA in the firewall. We need to create a Cert request from our firewall and submit it to LetEncrypt to sing. Where I can I submit that cert?

They don't know what they're talking about. Maybe they're doing as PaloAlto does, and block all ACME validation attempts?

You need to allow connections to the .well-known/acme-challenge/ directory and retry what you were doing before.

And no, you won't get the IP addresses for the validation servers. :smiley:


Gotcha. I felt like they were just kind of guessing tbh.

Can you elaborate on this part " You need to allow connections to the .well-known/acme-challenge/ directory"?

The Let's Encrypt validation servers will try to connect to that address to check if you are actually in control of the domain name and yours is a legitimate request (as in "you are authorized to ask for a certificate for this domain name").

If the aforementioned servers get no answer, an answer they don't expect, or any kind of answer different than what they told certbot (or any acme client you might be using) to set up, your request for a certificate fails.


Ok. I get that. That describes our issue. We are trying to get the cert so that we can broadcast to the IP/DNS that you posted. But the cert request fails. It seems to be a firewall issue from what I can tell. It works fine in our test lab(uses certbot in the background). But not behind our firewall. We've opened up ports pointed at our DNS at the server itself, Using Yunohost to test which gives us a nice little diagnostic gui that tells us that DNS and ports are correct, it just keeps failing the acme challenge. Ive whitelisted every single URL in our firewall related to the Acme Challenge that I can find with no change.

1 Like

When I try opening that url, I get this:

$ curl -iL
HTTP/1.1 403 Forbidden
Server: Microsoft-IIS/8.5
Date: Fri, 18 Aug 2023 20:43:37 GMT
Content-Length: 0

This is not a firewall, this is IIS intercepting the request and issuing a 403 (I expected a 404)

Certbot and IIS usually don't work so well together, and there are some Windows-specific ACME clients if that's what what you're looking for.

But you told us you're running Nginx. So, where does this Windows machine come from?


Well thats strange. I dont know where that windows server is coming from(though we do have IIS servers). But the server were running is a linux server in this case. When I run the same curl command I get the same thing you do. But when I click on the above link I get a "404 Nginx" error.

I'm guessing there's a weird issue with one of our IIS servers thats redirecting the IP. Guess we will need to investigate there.

Before going down the rabbit hole, check if the dns records have the right IP address.

It happens more than you would expect. :smiley:

(When I click in firefox I get the same answer as I get from curl)


Soo we've tried a few differnt public IP's that we own and we get differnt issues. Using our primary public IP(WAN IP) got us the closest but is also used by some IIS services, thus the issue you were seeing I believe. When trying to point a differnt public IP at the local server we get different issues. Acme challenge still fails but the server keeps trying to pull the cert to the same IP despite any changes we make in DNS/GoDaddy. This is what our troubleshooter shows us when change to any of our other public IPs:


Now after making the change the curl command just fails to resolve(on port 80) which is open.

I don't know how your network works, but it looks like there is some issue with your IIS load balancers/reverse proxy/whatever. They're not reverse proxying very well :smiley:


Yes, that much certainly seems to be true. Thanks for your help. Guess we'll keep looking at that.


Who handles the device doing the NAT?


Co-worker does, we're a small shop though so not really experts in NAT. We're certainly having some weird routing issues. Tried again to setup a server with subdomain and it exposed a random other server to the internet somehow.


Someone needs to get that sorted out - before you expose something that shouldn't be exposed.


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