Implementing Sophos Firewall TLS Inspection Correctly

A large portion of today’s web traffic is encrypted. Without TLS Inspection, the firewall often only sees the destination IP, SNI, certificate information, and metadata, but not the actual content of the connection.

This is a security issue: many protection functions cannot or can only very limitedly check encrypted payloads. Malware scanning, web protection, zero-day analysis, content scanning, and parts of application or threat detection only become truly effective when the firewall can decrypt, inspect, and then re-encrypt TLS traffic. IPS and NDR also benefit from more plaintext visibility. Without decryption, many signals remain limited to metadata, certificates, IPs, domains, or protocol information.

However, TLS Inspection is not a feature that should be activated unprepared for all users. It can disrupt applications, raise privacy concerns, and increase the firewall’s load. Therefore, TLS Inspection should be introduced in a planned, gradual manner with a clear exception strategy.

Orientation

Start by deciding which protection or configuration method fits the actual use case. This avoids broad rules and duplicated troubleshooting later.

License and Requirements

For TLS Inspection and the meaningful evaluation of decrypted traffic, the appropriate protection licenses are required.

The most important are:

• Web Protection: Includes Web Security, Web Control, Application Control, and Web Malware Protection.
• Network Protection: Includes IPS, Security Heartbeat, and other network protection functions.
• Zero-Day Protection: Becomes important when files or downloads need to be additionally analyzed using machine learning or sandboxing.

Web Protection is included in the Standard Protection license bundle. Xstream Protection and Epic Protection also include Web Protection and other protection modules. For the classification of bundles, see What Sophos Firewall Bundles Are Available?; for Base License, support status, and subscriptions, see Understanding Sophos Firewall Base License.

Important for planning: SSL/TLS Inspection Rules and URL groups can still be relevant with a Base License. Web categories can be configured, but without Web Protection they are not enforced as a web category criterion. Anyone who wants to use categories, web policies, malware scanning, or Zero-Day features seriously therefore needs the appropriate protection license and should not discover this only during the pilot.

Before rollout, you should check:

• Current Sophos Firewall firmware is installed.
• Web Protection is licensed.
• The firewall’s CA certificate is distributed to clients.
• A test group or test network is defined.
• Rollback is documented.
• Exception process is clarified.
• Logging is activated.

If the CA certificate has not yet been distributed, the article Install Sophos Firewall CA Certificate for HTTPS Scanning can help.

⚠️ TLS Inspection can disrupt applications that use certificate pinning or conduct their own certificate checks. The rollout should always start with a test group and not directly with all users.

The re-signing CA must be trusted by the endpoints. In practice, this means distributing the certificate to the operating system or browser trust store, or using a subordinate enterprise CA. A publicly trusted CA cannot simply be obtained for this, because the firewall signs new server certificates for third-party domains during decryption.

DPI or Web Proxy?

Sophos Firewall can implement HTTPS decryption in two modes:

• DPI Mode: The firewall rule uses the DPI engine. SSL/TLS Inspection Rules under Rules and policies > SSL/TLS inspection rules decide what is decrypted.
• Web Proxy Mode: The firewall rule uses the Web Proxy. HTTPS decryption is then controlled via the web proxy settings and web policies.

For modern setups, DPI Mode is often used. Sophos Firewall evaluates the firewall rule first and then the SSL/TLS Inspection Rules. If a firewall rule forces Web Proxy, DPI-based SSL/TLS Inspection Rules do not apply as one would expect with a direct-mode rule.

1. Open Rules and policies > Firewall rules.
2. Edit the affected LAN-to-WAN rule.
3. Open Security features > Web filtering.
4. Activate the appropriate web policy.
5. Activate Scan HTTP and decrypted HTTPS.
6. Leave Use web proxy instead of DPI engine disabled if SSL/TLS Inspection Rules should apply.

Scan HTTP and decrypted HTTPS is important, but it does not enable HTTPS decryption by itself. In DPI Mode, matching SSL/TLS Inspection Rules are also required. In Web Proxy Mode, HTTPS decryption must be enabled through the proxy options. If Use web proxy instead of DPI engine is enabled, the proxy filters classic web traffic on ports 80 and 443, while the DPI engine can continue to handle HTTP and SSL/TLS traffic on other ports. Before rollout, it should therefore be clear whether the environment uses Web Proxy or DPI, otherwise exceptions will later be searched for in the wrong place.

Which Traffic Should Be Decrypted?

You should not blindly decrypt everything. Good TLS Inspection starts with clear goals.

Sensible initial targets:

• LAN > WAN: classic user web traffic to the internet.
• Wi-Fi > WAN: managed clients in the company WLAN.
• VPN > WAN: remote access users when their internet traffic runs through the firewall.
• LAN > DMZ: internal access to own servers when security checks are desired there and certificates are properly distributed.

Handle with caution:

• Banking, health, government, and highly sensitive portals.
• Password managers and identity providers.
• Operating system and manufacturer update services.
• Mobile apps and Android devices.
• Applications with certificate pinning.
• Voice, video, and collaboration services if they become unstable due to decryption.
• Android devices, especially when Google services, Play Store or connectivity checks are affected.

For server publications from the internet into the DMZ, TLS Inspection is not automatically the best solution. For web servers, Web Server Protection / WAF or a reverse proxy is often more sensible.

Consider QUIC and Web Policy

If web traffic is not inspected as expected despite TLS Inspection, you should also check QUIC or HTTP/3. Many browsers can establish HTTPS connections over UDP 443. Depending on the rule and web policy design, the traffic may not run through the expected classic HTTPS path over TCP 443.

In client internet rules, you should consciously check:

• Is the appropriate web policy active?
• Is Block QUIC protocol active in the actually matching firewall rule?
• Is Scan HTTP and decrypted HTTPS set according to the decryption strategy?
• Does the rule use DPI or Web Proxy?
• Do you see UDP 443, TCP 443, web policy events, and SSL/TLS inspection events consistently in the Log Viewer?

The procedure for blocking QUIC is described in Correctly Blocking QUIC and HTTP/3 on Sophos Firewall. For the web policy itself, see Creating a Sophos Firewall Web Protection Policy.

QUIC is particularly tricky because Block QUIC protocol is set automatically in some web filtering scenarios, but in grown rule sets it is not necessarily active on the rule that actually matches. For a pilot, therefore do not only inspect the intended rule, but verify the real hit in Log Viewer.

Plan Rollout

TLS Inspection should be introduced gradually so that exceptions, client certificates and support cases remain manageable.

Rollout Strategy

A phased approach has proven effective:

1. Distribute CA certificate.
2. Prepare web policy and firewall rule.
3. Select decryption profile.
4. Define a small test group.
5. Activate SSL/TLS Inspection Rule only for this group.
6. Monitor Control Center and Log Viewer.
7. Analyze errors and document exceptions clearly.
8. Gradually expand to other user groups.

This way, you can identify early which applications cause problems without affecting the entire operation.

Plan Rollout Phases

A TLS Inspection rollout should be planned in phases. This keeps it manageable and allows you to separate technical errors from acceptance or application problems.

• Preparation: CA, web policy, firewall rule, and test group are ready. CA distribution, license, logging, rollback.
• Pilot: a few managed clients test productive everyday life. Log Viewer, Dashboard Widget, user feedback.
• Expansion: include more user groups or networks. Document exceptions, monitor performance.
• Operation: TLS Inspection is regularly reviewed. Review of exclusions, reports, errors, and new applications.

It is important that each phase has a clear exit point. If a business-critical application breaks during the pilot, a broad global exception should not be set immediately. A clean analysis is better: which domain, which client, which rule, which decryption profile, and which error in the Log Viewer are affected?

Define Pilot, Owner, and Exception Process

Before the first productive rollout, it should be clear who manages the test group, who approves exceptions, and how errors are reported back. Otherwise, TLS Inspection quickly generates unordered exceptions: individual domains are hastily set to Don't decrypt without it being clear later why the exception exists.

For operation, these points should be documented:

• Pilot group, affected networks, and timeframe.
• Owner for web policy, decryption profile, and SSL/TLS Inspection Rules.
• Process for new exceptions with reason, ticket, and review date.
• Criteria for when an application is exempted and when the cause is checked first.
• Place where Log Viewer, Dashboard Widget, and user feedback are collected.
• Rollback if business-critical applications are disrupted.

Particularly important is the separation between technical exception and permanent security decision. A temporary exception can be sensible to get a service working again. However, this exception should be reassessed later once the cause, risk, and alternative are clear.

Test Rollback Before Rollout

A rollback should not be invented only during an outage. Before the pilot, it should be clear how TLS Inspection can be removed from the test group without confusing other rules, Web Policies or exceptions.

Practical rollback check:

• Remove test group: check that the SSL/TLS Inspection Rule no longer matches the pilot client.
• Disable rule: verify that traffic again uses the expected non-decryption path.
• Test exception: a targeted Don't decrypt rule must be above the general decrypt rule and visibly match in Log Viewer.
• Keep Web Policy: rolling back decryption must not accidentally remove web filtering, malware scanning or logging completely.
• Document evidence: record test client, target domain, rule name, log event and time.

This test is especially important when several admins work on Web Policies, firewall rules and SSL/TLS Inspection Rules. A clean rollback only removes the affected scope and does not make the whole Web Protection chain blind.

Configuration

The configuration should be narrow, testable and easy to review later.

Understanding Decryption Profiles

A Decryption Profile determines how strictly the firewall handles TLS connections. The profiles can be found under Profiles > Decryption profiles.

A decryption profile answers, among other things, these questions:

• What happens with invalid or untrusted certificates?
• Are old TLS versions blocked?
• Are insecure cipher suites blocked?
• What happens with SSL compression?
• What happens with unrecognized cipher suites?
• What happens if the firewall cannot decrypt a connection?
• Which CA is used for re-signing?

For an initial rollout, a more compatible profile is sensible, such as Maximum compatibility or a custom conservative profile. For productive security rules, a stricter profile like Block insecure SSL can be used later.

Important: The decryption profile is selected directly in the SSL/TLS Inspection Rule. The profile can override the global SSL/TLS inspection settings for this rule. Therefore, when troubleshooting, you should always check the specific rule and not just the global settings.

With TLS 1.3, the action of the SSL/TLS Inspection Rule is especially important. Certain checks such as TLS downgrade detection, blocking certificate errors or minimum requirements for RSA keys only work meaningfully when the rule really uses Action > Decrypt. A Don't decrypt exception is therefore not a softer form of inspection, but deliberately removes the traffic from decryption.

Creating an SSL/TLS Inspection Rule

The menu path is Rules and policies > SSL/TLS inspection rules.

SSL/TLS Inspection Rules are normally active on fresh installations, but can be disabled manually. If they are switched off, no SSL/TLS inspection details appear in Control Center or Log Viewer. This matters for troubleshooting: an empty Log Viewer can also mean that the engine or rule processing is not active at all.

An initial rule should be as targeted as possible:

• Action: Decrypt
• Decryption profile: conservative test profile
• Source zones: LAN or test network
• Source networks and devices: test group or test subnet
• Destination zones: usually WAN
• Destination networks: initially Any
• Services: often Any to start, as SSL/TLS can also be recognized on other TCP ports
• Websites / Categories: optionally restrict
• Log connections: enable this so the pilot and error analysis remain traceable

The rule only applies when all configured criteria match. Source, destination, users or groups, service, and websites or categories are therefore not a loose OR construct. The more criteria are set, the more precise the scope becomes, but the easier it is for a pilot to appear not to work because a single criterion does not match the real traffic.

SSL/TLS Inspection Rules can detect TLS connections outside the classic HTTPS port, but cannot enforce this over UDP. The rules are processed from top to bottom. Specific exceptions and pilot rules should therefore be above general decrypt rules, otherwise it will be difficult later to understand why a connection was decrypted or exempted.

For new rules, the basic logic is:

1. Open Rules and policies > SSL/TLS inspection rules.
2. Select Add.
3. Set a descriptive Rule name, for example TLS decrypt pilot clients.
4. Choose Rule position so that exceptions sit above general decrypt rules.
5. Choose Action: Decrypt, Don’t decrypt or Deny.
6. Enable Log connections.
7. Define Source, Destination, Services and Websites or Categories to match the pilot.
8. Select the Decryption Profile.
9. Save and immediately test with a test client.

Exclusion Lists

Not all TLS traffic should be decrypted. Sophos uses exclusion rules and TLS Exclusion Lists for this.

Local TLS Exclusion List

The Local TLS exclusion list is the firewall’s local exclusion list. This list is empty by default and can be filled through troubleshooting in the Control Center or Log Viewer.

You can also edit it manually:

Web > URL groups > Local TLS exclusion list

This list is useful for domains that cause problems in your environment, for example, due to certificate pinning or special client applications.

Managed TLS Exclusion List

The Managed TLS exclusion list contains exceptions maintained by Sophos for known problematic services. This list is updated through firmware updates.

Typical examples are services where TLS Inspection is known to cause problems or is technically not sensible.

Custom Exclusion Rules

Additionally, you can create your own SSL/TLS Inspection Rules with Action > Don’t decrypt. These should be directly below the default exclusion rule and only contain traffic that really should not be decrypted.

Possible criteria:

• Web categories
• URL groups
• Users and groups
• Source and destination networks
• IP addresses
• Services

Exceptions should be documented: domain, reason, affected users, date, and review date.

SSL/TLS Exclusions and Web Exceptions are not the same tool. An SSL/TLS Exclusion decides whether a TLS connection is decrypted and can apply in DPI Mode to SSL/TLS connections on any TCP port. A Web Exception is more closely tied to the web policy context, for example HTTPS decryption, certificate validation, malware or content scanning, Zero-Day Protection, or web policy checks. In practice, first clarify whether decryption itself must be excluded or whether only a web policy exception is needed.

For non-decryptable but trusted legacy connections, a separate Decryption Profile can be useful, treating certain cases such as old SSL versions, SSL compression or unrecognized cipher suites as Allow without decryption. This is not a general best practice for normal web use, but a targeted compatibility decision for clearly named destinations. For production internet rules, such exceptions should be tightly limited and reviewed regularly.

Monitoring and Evaluation

After activation, consider dashboard, Log Viewer and test clients together. This is the only way to see whether traffic is really decrypted or whether exceptions, errors or QUIC change the expected path.

Monitoring the Dashboard Widget

In the Control Center, there is a widget for SSL/TLS Inspection. This widget is very helpful for monitoring rollout and errors.

It shows, among other things:

• Percentage of decrypted SSL/TLS sessions.
• Percentage of non-decrypted SSL/TLS sessions.
• Other traffic.
• Errors from the last few days.
• Top websites or top users with problems.
• Decryption peak and decryption limit.

If many errors appear in the widget, you should not immediately disable all TLS Inspection. It is better to use Fix errors to specifically check the affected targets and create clean exceptions if necessary.

Evaluating the Log Viewer

In the Log Viewer, you can select the SSL/TLS inspection filter. There you can see what happened with individual connections.

The colours help with the initial assessment:

• Red: Error. The connection could not be correctly decrypted or processed. Here you should check certificate errors, cipher suites, TLS versions, or incompatible applications.
• Green: Do not decrypt. The connection was deliberately not decrypted, for example, due to an exclusion rule or a TLS Exclusion List.
• Blue: Decrypt. The connection was decrypted and then re-encrypted and forwarded.

In the log, you also see decryption profile, source IP, destination IP, user, category, and target domain. This allows you to check whether the correct rule matched and whether an exception really applies.

With Don't decrypt, always check why the traffic was not decrypted: standard exclusion, Managed TLS exclusion list, Local TLS exclusion list, custom exception or wrong rule order. A green connection only means that it was not decrypted; it does not yet prove that the exception is technically correct.

Tests

After activating TLS Inspection, you should check:

• Is the Sophos CA certificate used in the browser?
• Do important business applications work?
• Are there TLS errors in the Log Viewer?
• Are malware or web policy events correctly detected?
• Is the traffic displayed as decrypted in the Control Center widget?
• Does the firewall performance remain within the expected range?
• Are there complaints from test users?

For troubleshooting, Log Viewer, Policy Test, browser certificate view, Packet Capture, and the SSL/TLS Inspection widget are particularly helpful.

Troubleshooting and Operation

TLS Inspection problems are usually solved through clear exceptions, controlled rollback and regular review.

Typical Errors

• Browser shows certificate warning: CA missing in trust store or wrong CA used. CA distribution, certificate chain in browser, client restart.
• Log Viewer shows no SSL/TLS inspection events: wrong mode, no matching rule, or SSL/TLS engine not active. Firewall rule, DPI/Web Proxy, SSL/TLS Inspection Rule.
• Traffic is allowed but not decrypted: Don't decrypt rule, managed exclusion, or wrong rule order. Check SSL/TLS Inspection Rules from top to bottom.
• Web filter does not work as expected: Web policy missing, QUIC active, or Scan HTTP and decrypted HTTPS misunderstood. Matching firewall rule, QUIC, web policy log.
• Android clients lose internet or Play Store access: certificate pinning is often involved. Check mobile device network, Google destinations and targeted Don't decrypt rule.
• Individual applications break: Certificate pinning, old TLS version, incompatible cipher suite, or own certificate check. Log Viewer, decryption profile, targeted exception.
• Many errors in the dashboard widget: too broad rollout or unsuitable decryption profile. Reduce pilot group, sort errors by domain and category.
• Performance drops after activation: too broad scope, large downloads, or too many simultaneous sessions. Check decryption scope, firewall load, and top users.
• Exception does not work: Exception is below a more general decrypt rule. Check rule order and matching criteria.

In unclear cases, you should not change multiple things at once. A tighter test case is better: one client, one target domain, one firewall rule, one decryption profile, and a clear time in the Log Viewer.

Rollback

If disruptions occur, a clear rollback should be possible:

• Deactivate SSL/TLS Inspection Rule.
• Remove test group from the rule.
• Soften decryption profile.
• Add exception for affected domain or application.
• Switch firewall rule back to Web Proxy if that is consciously desired.

SSL/TLS Inspection Rules and the SSL/TLS engine must be visibly active for the Control Center and Log Viewer to display details. If you deactivate SSL/TLS Inspection for troubleshooting purposes, you should reactivate it afterwards and briefly document the state.

Operational Recommendation

TLS Inspection is not a one-click project. Properly implemented, however, it provides significantly more visibility and enhances the effectiveness of Web Protection, Malware Scanning, IPS, NDR, and Zero-Day functions.

For productive environments, we recommend:

• Start with LAN-to-WAN for a small test group.

• Distribute CA certificate properly.

• Consciously choose DPI/Web Proxy mode.

• Do not start decryption profile too aggressively.

• Monitor Log Viewer and Dashboard daily.

• Document exceptions and review regularly.

• Only roll out further after successful tests.

• Keep rollback tested for the pilot group and exceptions.

FAQ