Security Settings

The Force HTTPS setting under Site Settings → Security ensures every visitor lands on an HTTPS URL. If they hit the HTTP version of your site, they're 301-redirected to HTTPS automatically and the redirect is permanent (browsers cache it).

For any production deployment in 2025, this should always be on. Modern browsers warn users about HTTP-served sites, search engines downrank them, and many platform features (Service Workers, push notifications, the Geolocation field, camera access for the Screen/Media Recorder field) require HTTPS at the browser level.

What it does

The platform reads the request scheme (HTTP vs HTTPS) on every page load. If it's HTTP and Force HTTPS is on, the response is a 301 Moved Permanently to the same URL on HTTPS. The redirect happens before any application logic runs, so it's fast and consistent across every page on the site.

Sessions and cookies are preserved through the redirect — the user's existing session continues seamlessly on the HTTPS side. New cookies are flagged Secure (so they only travel over HTTPS) and HttpOnly (so JavaScript can't access them), which prevents a whole class of cookie-theft attacks.

What it requires

The platform doesn't issue or manage TLS certificates itself — that's a deployment concern. You need:

• A valid TLS certificate installed at the web-server level (Apache, Nginx) or at the load balancer / CDN level (AWS ALB, CloudFront, Cloudflare).
• DNS pointing your domain at the host serving HTTPS.
• The certificate's hostname matching your site's hostname (no wildcard mismatches).

Common ways to get a certificate, in order of typical preference: a free Let's Encrypt cert managed by Certbot, a managed certificate from AWS Certificate Manager (free for traffic going through ALB or CloudFront), a paid wildcard certificate from a vendor like DigiCert (for organisations with strict policies).

Mixed-content gotcha

One common pitfall: after enabling Force HTTPS, pages might still reference HTTP-only resources (images, scripts, fonts) hard-coded in your templates or content. Modern browsers block these as "mixed content" — the page loads but the resources don't.

Three places to check after enabling:

• Image URLs in articles and email templates — use the browser's developer-tools network tab to spot HTTP requests.
• Hard-coded URLs in custom JavaScript — search your custom code for http://.
• External resources you embed — Google Fonts, third-party widgets, embedded videos. Update to HTTPS variants if they exist.

Tip: Use protocol-relative URLs (e.g. //example.com/image.png instead of http://example.com/image.png) for resources you reference from both HTTP and HTTPS contexts. Browsers fetch them via whichever protocol the parent page is using.

HSTS — going one step further

For maximum security, pair Force HTTPS with HTTP Strict Transport Security (HSTS) — an HTTP header that tells browsers to never connect over HTTP for this domain, even if the user types http://. HSTS is configured at the web server / load balancer level rather than inside ActiveManage; once set up the browser caches the directive and the only requests that ever go out are HTTPS.

For fields you mark as Encrypt at field-config time, and for some of the platform's own internal storage of sensitive data (API tokens, third-party credentials), ActiveManage uses a configurable encryption engine. The choice of engine matters because each has different PHP requirements, performance characteristics, and security properties.

The three engine options

Site Settings → Security → Encryption Engine picks among:

openssl

Requires the openssl PHP extension (almost always available). Industry-standard, well-understood, supports a wide range of cyphers via the additional Encryption Cypher setting. Default for most installs because it's universally available and battle-tested.

sodium

Requires the sodium PHP extension (bundled with PHP 7.2+). Modern alternative with simpler key handling and resistance to common implementation mistakes that have bitten openssl users over the years. If you're on PHP 7.2 or above and don't have a specific reason to use openssl, sodium is the modern recommendation.

mcrypt

Deprecated as of PHP 7.1. Don't use it for new installs. Existing installs on this engine should plan a migration to one of the others before upgrading PHP, because mcrypt is being progressively removed from newer PHP versions.

Encryption Cypher (openssl only)

If you pick openssl, the platform exposes a Cypher setting that picks the underlying algorithm. The defaults are sensible — typically AES-256-CBC or AES-256-GCM — but you can override.

Sensible choices in 2025:

• AES-256-GCM — preferred when available. Authenticated encryption (protects against tampering as well as eavesdropping).
• AES-256-CBC — fine, slightly older but widely supported.
• Anything else — only pick if you have a specific reason. Stay with mainstream algorithms.

Algorithms to avoid: DES, 3DES (too weak), RC4 (broken), any ECB-mode cypher (vulnerable to chosen-plaintext attacks).

Encryption Level (sodium only)

For the sodium engine, the Encryption Level setting picks between four performance/strength trade-offs:

• php_l1 — very fast. Minimal iteration count. Suitable for high-volume environments where the values are not deeply sensitive.
• php_l2 — fast. Moderate iteration count. Sensible default for general use.
• php_l3 — slow. High iteration count. Significantly slower per operation but harder to brute-force. Use for the most sensitive values.
• am — ActiveManage standard (very fast). Platform-tuned default with a good balance.

Three real-world scenarios

Scenario 1: Standard business app on modern PHP

Engine: sodium. Level: am. Suitable for most installs running PHP 7.2 or later. Modern, fast, well-supported.

Scenario 2: Legacy hosting on older PHP

Engine: openssl. Cypher: AES-256-CBC. Works on any PHP version that has the openssl extension (basically all of them since PHP 5).

Scenario 3: High-security regulated app

Engine: sodium. Level: php_l3. Slower but stronger. Combine with longer field-level encrypted columns and audit-mode logging for every read.

Warning: Changing engines after launch requires re-encrypting every Encrypt-flagged value with the new engine. There's no live re-key feature — you'd need a custom migration script that reads each encrypted value, decrypts with the old engine, and re-encrypts with the new. Plan engine choice at install time and stick to it.

When using the sodium engine for ActiveManage's data encryption, the Encryption Level setting trades performance for cryptographic strength. The four options represent different iteration counts in the underlying key-stretching algorithm.

What "iteration count" actually means

Modern symmetric encryption (used by ActiveManage for at-rest encryption of fields you mark Encrypt) uses a key derived from your master key plus per-record randomness. The derivation algorithm runs through many rounds of hashing — "iterations". More iterations means each encrypt or decrypt operation takes longer, but it also means a brute-force attacker has to do more work per guess.

The trade-off: every legitimate read takes slightly longer, but every illegitimate brute-force attempt also takes longer. Picking the right level depends on how concerned you are about the brute-force angle versus how much per-request latency you can afford.

The four levels in detail

php_l1 (very fast)

Minimal iteration count. Each encrypt/decrypt is essentially as fast as the underlying cypher allows — typically microseconds. Suitable for:

• High-volume environments where the values are not deeply sensitive (e.g. short-lived API tokens).
• Encryption purely for hygiene rather than against a determined adversary.
• Systems where the encrypted value is also protected by other means (e.g. it lives in a database that's already on a private network behind a firewall).

php_l2 (fast)

Moderate iteration count. Slight slowdown over l1. Reasonable balance — strengthens against the most casual brute-force without significantly affecting throughput. Sensible default for general business use.

php_l3 (slow)

High iteration count. Noticeably slower per operation — operations that took microseconds on l1 take milliseconds on l3. Reserve for the most sensitive data:

• Long-lived credentials that an attacker might genuinely target.
• Archival data where read frequency is low so the latency doesn't matter.
• Highly-regulated environments (healthcare, finance, government) where the audit trail will be examined.

am (ActiveManage standard, very fast)

The platform's own tuned default. Carefully chosen to give reasonable security without significantly affecting throughput. Recommended starting point for most installs — close to l1 performance but with slightly better security properties.

Real-world numbers

The actual time per operation depends on your hardware. To give a rough sense:

• php_l1 / am: 0.1–0.5 milliseconds per encrypt/decrypt on modern server hardware.
• php_l2: 1–5 milliseconds.
• php_l3: 10–50 milliseconds.

For most apps the difference is invisible. For high-throughput APIs handling thousands of requests per second, the difference adds up — a path that encrypts and decrypts five fields per request at php_l3 would add 50–250ms per request, which is significant.

Pick per use case

If you have multiple kinds of sensitive data, set the level globally to your most common case. Then handle exceptions in code:

• Highly-sensitive fields can be configured individually with stronger algorithms via Custom PHP Code rather than relying on the platform default.
• Cheap fields can skip encryption entirely if they're not actually sensitive.

Note: Don't pick the highest level just because it sounds safer. Higher iteration counts trade real per-request latency for protection against a brute-force attacker who's already managed to exfiltrate your encrypted data. If your real threat model is data theft via something other than brute-force (insider threat, credential compromise, etc.) higher iteration counts don't help — focus on access controls and audit logs instead.