I am having issues with Lets Encrypt not able to update SSL Certificates on my Webserver.

johnnyz

For some time now I am having issues with Lets Encrypt not being able to update SSL Certificates on my webserver. After many months of trying to troubleshoot this I am starting to this its the TZ400 causing the issue.

Linux Server gets this error when trying to update the certs:

Let's Encrypt validation status 400 (pacificdatacom.net). Details: Unable to update challenge :: authorization must be pending

when I run Lets encrypts "Let's Debug" test I can get 3 different responses. See pictures.

I have worked with my Webserver Software people (Hestia)

I have worked with my Service Provider (COX Business)

I have worked with Lets Encrypt

And none of them can find anything wrong so my Sonicwall is all that is left.

johnnyz

I got this from some on Lets Encrypts forums and I am thinking they are right, can you help me with this?

"The key is the Lets Debug response. If it cannot consistently see your server then you won't be able to get certificates from Lets Encrypt. Given you get inconsistent results I would look at settings in SonicWall that relate to "intelligent firewall" or "adaptive firewall" or "smart firewall" - something like that. It feels to me like it is adapting to a pattern in the Lets Encrypt requests and treating them as threats"

Ajishlal

Hi @johnnyz

For renewing the Lets Encrypts certificates required TCP port 80 access. So for renewing purpose open the port 80 to your webserver.

johnnyz

Port 80 is open to the websites. All has worked right for 20 years, this just started.

Ajishlal

Hi @johnnyz

Make sure the port 80 & 443 is enabled on the webserver and accessible in public. Since lets encrypt validation is handled automatically either one of those ports are required for the renewal.

Also I can see that the certificate on the subjected domain is renewed.

johnnyz

Your killing me. I have been an IT guy for 32 years, port 80 and 443 are open everywhere they need to be.

As far as the certificate, yes I can get it to renew but it takes days of running the renew script to get it to finally go through. Again I am positive this is a SonicWALL issue.

TKWITS

Are you running any of the security services on the Sonicwall? If so have you considered creating exceptions for the HTTP traffic required for Let'sEncrypt to properly renew?

johnnyz

No, I don't have an active SonicWALL subscription on this device.

Is there some logs I can run or look at to see whats going on?

Larry

Log on to the SonicWall.

In the "old" menu structure, start at System, then click Certificates and review your Let's Encrypt certificates.

I don't know if, in your research, you came upon this webpage: https://letsencrypt.org/certificates/

You should - at the very least - ensure your SonicWall is using the latest versions of these certificates. If your subscription is not active, it may not have received these recent updates.

If you don't have the current ones, at the bottom of the Certificates list is the Import button.

Hope that helps!

johnnyz

I am not using LE certificate on the SonicWALL they are on my Websites and email, all on the webserver.

Tippers

You could run a packet capture on the Sonicwall but you'll probably need to know the IP addresses used by LE to filter the HTTP/HTTPS traffic. You'd be able to see the content of the HTTP traffic and whether anything is dropped.

If there are no active services on the Sonicwall, it's unlikely to have changed recently due to signature updates so it's either a config change or something else.

johnnyz

There telling me some IPs here. so I will just have to figure out how to do the packet capture and see what I can get.

johnnyz

I cant tell. no matching IP on any of the dropped.

johnnyz

I don't know what is causing this? I have tried everything I can think of for about 8 months now. I built a new webserver (VM), and been on the Hestia forums for months...same problem. Been on Let's Encrypts forums... I had COX Business out here 3 times, and they all is good with my internet connection, that I have had for over 20 years. All the same equipment, nothing has changed.

Ajishlal

Hi @johnnyz

Update the TZ400 Firmware to latest and try to do the LE renewal or debug test.

If its possible share us with your Firewall rules for the webserver.

johnnyz

The firmware is up-to-date as of June, like I said, I have tried everything.

johnnyz

I am thinking this started with the firmware update before June? is it possible to put old firmware back on without any issues?

TKWITS

There's always the possibility of issue with a rollback, but it seems like you have a simple config so you should be ok.

https://www.sonicwall.com/support/knowledge-base/how-can-i-setup-and-utilize-the-packet-monitor-feature-for-troubleshooting/170513143911627/

I wouldn't filter the packet capture based on source IP, just destination IP and port.

johnnyz

I have a TZ 400 my menu is nothing like that.

johnnyz

but I can see the packets and when I run the Lets Debug test noting shows up on those logs. trying to get to my web servers IP

Larry

The new KB articles have a drop down at the top:

Select the Gen 6.5 option for a TZ400.

johnnyz

Thanks, I set up the packet monitor to monitor my webserver IP and the only thing I am seeing is email, not sure why so much email as I am not using the webserver for my email.

But I don't see anything trying to hit port 80 or 443 I am going to the website from a computer outside my network clicking on all pages and nothing showing up on packet monitor

johnnyz

I just rand the Lets Debug test and it passed this time as it does some times and got this in the log.

Ethernet Header

 Ether Type: 0x88cc(0x88cc), Src=[e0:63:da:70:f0:e9], Dst=[01:80:c2:00:00:0e]

Ethernet Type: Unknown

Value:[0]

Received 1:4294967

TKWITS

https://community.sonicwall.com/technology-and-support/discussion/comment/12124#Comment_12124

Than your packet capture filtering rules are incorrect.

Setup the packet capture, then run Lets Debug and make sure you see that traffic.

johnnyz

Ok, here is my packet filter setup.

I cleared the captured packets ran the lets debug test and nothing at all shows up.

johnnyz

I just went to the website and clicked on 4 different pages and then 10 seconds later this showed up on the packet monitor?

Ajishlal

As per your above screen shot, There are 52 packet drops.

For enable the display packet capture result, Navigate to the Configure and enable as same as below;

johnnyz

Thank you, now were getting somewhere. Ran Lets Debug and its dropping the packets to port 80.

Ethernet Header

 Ether Type: IP(0x800), Src=[84:8a:8d:f0:1c:19], Dst=[18:b1:69:34:67:65]

IP Packet Header

 IP Type: TCP(0x6), Src=[172.104.24.29], Dst=[70.167.119.118]

TCP Packet Header

 TCP Flags = [ACK,], Src=[57256], Dst=[80], Checksum=0xac8

Application Header

 HTTP

Value:[1]

DROPPED, Drop Code: 734(Packet dropped - drop bounce same link pkt), Module Id: 25(network), (Ref.Id: _2122_jcpfngDqwpegVtchhke) 1:1)

preston

Hi @johnnyz , stupid question, you don't have HTTPS and HTTP management enabled on the WAN Interface do you, or the HTTPS management and the redirect from HTTP to HTTPS enabled ? if so change the management port to be something else rather than the defaults 443 & 80, but it would be best to disable these if they are enabled from the WAN or at least tie down to specific IP addresses.

johnnyz

No, nothing enable on the WAN, only on the LAN and I don't use the default 443 port on the LAN.

TKWITS

For others' sake here is Let's Encrypt's very simple integration guide: https://letsencrypt.org/docs/integration-guide/

In my experience, the server requesting an LE cert needs to be able to lookup its own FQDN and be able to connect via HTTP to itself on said FQDN. Assuming DNS is ok, but do you have a hairpin NAT configured to allow the server to connect to itself via HTTP via its external IP?