Fortigate Generating/Renewing Certificate Without 443/80 Open

[yalexander21]

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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: remote.thecharmanthotel.com

I ran this command: none

It produced this output: none

My web server is (include version): Fortigate

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

My hosting provider, if applicable, is: Self

I can login to a root shell on my machine (yes or no, or I don't know): Yes, but its a firewall.

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): Unknown, built into firewall FW

I have a Fortigate firewall running a VPN gateway. The gateway has a LE cert applied to it. The firewall hosts the webserver itself, and has a built in LE feature which generates and renews LE certificates.

I am able to generate a cert and apply it without issue, if my "webserver" is open to 443, however, this "webserver" needs to be on a custom port for "security". What I have been doing is flipping over to 443, renewing, then flipping back to the custom port. This works without issue, I just would rather not do this every 90 days. Is there any way to have LE verify the domain on a custom port?

[MikeMcQ]

@yalexander21

Is there any way to have LE verify the domain on a custom port?

Well, not exactly. The initial request for an HTTP Challenge is HTTP with port 80. You can re-route that internally all you want but it starts there.

For a TLS-ALPN Challenge that uses HTTPS and port 443. Perhaps this is what that internal Fortigate ACME Client is using.

The other alternative is a DNS Challenge. This has Let's Encrypt validating against a TXT record in your DNS. Many common ACME Clients support this especially since you use Cloudflare as your DNS provider.

However, I don't know if Fortigate ACME Client supports that. Probably better question for them or some other volunteer with personal experience with Fortigate.

See: Challenge Types - Let's Encrypt

[yalexander21]

Thanks for the reply. I read up briefly on the DNS verification, if the Fortigate supports that I think it would be my best option. Or perhaps a VIP tied to a policy that forwards traffic to and from LE across 443 to the custom port.

[MikeMcQ]

@yalexander21

if the Fortigate supports that I think it would be my best option.

Definitely.

@yalexander21

Or perhaps a VIP tied to a policy that forwards traffic to and from LE across 443 to the custom port.

I don't exactly follow those terms but if it is for TLS-ALPN challenge that very likely won't forward like an HTTP Challenge.

A very specific reply is expected for TLS-ALPN and the ACME Client would normally be the one to make that reply.

An HTTP challenge is routine request. You can route that from your network "edge" to an internal anything as long as the reply goes out. For HTTP Challenge you can also redirect HTTP to HTTPS as noted in the docs link I provided. But, you can't specify an alternate port for those kinds of redirects.

A DNS Challenge could be run on any machine in your network if you have a way to get its cert to your Fortigate. It only needs port 443 outbound access to the public internet to reach the Let's Encrypt API server.

[jvanasco]

Everything that @MikeMcQ said is correct, he just glossed over some nuances in his explanation:

• The HTTP-01 challenge has an inbound port 80 HTTP request; it could have a HTTP redirect (or internal proxy) from port 80 to 443 on your device.
• The TLS-ALPN-01 challenge has an inbound port 443 HTTPS request.

Your device is most likely using one of those challenges.

For DNS-01, there are some security considerations as the DNS credentials must be installed on the machine. If your device does support DNS-01, it's best to delegate the _acme-challenge.fqdn. DNS entry onto a secondary DNS provider or use an API credential that only affects that record (which is only possible on a small subset of DNS providers).

The TLS-ALPN-01 challenge doesn't do forwards; it needs to speak a specific protocol to the server it contacts. This restriction, and the challenge itself, is due to an implementation detail in the status-quo of HTTPS deployments on shared hosting servers that makes it an insecure authorization vector for ACME authorization.

What I have been doing is flipping over to 443, renewing, then flipping back to the custom port.

That may be something you can automate using hooks in Certbot, or wrappers with other clients. Many people use them to toggle firewall rules during renewal.