Why UNA behaves badly when HTTPS is half-configured
UNA is a community and social-network platform that leans heavily on absolute URLs. Nearly every module — the timeline, profile avatars, media galleries, chat, and the studio builder — stores and emits full links that begin with the site root you configured during installation. That root is kept in two places: a database option row and a runtime configuration file. When you install over plain HTTP and later add a certificate, the stored root still says http://, so UNA keeps writing insecure links into pages that the browser has already loaded over HTTPS. The result is the padlock breaking, images silently failing, and AJAX calls to the polling and push endpoints getting blocked by the browser's mixed-content policy.
A second class of problems comes from redirect logic. If you add a blanket HTTP-to-HTTPS rule in .htaccess while UNA is also trying to enforce its own scheme internally, or while the stored root disagrees with what the server reports, you can create an infinite redirect loop. On the Hostiso stack this is amplified by how LiteSpeed and the CloudLinux environment present connection information to PHP. Requests may pass through an internal layer that terminates TLS, so PHP sometimes sees $_SERVER['HTTPS'] unset or $_SERVER['SERVER_PORT'] as 80 even though the visitor arrived on 443. UNA then thinks the request is insecure, rebuilds an http:// URL, and bounces the browser back into your redirect rule, which sends it to HTTPS again — a loop that ends in an ERR_TOO_MANY_REDIRECTS error.
Understanding this ordering matters before you touch anything. The correct sequence is always: issue and verify the certificate first, then update UNA's stored site URI to the HTTPS form, then add a single clean redirect, and finally clear caches so old absolute links are regenerated. Doing these steps out of order is the most common reason a UNA site ends up in a broken half-secure state.
Issuing and verifying the Let's Encrypt certificate
Everything downstream depends on a valid certificate being live for the exact hostname UNA uses. On Hostiso, both control panels provision free Let's Encrypt certificates through the account UI, so no root access or command line is needed.
In cPanel Jupiter, open Security → SSL/TLS Status. You will see every domain, subdomain, and alias on the account with its current coverage. Select the domain that hosts UNA (and the www variant if you serve it), then click Run AutoSSL. AutoSSL validates domain control over HTTP and installs the certificate within a few minutes. Refresh the page and confirm the entry shows a green lock and a future expiry date.
In DirectAdmin Evolution, go to Account Manager → SSL Certificates, choose the UNA domain from the selector, and pick Get automatic certificate from ACME provider (Let's Encrypt). Tick both the root domain and www entries, leave the key size at the default, and save. DirectAdmin also exposes a Force SSL with https redirect checkbox on this same screen; leave it unticked for now so you can control redirects explicitly through UNA and .htaccess instead of stacking two redirect sources.
Before editing UNA, confirm the certificate actually answers on 443. Load https://yourdomain.tld directly in a browser. If you get a certificate warning, the issuance has not propagated or the domain document root is wrong — resolve that first. A live green padlock on the raw domain is the signal to proceed. If AutoSSL fails to validate, the usual cause is a pre-existing redirect in .htaccess that intercepts the /.well-known/acme-challenge/ path; temporarily remove any custom redirect rules, re-run AutoSSL, and re-add them afterward.
Correcting UNA's stored site URI and proxy awareness
With the certificate live, update the two places UNA records its root. Open the File Manager in cPanel (or DirectAdmin's file editor) and navigate to your UNA document root, typically /home/USERNAME/public_html/ or a subfolder like public_html/una/. Edit inc/header.inc.php and locate the site URI definitions. Change the values so they use the secure scheme:
define('BX_DOL_URL_ROOT', 'https://yourdomain.tld/');
define('BX_DOL_URL_STUDIO', 'https://yourdomain.tld/studio/');The database holds a matching value. Open phpMyAdmin from the control panel, select the UNA database, and run this scoped update against the options table (the prefix is usually bx_):
UPDATE bx_options SET value = 'https://yourdomain.tld/'
WHERE name = 'sys_site_url';Some builds also store a separate studio or storage URL; search the same table for any row whose value begins with http://yourdomain.tld and update each to https://. Keep the trailing slash exactly as UNA expects it.
Now address the proxy-awareness problem so PHP recognises secure requests. Because LiteSpeed may terminate TLS ahead of PHP, you can normalise the environment through a .user.ini file or, more reliably for UNA, a small prepend that forces the HTTPS flag when the forwarded header indicates TLS. Create or edit .user.ini in the document root only if you need to raise limits — it does not set request variables. For the scheme, add this near the top of inc/header.inc.php, before the URL constants:
if (
(!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
|| (!empty($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] == 'on')
) {
$_SERVER['HTTPS'] = 'on';
$_SERVER['SERVER_PORT'] = 443;
}This guarantees UNA treats forwarded TLS requests as secure and stops it from rebuilding http:// links that would otherwise trigger a loop. Confirm your account is running a supported interpreter under MultiPHP Manager (cPanel) or the PHP Selector (DirectAdmin/CloudLinux) — UNA needs PHP 7.4 or newer, and mismatched versions can suppress the error messages you would otherwise see in the local error_log.
Forcing HTTPS cleanly and clearing mixed content
With the stored URI corrected and proxy detection in place, add exactly one canonical redirect. Edit .htaccess in the UNA document root and place this block above UNA's own rewrite rules (above the RewriteEngine On line that UNA ships, or immediately after it but before its route rules):
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteCond %{HTTP_HOST} ^(www\.)?yourdomain\.tld$ [NC]
RewriteRule ^ https://yourdomain.tld%{REQUEST_URI} [L,R=301]Using the X-Forwarded-Proto condition alongside %{HTTPS} prevents the loop that a naive RewriteCond %{HTTPS} off rule causes on a TLS-terminating stack. Do not enable DirectAdmin's Force SSL checkbox at the same time, and do not add a second redirect in a parent-directory .htaccess — competing rules are the top cause of loops here.
Old absolute links baked into cached pages will still be insecure until UNA regenerates them. Sign into the UNA Studio at https://yourdomain.tld/studio/, then open Dashboard → Tools and clear the cache; the button flushes template, block, and object caches so pages rebuild using the new HTTPS root. If Studio is unreachable, delete the contents of the cache/ and cache_public/ folders through File Manager, leaving the folders themselves intact.
Finally, hunt for stubborn mixed content. Open the affected page, launch the browser developer console, and read the Mixed Content warnings — each names the exact insecure asset. Common sources are hardcoded image URLs in profile or page HTML blocks, embedded third-party widgets, and email templates. Fix in-database references with a targeted query, for example replacing insecure media links across a content table:
UPDATE bx_posts_data
SET content = REPLACE(content, 'http://yourdomain.tld', 'https://yourdomain.tld')
WHERE content LIKE '%http://yourdomain.tld%';Always export a database backup from phpMyAdmin before running a REPLACE query, and scope it to one table at a time. After clearing caches and correcting references, reload with a hard refresh; the padlock should stay closed and the timeline, chat polling, and avatar delivery should all resolve over HTTPS. If any endpoint still fails, check the local error_log in the document root for the exact URL UNA attempted, which points directly at the remaining insecure constant or stored value.