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

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.

  • 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!
  • Yes, that's quite annoying. Please consider chaning this in future releases...
  • 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

     

     

  • 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.
  • In reply to ChavousCamp:

    Sorry guys,

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

    Luk
  • 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...

  • In reply to oxident:

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

  • In reply to ChavousCamp:

    There is a feature request about this issue: feature.astaro.com/.../11580213-captive-portal-fqdn-support

    Please vote!

  • 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.

  • 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.

  • In reply to BalazsBorbely:

    + 1 vote.

    Luk

  • In reply to BalazsBorbely:

    Then you need a publicly trusted certificate with IP SAN. I suggest to talk to some CA vendors. I can't speak for all of them, but I can confirm that for certain types of certificates Symantec supports this scenario. This is quite often used in public hotspots which distribute private IP address space.

  • In reply to Slawski:

    Slawski,

    this is a temporary workaround. Sophos should allow us to configure hostname on XG and generate appropriated Certificates by name.


    Luk

  • FYI, in v16, if I navigate to the domain name setting in the LAN DHCP it uses that as the "hostname" of the firewall. For Captive Portal and for Admin access if you have an SSL certificate, then you don't get the warning and the certificate can match the local domain name.

     

    Regards,

    Gary

  • In reply to GaryChancellor:

    Sorry, where exactly in the GUI? I'm afraid it's not clear at all.

     

    Regards,

    Filippo