Thread Info
  • State Verified Answer
  • +5 person also asked this people also asked this
  • Locked Locked
  • Replies 36 replies
  • Answers 5 answers
  • Subscribers 43 subscribers
  • Views 86002 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Is there a way to use the hostname for captive portal instead of IP?

ChavousCamp

Really, the subject says it all... is there a way to configure the HTTPS & HTTP proxies to redirect to a hostname instead of the IP address of the firewall?

Reason I ask is I'd really like to keep my certificates consistent.  We use an internal PKI, and so I have issued the XG a valid certificate based on our root cert.  Yes, I can go back and re-issue it with the IP address, but I would like for it to redirect, if possible, to the internal hostname instead.

Similar to overriding the hostname for the external SSL vpn... I want to do it on an internal-facing service.

If the answer is currently "not possible" - I would like to suggest this as a feature.



This thread was automatically locked due to age.
  • 0
    Hello, i am searching for seting up the hostname too but without any success so far. So this is what i like to know too!
  • 0
    Yes, that's quite annoying. Please consider chaning this in future releases...
  • 0

    You can generate the self signed certificate from CLI in the following way:

    1. openssl genrsa -des3 -out sophosxg.key 1024

    2. openssl req -new -key sophosxg.key -out sophosxg.csr

    3. fill all the required field and pay attention with common name (put your desired XG name instead IP)

    4. cp sophosxg.key sophosxg.key.org

    5. openssl rsa -in sophosxg.key.org -out sophosxg.key

    6. openssl x509 -req -days 365 -in sophosxg.csr -signkey sophosxg.key -out sophosxg.crt

    7. cat sophosxg.key sophosxg_cert.crt > sophosxg_cert.pem

    Use ftpput from XG to your computer to copy pem file and .key.

    Now on UI go to Certificate and upload the new certificate using previous files and create a new CA using the same files.

    Enjoy.

    Luk

     

     

  • 0 in reply to lferrara
    Read the question, Luk. That doesn't solve it.

    The question is how to get the portal to USE the hostname... you can create a certificate all day long. It will still USE the IP address every. single. time for redirects. EVERY single time.
  • 0 in reply to ChavousCamp
    Sorry guys,

    I misunderstood! Absolutely they need to allow us to redirect captive portals to hostname too.

    Luk
  • 0

    After thinking about this particular issue, the current behaviour makes it impossible to avoid any certificate warnings if the user starts his browser session with a https connection (attempt)!

    I don't think that it's possible to get a certifcate from a trusted issuer for your XG's IP (instead of FQDN). Therefore, any public hotspot solution will fail.

    Maybe I'm wrong but this effectively limits the captive portal to be used only by clients who trust your internal PKI and use this to issue a certificate for your XG's IP address.

    Strange...

  • 0 in reply to oxident

    You sum up a good portion of the issue quite eloquently.  Maybe someone will listen... We can hope....

  • 0 in reply to oxident

    You can add IP SAN if you have an internal PKI deployed. Installing custom root authority certificates on user's machines is necessary for HTTPS inspection to work anyway. And this is what I did. Created a simple "scripted" CA using OpenSSL and uploaded its signing certificate to SFOS. I have also issued a certificate for my box with both name and IPS as SANs. Everything works fine (root certificated had to be added to trusted authorities). Even Google Chrome presents green lock when I'm using IP Address.

    BTW: Symantec allows IP SANs for Intranet and RapidSSL certificates but not for public certificates.

  • 0 in reply to Slawski

    While this is a possible workaround, there are environments where you can't "touch" the client to install a root certificate. (Also, if you can do that, most of the time you could even install the Single Sign-on Client, and the captive portal is not needed anymore.)

    Other firewalls have a simple textbox on the webadmin, where you can type in the FQDN where the browser is redirected to. We need the same functionality in XG Firewall.