quarantined email release fails

Releasing has recently gone wrong on my macos Sierra machine.

Tried it with Safari, Firefox and Chrome but all fail:

Safari Can't Open the Page "https://<fqdn>:3840/release.plc?proto=smtp&mp;cluster_id=0&amp;message_id=1c2X06-0006pM-MV&amp;size=3469&amp;whitelist;0" because Safari can't establish a secure connection to the server "<fqdn>".

Secure Connection Failed
An error occurred during a connection to vgk.rcan.nl:3840. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG


This site can’t provide a secure connection
<fqdn> sent an invalid response
Try running Network Diagnostics.



Now, a day later I found out that Safari is redirecting the http://<fqdn>:3840 to a https request. Odd. anyone experiencing similar issue?



  • In reply to Gary Prosser1:

    I dont see any logic have WAF and DNAT rules for web services
    Just for test
    LOGOUT from UTM and edit the host file in your PC. Put there the hostname of spam release with internal ip. 
    Flush your PC DNS. And click the link after

  • In reply to oldeda:

    The certificate is redirecting you


  • In reply to Gary Prosser1:

    You're right that the release is done on a different port, so the repaired NAT rule doesn't make a difference.  See #5 in Rulz to understand why you got the error message.

    If you have DNAT and WAF, see #2 in Rulz to understand that the DNAT causes traffic to bypass WAF (reverse proxy).  See the link in my previous post to understand when you need Full NAT instead of a DNAT.

    Oldeda is right - the best solution is split DNS where resolution inside your LAN is to the local IP, not the external address where you have nothing to handle port 3840 traffic from inside your LAN.

    Cheers - Bob

  • In reply to BAlfson:



    I get your advice. And maybe I have to swallow it and move all our dns to the utm via interface based host definitions.

    Meanwhile our current subnets, dhcp, dns config works fine considering we have a single utm and so for resilience we use ISP dns (via forwarders) for some subnets like visitor wireless where no internal hosts should be available, or lan based dns servers for subnet specific services, or in two cases an AD domain.

    Its currently a config that works for all except, and then only recently, in one case (and only for some internal clients) - ie the spam release.

    The bit of angst I feel is that the ssl error I've reported seems to come from the utm itself simply because either

    - it doesn't have an ssl capable listener on port 3840

    - the utm is redirecting non-ssl requests to ssl; I note you say this is a 'side effect' of NAT rules - really ? Actually we can't tell as there is no relevant logging (AFAIK).

    Since the default hostname for spam release is the utm itself (with an ssl cert defined, either self signed or uploaded) why is the utm release url coded as http not https ? 


  • In reply to Gary Prosser1:

    This morning I changed the dns record* for utm.<fqdn> from its external interface to my PC's relevant subnet interface

    * on our local bind server

    Then, from my pc on that subnet, I ping / dig utm.<fqdn> which comes back with the IP of the internal interface.

    I try release link - get same ssl error as previously stated. The utm http daemon log has

    2018:03:29-10:41:13 utm httpd: - - [29/Mar/2018:10:41:13 +0100] "POST /webadmin.plx HTTP/1.1" 200 484
    2018:03:29-10:41:14 utm httpd: - - [29/Mar/2018:10:41:14 +0100] "POST /webadmin.plx HTTP/1.1" 200 485
    2018:03:29-10:41:15 utm httpd: - - [29/Mar/2018:10:41:15 +0100] "\x16\x03\x01\x02" 404 -
    2018:03:29-10:41:15 utm httpd: - - [29/Mar/2018:10:41:15 +0100] "\x16\x03\x01\x02" 404 -
    2018:03:29-10:41:15 utm httpd: - - [29/Mar/2018:10:41:15 +0100] "\x16\x03\x01" 404 -
    2018:03:29-10:41:15 utm httpd: - - [29/Mar/2018:10:41:15 +0100] "\x16\x03\x01" 404 -

    1st two lines is my PC connected to utm.<fqdn>:4444

    A little later I also found this in the same log

    2018:03:29-10:55:14 utm httpd: - - [29/Mar/2018:10:55:14 +0100] "GET /release.plc?proto=smtp&cluster_id=0&message_id=1f0oKC-0001Z8-D9&size=37561&whitelist=0 HTTP/1.1" 200 452
    .15.138 that's a mobile device on our visitor subnet - the utm provides dhcp for that subnet; the dns servers are stated as those of our ISP ie the release link points to an external interface of the utm.
  • any news about this issue? Its definitly a chrome issue, because if you have visited one time an url with https, it requests in future only https (damn if you type a wrong url ....). i couldnt find a solution for chrome, all thinks i've found on google are to edit the apache server etc.......

  • In reply to x.cr3w:

    This is also an issue in Firefox

    If the browser connects to a HTTPS site (such as the user portal), the browser will change all future access to HTTPS even if on a different port.

    As this situation only occurs when UTM already has a certificate, one solution could be to add the option to have the the quarantine release on a different port with HTTPS, this would allow existing quarantine emails to continue to work.


  • In reply to automaton:

    This issue affects both FF on Windows (8) and Linux, and Safari on Mac - so it would be very helpful when Sophos fix it.

    On our utm9


    Listen 3840
            ServerAdmin admin
            DocumentRoot /var/content/httpd-spam
            SSLEngine Off
            Options ExecCGI

            <Directory /var/content/httpd-spam>       
              <Files _*>
                Order Deny,Allow
                Deny from All

    it could be

            SSLEngine on
            SSLCertificateFile /etc/httpd/WebAdminCert.pem
            SSLCertificateKeyFile /etc/httpd/WebAdminKey.pem
            SSLCACertificateFile /etc/httpd/WebAdminCertCA.pem

    which is what is in


    BUT the release links would have to be https://etc

  • In reply to Gary Prosser1:

    HAProxy could be used to listen to both HTTP and HTTPS on the same port, and proxy the connection to the appropriate web server instance


  • In reply to sachingurung:

    The issue is quite simple, HSTS is set on the user portal, because HSTS is set, "modern" browsers that honour the HSTS flag, change all access to HTTPS (the port is irrelevant)

    The only fix is to have the quarantine release run on HTTPS


  • In reply to automaton:

    automaton, I agree please see my post of

    12 Apr 2018 12:32

    how can we make an urgent request for Sophos to provide this 2 part fix ? it seems fairly straightforward.

  • In reply to automaton:

    Sounds good. I think its time to change all the links from utm to https. is there a way to do that? is sophos planing something about this?



  • In reply to sachingurung:

    PUSH :-]


    Got the same error on our customers. You guys already found out that it seems to be caused from HSTS.

    I hope Sophos will fix this soon.

  • In reply to x.cr3w:

    I'm just a home user, as a platinum partner, you might have more "leverage"...

  • In reply to Gary Prosser1:

    Support Case created and a preliminary response received.  I should hear back by Monday evening PDT USA.

    Cheers - Bob