Confirm the Deployment Is Ready
SafeSquid is not production-ready until service state, proxy routing, license status, inspection, policy, and log evidence all agree. This page is the sequence that ties those checks together and the record you keep when they pass. Each step links to the detailed check. Work them in order — a failure early on makes every later result unreliable.Validate prerequisites
Before running the sequence, confirm:- SafeSquid is installed and activated. Use Activate Your License if the license is not active.
- At least one pilot client uses SafeSquid as its proxy. Use Connect Your Client for the routing path.
- You have shell access to the SafeSquid server.
- The test window is approved in the change record.
- Rollback exists for proxy settings, firewall rules, and client routing.
Run the validation sequence
1
Prove service and listener state
Confirm the proxy listener, process ID, service state, and local DNS resolution in Service Health.Confirm the listener, process, and resolver checks all show SafeSquid is running.If any check fails, inspect service logs before routing more users.
2
Open the interface safely
Load the Configuration Portal from an approved management path, following Access the Management Interface.Confirm the portal loads and the management path used is recorded.If the portal does not load, verify browser proxy settings, listener state, and network ACLs.
3
Confirm activation
Check product type, subscription state, and expiry, following Activate Your License.Confirm product, subscription, and expiry details are populated.If activation details are missing, re-upload the activation key and test subscription reachability.
4
Prove client traffic reaches the proxy
Run the client-side checks in Proxy Connectivity.Confirm the request returns a response and a matching access-log entry appears.If the request succeeds with no log entry, the client is bypassing SafeSquid. Treat that as a failure.
5
Prove HTTPS is inspected
Read the certificate issuer as described in HTTPS Inspection Validation.Confirm the issuer is the SafeSquid CA for inspected destinations, and the original CA for excluded ones.If HTTPS fails with trust warnings, finish Root CA deployment before production inspection.
6
Prove the audit trail
Confirm logs, retention, forwarding, and reports in Logging and Reporting.Confirm the evidence path works end to end, not just that the log file exists.If reports are empty while access logs are healthy, the reporting integration is the fault.
Validate production controls
Before routing broad user traffic, confirm these controls are planned or already complete:- SSL inspection is configured and the SafeSquid Root CA is deployed to managed endpoints.
- Authentication integrates with the approved identity source.
- Baseline access policies block malware, high-risk categories, and unauthorized applications.
- Reporting or log export captures access evidence for incident response.
- High availability is planned with Proxy Clustering when uptime requirements demand it.
- Support and rollback owners are documented.
Integration validation before production
Integration validation before production
Use this once controls are configured, to confirm each one is actually enforcing rather than merely enabled.Authentication and identity
- Users authenticate with domain credentials through the configured AD or LDAP integration.
- Usernames, not just IP addresses, appear in
/var/log/safesquid/access/extended.log. - Where group policies are configured, different groups receive demonstrably different policy.
- A blocked category is genuinely blocked from a client.
- Sites are categorized as expected.
- Time-based policies activate and deactivate on schedule, where configured.
- HTTPS sites present the SafeSquid certificate once the CA is deployed.
- An EICAR test file download is blocked, confirming antivirus scanning is live.
- Keyword-based content blocking triggers, where enabled.
- Restricted file types are blocked on upload and download.
- Multiple client devices browse successfully through SafeSquid.
- A documented test case exists for each policy rule.
- Configuration is backed up, including
/usr/local/safesquid/config/. - A failover and restore procedure is written down and has been tested.
Use the EICAR test file rather than live malware. It is an industry-standard, inert string designed for exactly this check and is safe to transmit on a production network.
Capture readiness evidence
Store these artifacts with the deployment record:- Service, listener, and resolver output from Service Health.
- Screenshot or record showing active license state.
- HTTP and HTTPS access-log entries from
/var/log/safesquid/access/extended.log. - Certificate issuer evidence for an inspected and an excluded destination.
- Pilot client proxy configuration.
- The completed integration checklist above, with the tester named.
- Change record with rollback owner.
Troubleshoot failed checks
Escalate to the operations owner if service restart, DNS repair, or activation upload changes production traffic behavior.
Verification is complete
The setup is ready for policy rollout when service state, interface access, activation status, client routing, HTTPS inspection, and log evidence all pass, and every artifact above is attached to the deployment record.Next steps
- Policy Enforcement - enforce the baseline controls in order.
- SSL Inspection - enable HTTPS decryption after CA rollout.
- Access Restriction - enforce category and time-based policies.