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

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

  • For the XG units I have that have been successively upgraded from v15, I'm seeing the following:

    - Sandstorm analysis in progress still uses ApplianceCertificate certificate, regardless of certificate specified for Captive Portal.

    - The Captive Portal certificate doesn't get pushed into /cfs/web/apache/sslcert.conf which is used for the [<IP>:8090] virtual host.

    Recreating the ApplianceCertificate certificate to include the IP and FQDN hostname as sAN attributes fixes up the remaining virtual hosts and makes this work as I'd expect according to the documentation of this feature addition. Although you still need to push out the Appliance CA certificate and add it to the client PCs' trusted root CA certificate store.

    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.

  • Why is that "The email Quarantine Digest will always use the IP". This way quarantine will be available only for internal or external users, not for both.

  • Hi Chris,
    I appreciate that you are trying to understand the system but please be aware - you are hacking the system without any knowledge of how it works.  Some of what you are posting is wrong or at least misleading.  I don't want to spend too much time trying to explain how it works because, quite frankly, you shouldn't be doing that.
     
    Lets back up.
    Using the documentation in community.sophos.com/.../132058
    What end-to-end functionality is not working as you expect?
  • FilippoBastianello said:

    Why is that "The email Quarantine Digest will always use the IP". This way quarantine will be available only for internal or external users, not for both.

     

    The Email quarantine digest uses a separate setting, configured under Email > Quarantine Digest > Reference User Portal IP. When we built the "proxy_use_hostname" feature for 17.1 we did not realize email was a separate configuration (built by a different team).  We are looking at options for changing this in the future.

     

    There is no reason why you cannot use the same IP for both internal and external users, as long as you can route there.  Putting in a hostname/FQDN does not change the fact that the FQDN will resolve to a single IP address which will be one of the interface IPs (the same interface IPs you can select right now).

  • "There is no reason why you cannot use the same IP for both internal and external users". In Email > Quarantine Digest > Reference User Portal IP I can choose one interface (I usually choose LAN or WAN). How can I route users from one zone to the IP chosen?

    "Putting in a hostname/FQDN does not change the fact that the FQDN will resolve to a single IP address" is not necessarily true if you use, as in my case, split DNS in order to resolve FQDN differently, depending on which zone you are in; usually internal DNS for LAN and public DNS for WAN

  • Thanks to the saint-like patience of Michael Dunn, I was able to work out that my Captive Portal certificate binding issue was due to the fact that PFX Import - while helpfully reporting that it imported the certificate chain correctly - would result in the awarrenhttp service (responsible for handling the Captive Portal) not being able to find the Root CA from the Intermediate CA and would silently roll back to using the ApplianceCertificate certificate. Once I imported the Root CA, Intermediate CA and leaf certificates separately as PEMs it worked correctly.