Skip to main content
Version: 2.22.0

Enable ICAP

Glasswall ICAP Server​

  • The ICAP Server in the OVA listens on the ports chosen during appliance setup: 1344 for open connections and 11344 for mTLS unless they were changed. Both are reachable on the appliance's address directly.
  • Ports 31344 and 31345 continue to reach the same listeners, so a client already pointed at them keeps working and does not need repointing. They stay fixed even if the listening ports are changed.
  • The appliance ships with the ICAP server installed but not running. Nothing answers on the ICAP ports until you turn it on, so a client connecting before then is refused.
  • The ICAP tab appears only when your licence includes the ICAP entitlement. If you cannot see it, contact your Glasswall account contact.

Enable the ICAP server​

  1. Sign in to the Portal as an administrator.
  2. Open Protection settings and select the ICAP tab.
  3. Under ICAP configuration, choose Enable ICAP server.

The control shows the state the appliance is actually in, not the one you asked for. It reads Starting the ICAP server… until the server is ready to answer, and only then reports it as running.

The ICAP configuration and profile settings on this tab can be changed only while the ICAP server is on. While it is off they are shown inactive, marked Inactive until the ICAP server is turned on — that is the expected state of a stopped server, not a fault.

When the control is unavailable​

Where the control cannot be used it is shown inactive with the reason. There are three:

Reason shownWhat it means
This installation does not turn the ICAP server on and off from the portal. It is set where the appliance is deployed.The installation was deployed without permission to change it.
The ICAP server is not installed on this appliance, so there is nothing to turn on.The ICAP server was never deployed to this cluster.
Whether the ICAP server runs is set by autoscaling on this installation, so it cannot be changed from the portal.Autoscaling owns how many ICAP servers run, so a change made here would be reverted.

Enable mTLS​

By default, mTLS is not configured, and only the open port is active. To enable mTLS on the ICAP server, follow the steps below.

  1. Create a set of client and server mTLS certificates along with a CA certificate. The server certificates will be used in the ICAP server and the client certificates will be used in a client application such as a proxy or a firewall.

  2. SSH to the Halo Virtual Machine created from the OVA.

  3. Save the cdrplatform-secrets Kubernetes secret to a file.

kubectl get secret cdrplatform-secrets -o yaml > cdrp-secrets.yaml
  1. Edit the cdrp-secrets.yaml file and add 3 keys, tls-cafile, tls-server-cert and tls-server-key under the data section.
apiVersion: v1
data:
 <existing secrets>
 <existing secrets>
 tls-cafile: <base64-encoded-tls-cafile>
 tls-server-cert: <base64-encoded-tls-server-cert>
 tls-server-key: <base64-encoded-tls-server-key>
kind: Secret

tls-cafile must contain the self-signed root certificate. The ICAP server validates each client certificate against this file, and a chain can only be trusted if it ends at a self-signed root present here. An intermediate-only file leaves nothing to anchor to and every client is refused. For a two-tier authority, concatenate the intermediate and the root into one PEM file.

  1. Apply the edited cdrp-secrets.yaml.
kubectl apply -f cdrp-secrets.yaml
  1. Create acr-secret to authenticate to glasswallhub container registry. The token_ID and token will be provided by the Glasswall.
kubectl create secret docker-registry acr-secret -n cdrplatform \
 --docker-server="glasswallhub.azurecr.io" --docker-username="${token_ID}" --docker-password="${token}"
  1. Pull the ICAP Server Helm chart:
helm pull oci://glasswallhub.azurecr.io/helm/icap-server --version 2.2.3 --untar --untardir .
  1. Capture the settings this appliance is already running with, so the redeploy keeps them:
helm get values icap-server -o json > icap-server-current.json

This matters because the ICAP ports are chosen during appliance setup. Redeploying without these values would put the ports back to their defaults and stop the appliance serving them on the node.

  1. Redeploy ICAP Server with mTLS enabled:
helm upgrade --install icap-server icap-server --atomic \
 --set service.type=NodePort \
 --set cloud_provider=local \
 --set image.tag="2.22.0-212371" \
 --set image.repository=glasswallhub.azurecr.io/icap-server \
 --set image.pullPolicy=IfNotPresent \
 --set secretsFromRef[3].DATABASE__ConnectionString.secretName="mongodb-cdrplatform-cdrp-user" \
 --set secretsFromRef[3].DATABASE__ConnectionString.key="connectionString.standard" \
 --set configuration.HALO__Version="2.22.0" \
 -f icap-server/values.yaml \
 -f icap-server-current.json \
 --set settings.ICAP.MutualTlsEnabled=true

The order of the two -f files matters: the chart's own file supplies the defaults, and the appliance's captured values are layered over it.

Note: this redeploy can start the ICAP server even if you had turned it off. Once it completes, open Protection settings → ICAP in the Portal and check the server is in the state you want.

Note: configuration.ENABLE_MTLS was replaced by settings.ICAP.MutualTlsEnabled. A saved command still passing the old key stops the redeploy with a message naming the replacement, rather than being ignored.

Note: the certificate volume is always mounted, so enabling mutual TLS no longer changes the pod specification. It still takes effect on the next ICAP server restart, which this redeploy performs, because the listener binds its port at startup.

Note: while mutual TLS is disabled the ICAP server does not bind the TLS port at all. Earlier releases bound the port and refused every connection on it, so a port scan of an appliance without certificates no longer reports that port as open.

Once the above command is successful, the ICAP server listens for mTLS on the TLS port set during appliance setup — 11344 unless it was changed — as well as the open port, 1344 by default. Both are reachable on the appliance's address directly, and on node ports 31345 and 31344.

When connecting to the ICAP Server through a secure connection the URI Scheme submitted in the ICAP Client request should be icaps. This indicates that a secure connection is expected. Example Secure-ICAP url:

icaps://gw-icap-server.net:11344/resp-cdr-service

Disable the ICAP server​

  1. Sign in to the Portal as an administrator.
  2. Open Protection settings and select the ICAP tab.
  3. Under ICAP configuration, choose Disable ICAP server and confirm.

The appliance stops answering ICAP requests and any client pointed at it is refused. Your saved ICAP settings are kept and apply again when you turn the server back on.

Last updated on