I am having issues with Lets Encrypt not able to update SSL Certificates on my Webserver.
johnnyz
Newbie ✭
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.
Category: Mid Range Firewalls
0
Answers
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"
Hi @johnnyz
For renewing the Lets Encrypts certificates required TCP port 80 access. So for renewing purpose open the port 80 to your webserver.
Port 80 is open to the websites. All has worked right for 20 years, this just started.
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.
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.
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?
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?
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!
I am not using LE certificate on the SonicWALL they are on my Websites and email, all on the webserver.
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.
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.
I cant tell. no matching IP on any of the dropped.
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.
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.
The firmware is up-to-date as of June, like I said, I have tried everything.
I am thinking this started with the firmware update before June? is it possible to put old firmware back on without any issues?
There's always the possibility of issue with a rollback, but it seems like you have a simple config so you should be ok.
I wouldn't filter the packet capture based on source IP, just destination IP and port.
I have a TZ 400 my menu is nothing like that.
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
The new KB articles have a drop down at the top:
Select the Gen 6.5 option for a TZ400.
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
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
Than your packet capture filtering rules are incorrect.
Setup the packet capture, then run Lets Debug and make sure you see that traffic.
Ok, here is my packet filter setup.
I cleared the captured packets ran the lets debug test and nothing at all shows up.
I just went to the website and clicked on 4 different pages and then 10 seconds later this showed up on the packet monitor?
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;
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)
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.
No, nothing enable on the WAN, only on the LAN and I don't use the default 443 port on the LAN.
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?