https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257176#M50387 <P>The best approach is to use a single certificate, with alt names for all your web applications, centralize the renewal in one server that listens to port 80 with the validation path&nbsp;/.well-known/acme-challenge correctly configured and use a renew hook script to copy the new cert to all your apps.<BR /><BR />This approach would also let you use the certificate with inbound HTTPS Inspection, which you can automate using the Management API. To do that, create an inspection rule, get the rule UID, add the new certificate via API and replace the cert used in the rule. You cannot overwrite a certificate, just upload the new one and modify the rule.</P> Fri, 12 Sep 2025 14:23:35 GMT Pedro_Espindola 2025-09-12T14:23:35Z https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/256991#M50365 <P>Hello,</P><P>We have successfully been running Let's Encrypt certificate renewals.<BR />There is a security rule for Let's Encrypt IPs on port 80 to our web server's external IP addresses and corresponding NAT rules for forwarding to the internal web servers. This works very well.</P><P>Now, however, several internal web servers are hiding behind one external IP, all of which want to renew a Let's Encrypt certificate with different domains.</P><P>How do I set up a Checkpoint Security Gateway so that the requested domain is read from Let's Encrypt accesses and then forwarded to the correct internal web server?<BR />You can specify domains or FQDNs in the NAT rule, but then you also have to specify a domain name for the destination. However, the name is then resolved using either the external or internal IP address and therefore doesn't match the external or internal object entry.</P><P>So, how can I filter and forward requests based on the requested domain?</P> Wed, 10 Sep 2025 08:31:44 GMT https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/256991#M50365 Sebastian757 2025-09-10T08:31:44Z https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257046#M50368 <P>NAT does nothing for the Layer 7 information inside of HTTP, only the IP headers.<BR />In any case, this is more like&nbsp;Reverse Proxy functionality:&nbsp;<A href="https://support.checkpoint.com/results/sk/sk110348" target="_blank">https://support.checkpoint.com/results/sk/sk110348</A><BR />Not sure it will work in this case, otherwise you're looking at an <A href="https://usercenter.checkpoint.com/ucapps/rfe/" target="_self">RFE</A>.&nbsp;</P> Wed, 10 Sep 2025 17:11:29 GMT https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257046#M50368 PhoneBoy 2025-09-10T17:11:29Z https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257170#M50386 <P>Might be worth TAC case to verify.</P> Fri, 12 Sep 2025 13:21:29 GMT https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257170#M50386 the_rock 2025-09-12T13:21:29Z https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257176#M50387 <P>The best approach is to use a single certificate, with alt names for all your web applications, centralize the renewal in one server that listens to port 80 with the validation path&nbsp;/.well-known/acme-challenge correctly configured and use a renew hook script to copy the new cert to all your apps.<BR /><BR />This approach would also let you use the certificate with inbound HTTPS Inspection, which you can automate using the Management API. To do that, create an inspection rule, get the rule UID, add the new certificate via API and replace the cert used in the rule. You cannot overwrite a certificate, just upload the new one and modify the rule.</P> Fri, 12 Sep 2025 14:23:35 GMT https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257176#M50387 Pedro_Espindola 2025-09-12T14:23:35Z https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257177#M50388 <P>Isn't the Mobile Access Reverse Proxy available only after logging in? That would prevent the inbound validation connection from Let's Encrypt.</P> Fri, 12 Sep 2025 14:26:32 GMT https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257177#M50388 Pedro_Espindola 2025-09-12T14:26:32Z https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257198#M50391 <P>This is a feature of Mobile Access Blade but this is not the Mobile Access Portal.<BR />It won't require logging in.</P> Fri, 12 Sep 2025 22:12:59 GMT https://community.checkpoint.com/t5/Firewall-and-Security-Management/Let-s-Encrypt-forward-requests-to-the-correct-internal-server/m-p/257198#M50391 PhoneBoy 2025-09-12T22:12:59Z