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.
config vpn certificate local
edit VPN_SSL
set enroll-protocol acme2
set acme-domain vpn.ilcasco.com
set acme-email my email
It produced this output:
Contacting ACME server for vpn.ilcasco.com at https://acme-staging-v02.api.letsencrypt.org/directory
Unsuccessful in contacting ACME server at https://acme-staging-v02.api.letsencrypt.org/directory. If this problem persists, please check your network connectivity from your Apache server to the ACME server. Also, older servers might have trouble verifying the certificates of the ACME server. You can check if you are able to contact it manually via the curl command. Sometimes, the ACME server might be down for maintenance, so failing to contact it is not an immediate problem. Apache will continue retrying this.
Contacting ACME server for vpn.ilcasco.com at https://acme-staging-v02.api.letsencrypt.org/directory: Unsuccessful in contacting ACME server at https://acme-staging-v02.api.letsencrypt.org/directory. If this problem persists, please check your network connectivity from your Apache server to the ACME server. Also, older servers might have trouble verifying the certificates of the ACME server. You can check if you are able to contact it manually via the curl command. Sometimes, the ACME server might be down for maintenance, so failing to contact it is not an immediate problem. Apache will continue retrying this.
Pinging 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com [172.65.46.172] with 32 bytes of data:
Reply from 172.65.46.172: bytes=32 time=8ms TTL=57
Request timed out.
Reply from 172.65.46.172: bytes=32 time=8ms TTL=57
Reply from 172.65.46.172: bytes=32 time=8ms TTL=57
Ping statistics for 172.65.46.172:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 8ms, Average = 8ms
exe ping acme-staging-v02.api.letsencrypt.org
PING 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com (172.65.46.172): 56 data bytes
64 bytes from 172.65.46.172: icmp_seq=0 ttl=58 time=8.7 ms
64 bytes from 172.65.46.172: icmp_seq=1 ttl=58 time=8.0 ms
64 bytes from 172.65.46.172: icmp_seq=2 ttl=58 time=8.5 ms
64 bytes from 172.65.46.172: icmp_seq=4 ttl=58 time=9.6 ms
Based on what I'm seeing, it looks like your wanting to put a certificate on your firewall that is publicly accessible and yet you are having some issues.
I'm sorry your post started this morning and I was unable to respond until now. A lot of the volunteers here probably will avoid touching this until a lot more information comes from your side.
So your fortigate firewall is an appliance yes?
Is this a VPN that is accessible for several users or clients?
Have you entertained the idea of using a self signed certificate?
Is there an Acme client built into this device?
If not, is there is a workstation or a server somewhere behind the firewall that can talk to the world, and especially let's encrypt?
This is what I see when I peek at a tool to see the eligibility of the certificate being issued to your domain.
It's important that you can talk to the let's encrypt API, but it's also important that let's encrypt can talk to your system. Your port 80 is closed or filtered, not gonna work. And port 443 is also filtered, is not going to do a lot of good.
So were at a conundrum here. If there is not an application or service on your firewall to obtain a let's encrypt certificate, you'll need to have a workstation or server behind the firewall that can make the request. Port 80 and port 443 need to be open to the world. (Especially port 80)
Let's start here and see what happens. It's easy to put a certificate on a device or an appliance long as you have some kind of service or workstation that can make the request and be reachable from the Internet. I know your firewall has an address in DNS, but if there's no client to talk to the let's encrypt servers then you're not going to get anywhere.
I may be totally out of bounds. I may not know what I'm talking about. I may not understand your environment based on the information you're giving us. But it sounds like you need certificate for your firewall and you may need to use a server or workstation or something to get it. Possibly a workstation using DNS challenge… You can copy the cert to the firewall. But I simply just don't know your environment well enough to advise beyond this.
Please give us more info.
You are correct that we are trying to apply the certificate to our firewall for SSLVPN and HTTPS control. According this guide it should "just work": New Features | FortiGate / FortiOS 7.0.0 | Fortinet Documentation Library. I find it odd that when we ping https://acme-staging-v02.api.letsencrypt.org/directory we get failures. Is it possible LetsEncrypt is trying to blacklist or IP? If we ping from our secondary ISP, it succeeds with 100% response. I'm not 100% sure on the process but I believe when we create the cert in the firewall, it opens the ports required automatically. I don't think there is a way to manually perform this action. I also have a ticket open with the Firewall vendor but when I talked to them yesterday, they were pointing the finger at LetsEncrypt so here we are stuck in the middle. I believe my issue is similar to the one here but I'm running the firmware that they said would fix it at the end of the forum. How to recreate a certificate on Fortigate FOS 7.0.1 - Help - Let's Encrypt Community Support (letsencrypt.org). Hopefully I helped answer some of your questions.
It is possible. Let's Encrypt blocks some IPs if they are aggressively retrying but not succeeding (often because of misconfiguration). If this your first attempt at getting a Let's Encrypt certificate, it's unlikely unless you inherited an IP that was already blocked. You should check with curl -iL https://acme-staging-v02.api.letsencrypt.org/directory If you get errors that helps rule out a network issue between the two hosts and will provide a message if the connection at the Let's Encrypt is being blocked.
I just contacted the vendor again and this is supposedly a bug in the current firmware as well and supposed to be fixed in the next release. As a work around the CLI should work but hasn't for me. They want me to try rebooting the firewall tonight and see if the CLI will work. The GUI points to the staging URL and the CLI is supposed to point to https://acme-v02.api.letsencrypt.org/directory. I will update this forum once I reboot the firewalls and try again.
After rebooting the firewall, we are able to obtain the certificate successfully! This must be done through the CLI when using version 7.0.3. The issue is supposed to be fixed in a later version. For anyone who has the same issue here is the commands you need to run:
config vpn certificate local
edit "certificate_name"
set enroll-protocol acme2
set acme-domain "certificate_domain"
set acme-email "email_address"
set acme-ca-url https://acme-v02.api.letsencrypt.org/directory
next
Yes, and normally that GUI version would work. However, it is a known bug (0757130) according to Fortigate support. The GUI creates the certificate using the expired CA LetsEncrypt certificate and points the CA to acme-staging-v02.api.letsencrypt.org. When using the CLI, we can force the FortiGate to use the correct CA URL https://acme-v02.api.letsencrypt.org/directory which creates the certificate successfully. This is supposedly supposed to be fixed in the next firmware release.
I believe my issue is similar to the one here but I'm running the firmware that they said would fix it at the end of the forum. 