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?

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.
Parents
  • Version 17.1 has now been released. Once you have updated to v17.1, you can switch to using the device hostname for the Captive Portal and other end-user interactions as follows:

    1) Log in to the Firewall console over ssh
    2) Select option 4 (Device Console)
    3) Enter the following command at the prompt:
    set http_proxy proxy_url_use_hostname on
    4) To confirm that it has set, enter the following command:
    show http_proxy
    5) Type ‘exit’ to return to the menu and logout.

     

     

    source : https://ideas.sophos.com/forums/330219-xg-firewall/suggestions/11580213-captive-portal-fqdn-support 

  • While you can now use the Hostname FQDN using the steps you outlined, it does not use the specified certificate for the Captive Portal - it defaults to using the default ApplianceCertficate certificate.

    EDIT: This may not be the case for everyone, but it certainly is for me on the units I have that have been successively upgraded from v15.

  • Here is our KB article about the feature:

    https://community.sophos.com/kb/en-us/132058

    >>

    To upload a certificate, go to Certificates > Certificates.

    To select the certificate to use, go to Administration > Admin Settings > Port Settings for Admin Console.

    <<

    All HTTPS traffic that goes to directly to the box, whether by IP or hostname, should be using the certificate selected above.

  • The following pages will use the settings.

    • Captive Portal
    • User Portal
    • Guest User Registration
    • Clicking Proceed on the Warning page
    • Sandstorm analysis in progress

     

    The email Quarantine Digest will always use the IP.

    NTLM authentication (which is only HTTP) will always use the IP.

     

    Let me know if there are any other pages that do not follow the configured setting.

     

  • Hi Michael,

    For the units I have that have been successively upgraded from v15, I have the following problem:

    - Not all the virtual hosts use the correct certificate binding.

    - /cfs/web/apache/sslcert.conf continues to use the ApplianceCertificate certificate, rather than the specified certificate

    AFAICT this is anything that uses the virtual host [<ip>:8090] which includes the Sandstorm analysis page.

    Workaround for this specific problem was to recreate the ApplianceCertificate certificate to include the IP and FQDN hostname as subjectAlternativeName attributes. A process made difficult by having to find an openssl.cnf file, fix it to match the current certificate store layout + ability to sign certificates with sAN attributes, and finding where in the Postgres db the certificate passphrases are stored.

    Once this was done, everything now works as I would expect according to the documentation you provided.

    EDIT: This may not be the case for everyone, but it certainly is for me on the units I have that have been successively upgraded from v15.

Reply
  • Hi Michael,

    For the units I have that have been successively upgraded from v15, I have the following problem:

    - Not all the virtual hosts use the correct certificate binding.

    - /cfs/web/apache/sslcert.conf continues to use the ApplianceCertificate certificate, rather than the specified certificate

    AFAICT this is anything that uses the virtual host [<ip>:8090] which includes the Sandstorm analysis page.

    Workaround for this specific problem was to recreate the ApplianceCertificate certificate to include the IP and FQDN hostname as subjectAlternativeName attributes. A process made difficult by having to find an openssl.cnf file, fix it to match the current certificate store layout + ability to sign certificates with sAN attributes, and finding where in the Postgres db the certificate passphrases are stored.

    Once this was done, everything now works as I would expect according to the documentation you provided.

    EDIT: This may not be the case for everyone, but it certainly is for me on the units I have that have been successively upgraded from v15.

Children
No Data