Personal tools

HTTPS Inspector

From UntangleWiki

Jump to: navigation, search

Image:HttpsInspector_128x128.png     HTTPS Inspector
Other Links:
HTTPS Inspector Description Page
HTTPS Inspector Screenshots
HTTPS Inspector
HTTPS Inspector FAQs


About HTTPS Inspector

The HTTPS Inspector is a special application that allows other Untangle applications and services that process HTTP traffic to also process encrypted HTTPS traffic. It does this by performing man-in-the-middle style decryption and encryption of HTTPS traffic, passing the unencrypted HTTP traffic through the Untangle server for inspection by other applications and services.

When a client makes an HTTPS request, the Inspector first initiates a secure SSL connection with the external server on behalf of the client. While this session is being established, the inspector captures information about the server SSL certificate. Once the server session is active, the Inspector uses the details from the server certificate to create a new certificate that will be used to encrypt the session between the inspector and the client. This certificate is generated or loaded on the fly, and is created using the same subject details contained in the actual server certificate. The certificate is then signed by the internal CA on the Untangle server, and is used to establish a secure connection between the inspector and the client. Creating the certificate this way is necessary to eliminate security warnings on the client, but it does require a few extra steps to properly configure the client computers and devices on your network. See the SSL Certificates section below for details.

SSL Certificates

SSL Certificates serve two primary purposes. They allow traffic between the client and server to be encrypted, and they allow the client to validate the authenticity of the server. There are two main ways the client checks the authenticity of the server certificate. The first is by validating the server certificate to ensure it has been issued or signed by a known and trusted third party certificate authority. Once that trust has been established, the client checks the server name portion of the target URL to ensure it matches the server name registered in the certificate presented by the server. If either of these checks fail, the client will typically display a warning, indicating that the security of the connection may be compromised.

When the Untangle server is initially installed, a default Certificate Authority is created automatically and used to sign the man-in-the-middle certificates created by the HTTPS Inspector. To view or make changes to the internal Certificate Authority, check out Certificates tab of the Config/Administration page.

Config > Administration > Certificates

Client Configuration

For the client authenticity checks to be successful, the client must be configured to trust the root certificate used by the Untangle server to sign the man-in-the-middle certificates described above. To configure clients, you must first use the Download Root Certificate button located on the Configuration tab of HTTPS Inspector Settings page to download the root certificate. You must then install this certificate in correct the location on the client.

Another way to download the root certificate is to simply access a special URL using the IP address of the Untangle server:

Simply replace with the IP address of your Untangle server. This method is especially useful when using mobile devices. For example, accessing this URL on an iPad or iPhone will download and display the certificate, and provide an option to install and trust the certificate directly on the device.

Below are basic instructions for installing the root certificate on some common client platforms. If yours is not listed, or you have any difficulty, consult the reference material for the target platform for further information.

Internet Explorer or Google Chrome on Microsoft Windows

  1. Log into the Untangle server running HTTPS Inspector.
  2. Go to Settings/Configuration and download the certificate using the "Download Root Certificate" button.
  3. Copy the root_authority.crt you just downloaded to the Windows client computer.
  4. From a command prompt, or from Start/Run, run the command "certmgr.msc".
  5. Open the "Trusted Root Certification Authorities" tree in the panel on the left.
  6. Right click on "Certificates" and select All Tasks --> Import.
  7. Proceed with the Certificate Import Wizard, selecting the the root_authority.crt file.

Firefox on Microsoft Windows

  1. Log into the Untangle server running HTTPS Inspector.
  2. Go to Settings/Configuration and download the certificate using the "Download Root Certificate" button.
  3. Copy the root_authority.crt you just downloaded to the Windows client computer.
  4. Launch Firefox
  5. From the Tools menu, go to Options -> Advanced -> Encryption -> View Certificates -> Authorities
  6. Click the Import button and select the root_authority.crt file.
  7. Enable the "Trust this CA to identify websites" checkbox and click the OK button.

Opera on Microsoft Windows

  1. Log into the Untangle server running HTTPS Inspector.
  2. Go to Settings/Configuration and download the certificate using the "Download Root Certificate" button.
  3. Copy the root_authority.crt you just downloaded to the Windows client computer.
  4. Launch Opera
  5. From the Tools menu, go to Preferences -> Advanced -> Security and click Manage Certificates
  6. Select the Authorities tab, click Import, and select the root_authority.crt file.
  7. Click Install and click OK when asked if you are sure you want to trust the certificate.

Group Policy Distribution

If you have a fully deployed and implemented Active Directory infrastructure, you can leverage the Group Policy model to distribute the Untangle root certificate to all of your client computers. This is way outside our own area of expertise, so we can't provide much help or assistance, but we have compiled links to some TechNet articles with instructions for several common versions of Windows Server.

Windows Server 2003

Windows Server 2008

Windows Server 2012


This section describes the different settings and configuration options available for HTTPS Inspector.


Download Root Certificate

As described above, client computers and devices on your network need to be configured to trust the root certificate of the Untangle server. Clicking this button will allow you to download the root certificate. Once downloaded, you need to install it in the Trusted Authorities certificate store on your client computers and devices. Note that this is the same root certificate that can be downloaded from the Config > Administration > Certificates page. The download link is included on the HTTPS Inspector Configuration page for convenience.

Block Invalid Traffic

When processing a new HTTPS session, the first thing the inspector does is analyze the initial client request to see if it contains a valid SSL negotiation message. If not, by default the session will be ignored and the traffic will flow directly between the client and server with no inspection performed. By enabling this checkbox, you can change the default behavior and effectively block any port 443 traffic that does not contain a valid HTTPS signature.

Trust All Server Certificates

Normally, when establishing an SSL connection with an external server, the inspector will authenticate the server certificate against a standard list of trusted certificate authorities. If this trust cannot be established, the inspector will end the session. By enabling this checkbox, you can force the inspector to blindly trust all external server certificates.

Please note that we DO NOT recommend running with this option enabled, as it exposes all HTTPS traffic to significant security risks.

The standard list of trusted certificates used by Untangle is generated from the standard ca-certificates package. It includes, among others, certificate authorities used by Mozilla's browsers. Please note that Untangle can neither confirm nor deny whether the certificate authorities whose certificates are included in this list have in any way been audited for trustworthiness or RFC 3647 compliance. Full responsibility to assess them belongs to the local system administrator.

Upload Trusted Certificate

The inspector emulates a web browser when it makes outbound connections to external web servers. Just like a web browser, it must verify the authenticity of the server certificate before it will trust the connection and allow traffic to flow freely. As mentioned above, the inspector uses a standard list of known certificate authorities to validate server certificates. However, it's also possible you have servers in your network that use certificates that can't be authenticated this way. Perhaps you have your own certificate authority, or use self-signed certificates. Whatever the reason, you can use section of the configuration page to upload additional certificates that you want the inspector to trust.


The Rules tab allows you to specify explicit rules to Inspect or Ignore HTTPS traffic that crosses the Untangle. By default, many common HTTPS sites (google, youtube, yahoo, etc) are inspected, but not all HTTPS. This provides a safe default which provides HTTPS inspection on those sites without interfering with other HTTPS communications. It can easily be configured to inspect all HTTPS by enabling the "Inspect All Traffic" rule.

The Rules documentation describes how rules work and how they are configured. HTTPS Inspector uses rules to determine if it should inspect or ignore traffic for the specific session.

In addition to all the common rule types, there are three that are unique to the HTTPS Inspector, and these can be very useful for ignoring traffic that you don't want to inspect, or that isn't compatible with the HTTPS Inspector.

HTTPS: SNI Hostname

Most web browsers and many client applications include the destination hostname in the initial packet of an HTTPS session. The mechanism used is called the Server Name Indication, or the SNI extension to the TLS protocol. The main purpose is to allow a single web server to host multiple secure web sites. By analyzing the SNI hostname in the client request, the server can decide which SSL certificate to use for encrypting the session. This extension is necessary because the encryption must be established long before the server ever sees the HTTP request, and by then it would be too late to use a different certificate.

Creating ignore rules based on the SNI hostname is an effective way to have the HTTPS Inspector ignore incompatible traffic. A prime example is the default rule for Microsoft Update. The Microsoft Update client checks the server certificate to ensure it was signed by a specific authority. Since it doesn't trust the Root Aurthority the HTTPS Inspector uses to generate certificates on-the-fly, Microsoft Update will fail with an error. The default rule allows this traffic to be detected and ignored, allowing Microsoft Update to work properly.

HTTPS: Certificate Subject and HTTPS: Certificate Issuer

These two rule conditions are useful when dealing with client applications that don't use SNI, and aren't compatible with HTTPS Inspector. An excellent example is the Dropbox client utility for which there is also a default rule. Like Microsoft Update, the Dropbox client will reject SSL certificates that it doesn't explicitly trust.

Using either of these rule conditions, you can match traffic on any portion of the Subject or Issuer Distinguished Name (DN) included in the server certificate. In both cases, the information in the match string includes the standard information fields commonly stored within the SSL certificates, such as CN (common name), C (country), ST (state), L (locality), O (organization), and OU (organizational unit). Each of these are appended to the match string and separated by commas. Note that not all fields are required in all certificates, and some certificates may have others not listed. The order they occur in the match string is also not guaranteed.

The Subject DN generally includes information about the company to which the certificate was issued. Here is an example Certificate Subject:

CN=*, O="Dropbox, Inc.", L=San Francisco, ST=California, C=US

The Issuer DN generally includes information about the company that issued and authenticated the certificate. Here is an example Certificate Issuer:

CN=Thawte SSL CA, O="Thawte, Inc.", C=US

Rule Actions

  • Inspect: Causes the traffic which matched the rule to be decrypted and passed along to other applications and service for further inspection, classification, and possible action.
  • Ignore: Causes the traffic which matched the rule to be ignored the HTTPS Inspector.

Event Log

Use the following terms and definitions to understand the Application Control event log.


The time the event took place.


The Active Directory name of the user associated with the session.

Client IP

The client IP address of the traffic.

Client Port

The client port of the traffic.

Server IP

The server IP address of the traffic.

Server Port

The server port of the traffic.

Rule ID

The numbered rule that resulted in the creation of the log entry. If this value is zero, the event was generated directly by the application in response to receiving an untrusted server certificate, or as a result of some other problem while processing network traffic.


The status of the session that generated the event.

  • INSPECTED means the session was fully processed by the inspector, and all traffic was passed through all the other applications and services.
  • IGNORED means the session was not or could not be inspected, so the traffic was completely ignored and not analyzed by any applications or services.
  • BLOCKED means the traffic was blocked because it did not contain a valid HTTPS request, and the Block Invalid Traffic option was enabled.
  • UNTRUSTED means the traffic was blocked because the server certificate could not be authenticated.
  • ABANDONED means the traffic was blocked because of a problem with the underlying SSL session.

This field may be emtpy, or may contain additional information about the event, such as the SNI hostname included in the initial client request packet, or the IP address of the external server.

HTTPS Inspector FAQs

Does HTTPS Inspector work with Captive Portal?

Yes, HTTPS Inspector will decrypt HTTPS request to HTTP which will then be handled just like normal HTTP request by Captive Portal. If the client is captured and not authenticated they will be redirected to a login page.

HTTPS Inspector does not seem to be working with google and Chrome. Why?

Newer Chrome versions use a custom protocol call QUIC to communicate with google. Adding a Firewall Rule or Filter Rule to block port 443 UDP will block QUIC and force chrome to use regular HTTPS which will be handled normally.