Skip to main content
bfogliano
bfogliano
New Member
February 5, 2025
Question

Cannot secure Fortigate public IP with CA signed certificate

  • February 5, 2025
  • 7 replies
  • 2976 views

I have read every article on the internet on this topic and worked with Fortinet TAC for 2 days.  All of the articles say you can secure the public IP of the Fortigate by putting the public IP in the Host IP section for the common name in the CSR.  Done this, does not work.  Once the wildcard is rekeyed for the subdomain it shows the top level domain in the cert and that it is applied on the IP login but the browser still says not secure.  I have tried this with the SAN as the DNS name for the site, and it secures the DNS name for the site but not the IP.  Has anyone successfully done this and how, and why would Fortinet documentation say this can be done if it can't (this is what TAC says and would not escalate)?

7 replies

AEK
SuperUser
AEK
SuperUser
February 6, 2025

When generating the CSR, in the "Subject Alternative Name", did you enter the IP address directly like this: "1.2.3.4", or did you add "IP:" prefix like that: "IP:1.2.3.4"?

AEK
    ebilcari
    Staff
    ebilcari
    Staff
    February 6, 2025

    If a private root CA is used to sign the CSR, than usually yes it is possible to insert IP as SAN. Public root CAs will not allow to put IP in the SAN and probably will strip them out from the the CSR while signing the certificate. This is not a limitation of FGT but mostly from the root CA that is used.

    Emirjon
      AEK
      SuperUser
      AEK
      SuperUser
      February 6, 2025

      Hi Emirjon

      I think it does. Unless if google is an exception.

      gglcrt.png

      AEK
        ebilcari
        Staff
        ebilcari
        Staff
        February 6, 2025

        In this case google is self signing its own certificate so the rule doesn't apply :).

        There are also some exceptions for large organization like shown here, but based on what I've seen, most of the time you can't get a public signed certificate for a public IP.

        Emirjon
          bfogliano
          bfoglianoAuthor
          New Member
          February 6, 2025

          Ok so the agreement is that you cannot secure a public IP with a certificate on a firewall, correct?

          AEK
          SuperUser
          AEK
          SuperUser
          February 6, 2025

          The agreement is you can but with private CA, and "probably" not with public CA.

           

          Edit: You can still check with your public cert provider if he can do it for you.

          AEK
          bfogliano
          bfoglianoAuthor
          New Member
          February 6, 2025

          Believe me I worked with GoDaddy for hours they were of no help. 

          AEK
          SuperUser
          AEK
          SuperUser
          February 6, 2025

          Then try find a CA that can do it, like the one shared by Emirjon.

          AEK
          bfogliano
          bfoglianoAuthor
          New Member
          February 6, 2025

          Ok if my customer is good with just securing the DNS name is there a way to block 443 access then to firewall on the WAN interface?  Today they use 10443 for admin access on the WAN interface.  I have put in local in policy to block 443 on the WAN interface but telnet test to 443 still works.  Am I missing something? 

          AEK
          SuperUser
          AEK
          SuperUser
          February 6, 2025

          Local in policy if it is well configured should block the access as expected.

          Should be like that.

          config firewall local-in-policy
           edit 1
            set intf "wan1"
            set srcaddr "all"
            set dstaddr "1.2.3.4"
            set service "HTTPS"
            set schedule "always"
            set action deny
           next
          end
          AEK
          bfogliano
          bfoglianoAuthor
          New Member
          February 7, 2025

          Ok here is the weirdest thing.  I have applied that exact Local In you showed on both firewalls and only 1 is blocking the connection to 443.  

          This one works

          config firewall local-in-policy
          edit 2
          set uuid 2c381c5e-e4cd-51ef-fc7a-6cfcc55b8019
          set intf "wan1"
          set srcaddr "all"
          set srcaddr-negate disable
          set dstaddr "wan1-IP"
          set internet-service-src disable
          set dstaddr-negate disable
          set action deny
          set service "HTTPS"
          set service-negate disable
          set schedule "always"
          set status enable
          set comments ''

           

          This one does not

          config firewall local-in-policy
          edit 2
          set uuid 78d309cc-e4c6-51ef-d267-3c77db370faf
          set intf "wan1"
          set srcaddr "all"
          set srcaddr-negate disable
          set dstaddr "wan1-IP"
          set internet-service-src disable
          set dstaddr-negate disable
          set action deny
          set service "HTTPS"
          set service-negate disable
          set schedule "always"
          set status enable
          set comments ''

           

          Am I missing something

          bfogliano
          bfoglianoAuthor
          New Member
          February 10, 2025

          This is the two rules for each firewall

           

           
           

          config firewall local-in-policy
          edit 1
          set uuid ae9f5406-9bbb-51ef-f6dd-2a8d82bb10ee
          set intf "wan1"
          set srcaddr "all"
          set srcaddr-negate disable
          set dstaddr "wan1-IP"
          set internet-service-src disable
          set dstaddr-negate disable
          set action deny
          set service "TIMESTAMP"
          set service-negate disable
          set schedule "always"
          set status enable
          set comments ''
          next
          edit 2
          set uuid 78d309cc-e4c6-51ef-d267-3c77db370faf
          set intf "wan1"
          set srcaddr "all"
          set srcaddr-negate disable
          set dstaddr "wan1-IP"
          set internet-service-src disable
          set dstaddr-negate disable
          set action deny
          set service "HTTPS"
          set service-negate disable
          set schedule "always"
          set status enable
          set comments ''
          next
          end

           

          AEK
          SuperUser
          AEK
          SuperUser
          February 10, 2025

          It looks fine. So probably a bug. Which FortiOS version?

          AEK
          bfogliano
          bfoglianoAuthor
          New Member
          February 10, 2025

          7.6.2 on both boxes

          AEK
          SuperUser
          AEK
          SuperUser
          February 10, 2025

          There is a bug in 7.6.2 that "may" have relationship with your issue.

          1104649

          If a local-in policy, DoS policy, interface policy, multicast policy, TTL policy, or central SNAT map used an interface in version 7.4.5, 7.6.0 or any previous GA version that was part of the SD-WAN zone, these policies will be deleted or show empty values after upgrading to version 7.4.6 or 7.6.1.

          Workaround: After upgrading to 7.4.6 or 7.6.1 GA, users must manually recreate these policies and assign them to the appropriate SD-WAN zone.

           

          Try purge your local-in policies and recreate them again.

          Hope it helps.

          AEK
          Terms & ConditionsAccessibility statement