1. Since version 1.57.0: The ‘Force Redirect’ to add or omit www, needs a change to work RFC solid until after security headers.
   Current explanation by DirectAdmin https://www.directadmin.com/features.php?id=2365 (https://www.directadmin.com/features.php?id=2234)
2. The creation algorithm EC384 for Let’s Encrypt created manually, can get renewed after 60-90 days with outdated RSA4096.
   Solution: A reported problem on internet.nl requires automatic renewal without this file from the past: example.com.san_config;
   Note: Field label ‘Key Size (bits)’ could be called ‘Algorithm’.

DirectAdmin HTTPS / www Redirect Issue – Summary

DirectAdmin’s built-in “Force SSL” and www redirect options can unintentionally cause security warnings, even when a website itself is correctly configured. This is not caused by user error or incorrect .htaccess rules, but by how DirectAdmin applies redirects at server level.

What happens

When both HTTPS and www redirection are enabled, visitors often encounter:

http://example.com
→ 301 https://example.com
→ 301 https://www.example.com
→ 200 OK

Each step is a separate external redirect handled before user-level configuration is processed.

Why this causes warnings

HSTS (HTTP Strict Transport Security):

• Is only accepted over HTTPS
• Applies per hostname
• Must be present on the first HTTPS response

If https://example.com redirects to https://www.example.com without including the HSTS header, the browser does not store an HSTS policy for example.com — even if the final destination includes it.

Security scanners (e.g. internet.nl) correctly report this as missing HSTS for that hostname. This matches real browser behaviour and is not a false positive.

Why .htaccess cannot fix this

The redirect is executed before .htaccess is processed.
If .htaccess is not executed, security headers added there cannot apply to the redirect response. This is an execution-order limitation, not a configuration mistake.

Why it matters

• Browsers do not enforce HTTPS early for the non-www hostname
• Security audits flag incomplete HSTS implementation
• Conflicting security reports appear

The technically preferred solution is a single redirect:

http://example.com/path
→ 301 https://www.example.com/path

Because the redirect is generated at server level, this must be resolved within DirectAdmin’s configuration.

Key point:
A website can be correctly configured and still appear insecure if the hosting platform applies redirects before user-level security headers are executed.