Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Lolo-b
New Contributor

Let's encrypt enrollment pb

Hi , I meet a pb with my Fortigate F60 with 7.2.11 OS when I try to create a Let's Encrypt cert ...

The Local In Policy accepts Port 80 and 443 on the concerned interface and there is no conflict with SSL VPN config (Port xx443) . When I try to generate the certificate with the Let's Encrypt assistant , I've got an error msg saying the server is not able to validate the http-01challenge. 

1) Is it necessary to have the file with the challenge string in the /.well-known/acme-challenge/ webserver folder or the Fortigate acme client is able to validate without the file ?

2) I am able to access Fortigate Admin Gui from my lan but not from outside as something blocks 80 and 443 ports in the fortigate 

 

Many thanks for your help

Laurent

1 Solution
Yurisk
SuperUser
SuperUser

1) No, it is not needed to have any files, Fortigate has built-in ACME agent that will do everything by itself, provided you choose HTTP validation (well, its the default and only one available so)

2) It actually may point to the problem source - port 443 is already used by some other daemon in FGT. To make sure it is not:

  • Verify there is no VIP that port-forwards port 80/443 to some internal server
  • If HTTPS management protocol is enabled on the WAN interface - change admin port from 443 to something else, and after that disable "Redirect to 443" from port 80. Actually Let's Encrypt servers connect Fortigate on port 80 1st, and if it doesnt work - try to port 443
  • Verify Lcoal-in policy if exists that it does not limit access to FGT WAN interface on ports 80/443 to specific IPs

 

My personal (unsolicited) take on it - I do not enable ACME and auto-renewal on FGT and thus opening ports 80/443 on FGT to the whole World, I prefer wildcard certificates anyway and these are not possible to issue on FGT from Let's Encrypt, so I use DNS verification for such certs on a standalone hardened linux server that has no incoming access on any port from Internet.

https://yurisk.info

View solution in original post

https://yurisk.info
3 REPLIES 3
sw2090
SuperUser
SuperUser

this is the default behaviour of lets encrypt. 

Lets Encrypt themselves also do support using DNS for the challenge (i.e. some TXT record) but I'm not sure wether FortiOS implemented that...

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Yurisk
SuperUser
SuperUser

1) No, it is not needed to have any files, Fortigate has built-in ACME agent that will do everything by itself, provided you choose HTTP validation (well, its the default and only one available so)

2) It actually may point to the problem source - port 443 is already used by some other daemon in FGT. To make sure it is not:

  • Verify there is no VIP that port-forwards port 80/443 to some internal server
  • If HTTPS management protocol is enabled on the WAN interface - change admin port from 443 to something else, and after that disable "Redirect to 443" from port 80. Actually Let's Encrypt servers connect Fortigate on port 80 1st, and if it doesnt work - try to port 443
  • Verify Lcoal-in policy if exists that it does not limit access to FGT WAN interface on ports 80/443 to specific IPs

 

My personal (unsolicited) take on it - I do not enable ACME and auto-renewal on FGT and thus opening ports 80/443 on FGT to the whole World, I prefer wildcard certificates anyway and these are not possible to issue on FGT from Let's Encrypt, so I use DNS verification for such certs on a standalone hardened linux server that has no incoming access on any port from Internet.

https://yurisk.info
https://yurisk.info
Lolo-b
New Contributor

Hi Yurisk , many thanks for your relevant and useful help ... have a good day

Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors