I am trying to setup a connector between a Fortigate Firewall and Azure AD. To do this I need to setup a CA issued certificate. However, I’m a noob and not exactly sure how to do this.
We have a company website that is hosted in the cloud and do have several Static public ipv4 IP’s from our ISP.
From my research it seems that most CA’s require a FQDN to setup a certificate but I would like to set one up using the public IP address. What would be the best way to go about that?
Setup a certbot behind the firewall? Somehow attach the public IP to our FQDN?
Let’s Encrypt doesn’t issue certificates for IP addresses. No amount of masquerading or hiding behind firewalls will change that. I would imagine other authorities handle it the same way (fortnately haven’t had a need to use one since LE came about).
“Attaching” an IP address to an existing, signed certificate won’t work either. The whole point of a certificate is that it is provably not manipulable.
I have no experience with Azure or Fortigate, but I suspect both would let you add your own CA to the trusted store. For internal use, I would probably maintain my own CA.
I am not familiar with Fortigate. However, if you are using a registered domain name in your local network you can get signed certificates for this domain, even wildcard certificates, i.e. *.yourdomain.tld or *.sub.domain.tld.
What I don’t know though, is how to get these certificates as automated as possible on your Fortigate or on your AD controller. But if necessary you can add them manually.
So If the Fortigate doesn’t provide an acme client and you don’t want to pay for signed certificates, you can also run Certbot or acme.sh as standalone application, for example in a Linux VM, and if you don’t want to open Port 80, you can use the DNS challenge mode.
The renewal of the certificates can be automated, if your DNS provider supports adding DND records via an API, if not, it can also be done manually:
DNS manual mode · acmesh-official/acme.sh Wiki · GitHub.