Deep Inspection vs Certificate Inspection

Encryption is everywhere. A quick Google search tells me that an estimated 95% of traffic on the internet today is encrypted. While this is a great thing for privacy and security, it also creates a real problem for network security teams—we can no longer see what is inside most of the traffic flowing through our networks.

This is where SSL inspection comes into play.

This article will cover why SSL inspection matters, what certificate inspection actually provides, how deep inspection functions, how the trust models differ, and what deployment really looks like in practice. My goal is not just to explain the difference between the two, but also to help you (and me) understand when and why we might choose one over the other.

Why SSL Inspection Matters

Encryption is a double-edged sword. While it protects data in transit, it also blinds traditional security controls. Without SSL inspection, web filtering is limited, file scanning is not effective, and threats are able to hide inside encrypted channels without detection. If most of our traffic is encrypted, that means most of the threats are also hidden inside that encryption, which is the problem.

In corporate networks and schools, visibility is not optional. It is required to enforce policy and manage risks. SSL inspection exists to bridge the gap between security and encryption.

Certificate Inspection

Certificate inspection basically gives visibility into encrypted traffic without actually decrypting it. Instead of looking at the payload, the firewall analyzes the metadata from the TLS handshake, which is the information exchanged before the encryption is established. From that, it is able to see the Certificate Common Name and the Server Name Indication, which is enough to identify where traffic is going and make general filtering decisions.

What it cannot see is the HTTP host, the URI, or file contents. While certificate inspection is better than no inspection, it has a limit to what it can enforce.

Deep Inspection

Deep inspection functions differently from certificate inspection. Instead of just observing the handshake, the firewall sits between the client and server and inserts itself into the process.

The client connects to the firewall rather than directly to the destination. The firewall then establishes a separate connection to the server where traffic is decrypted, inspected, and re-encrypted before it continues. This is often described as a controlled man-in-the-middle.

To allow deep inspection to work, the firewall will generate its own certificate and present it to the client. It then connects to the real server, receives the server certificate, and creates a new one for that site which is signed with its own Certificate Authority. Once this CA has been installed on the client, the client will trust this new certificate as it has been re-signed by a certificate authority trusted by the client.

With this in place, the firewall can now see everything: the certificate CN and SNI, the HTTP host and URI, file contents, and the full payload. What this means is the firewall can now properly enforce antivirus, IPS, DLP, and file inspection the way it was designed to.

The Trust Model Difference

In a standard HTTPS connection, the client trusts a public certificate authority and will connect directly to the server. Certificate inspection does not change this trust model; the firewall will just observe the connection details.

Deep inspection is where the trust model changes. The client no longer trusts the CA directly; it trusts the firewall. Because of this, there are now two trust chains instead of one. The first is between the client and the firewall, the second is between the firewall and the server. The firewall now becomes the intermediary point of trust between the client and server.

Server Certificate (example.com)
      ↓
Intermediate CA
      ↓
Root CA (trusted by client)

Client
     ↓
Public CA (trusted root)
     ↓
Server Certificate (example.com)

Firewall (passively inspects SNI/CN only)

Client
     ↓
Re-signed Certificate (example.com)
     ↓
Firewall CA
     ↓
Trusted on client device

Firewall
     ↓
Real Server Certificate
     ↓
Public CA (e.g., DigiCert)

Real World Impact

As I and many of us know, deep inspection is not a set-it-and-forget-it solution, but an ongoing process.

Some applications such as banking apps or Microsoft and Apple services do not tolerate certificate re-signing or require strict validation; therefore, these can break once deep inspection is applied. What this means is deploying deep inspection is less about the deployment and more about the tuning.

In a perfect deployment, users should not notice anything. However, it is common to run into certificate warnings if the CA is not deployed correctly, slower browsing if the firewall is not up to spec for the number of users, and application failures that will require exceptions. Due to this, it is essential to properly deploy the certificate and keep the firewall healthy to deploy this with minimal friction.

Then we must consider the privacy and legal implications of deep inspection. Now that the firewall is decrypting all traffic, there is visibility into personal communications, financial activity, and potentially regulated data. Based on the regulations of your own environment, you must consider GDPR, HIPAA, and acceptable use policies. A common approach to this is excluding sensitive categories such as financial or healthcare traffic from deep inspection.

When to Use Each

Deep inspection is most suitable for an environment you fully control and require the highest visibility. In a corporate managed network where devices are domain-joined or managed via Intune or other MDM solutions, deployment can be fairly straightforward. With this level of control, you are able to deploy the certificate without introducing many certificate warnings or user-facing issues.

Deep inspection is very valuable in higher security environments. The vast majority of modern threats exist in encrypted traffic, especially in LAN-to-WAN flows. Without decryption, almost all security controls we are able to apply are not nearly as effective. Deep inspection restores the functionality of these controls by restoring that visibility to the firewall.

Certificate inspection is a good choice when you do not control the client devices or where stability and privacy are more important than full visibility. Some examples of this would be guest or BYOD networks. From my experience, trying to deploy a trusted CA to every personal device is quite the hassle and usually results in frustrated end users. I have also found certificate inspection is useful for internal traffic where breaking functionality outweighs the added security controls. Some applications are not tolerant of certificate re-signing, and rather than fighting an uphill battle, it can make more sense to leave decryption out of the picture and take the path of least resistance.

A Practical Approach

What I have found is the best approach is not choosing just certificate inspection or just deep inspection, but a combination of both.

A good approach can be starting with certificate inspection broadly, then enabling deep inspection selectively. By starting with a controlled selection, we reduce the maintenance overhead while also minimizing the user impact. As deep inspection is enforced, users will naturally find issues. This is where the tuning begins: adding exceptions, revising policies, and deploying the missed certificates here and there. This method allows you to find a healthy balance of usability and visibility without having to solve everything from the start.

The Trade Off

While deep inspection gives us meaningful visibility and control, it also changes the trust model significantly, which introduces other things to think about.

The firewall is no longer just passing traffic. The firewall now holds the private keys and has access to all communications. Because of this, the firewall must now be treated as even more critical and sensitive. This means keeping up to date with firmware, restricting administrative access, and protecting the private keys are not optional. If the firewall is compromised, it now grants the attacker the same visibility we had configured for security to be used in a malicious manner.

This is where the trade-off really comes into focus for me. While deep inspection gives us the ability to see and control almost all of your traffic, it also introduces risks and complexity that you must adapt to. Whether that is worth it depends on your environment, the risk tolerance, and how much visibility you can go without.

Final Thoughts

Encryption is the standard now, and that is not changing. The question is no longer whether traffic is encrypted, but how much visibility you are willing to forgo and what you will do about that.

Deep inspection allows us to reclaim that visibility at the price of complexity and ongoing maintenance. While certificate inspection is lighter, causes fewer issues, and is easier to manage, it leaves real gaps. The most effective deployments are not only certificate inspection or deep inspection, but a deliberate balance of both with intentional tuning.