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 – Clear Explanation

Executive summary

DirectAdmin’s built-in handling of HTTPS and www redirects can unintentionally cause security warnings and reduced test results, even when a website itself is correctly configured. This is not caused by user error or misconfigured .htaccess files, but by how DirectAdmin applies redirects at server level.

This affects:

• HSTS (HTTP Strict Transport Security)
• Security scanners such as internet.nl
• Canonical URL consistency
• The perceived security posture of a website

What actually happens

When DirectAdmin’s “Force SSL” and/or www redirection options are enabled, visitors often encounter this redirect chain:

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

From a browser’s perspective, these are separate external redirects. Each redirect is a new navigation and a new response.

Why this causes security warnings

The Strict-Transport-Security (HSTS) header tells browsers to always use HTTPS for a specific hostname. However:

• HSTS is only accepted over HTTPS
• HSTS applies per hostname
• The first HTTPS response must include HSTS

In the DirectAdmin redirect chain, the first HTTPS response is often:

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

If this 301 response does not include HSTS, the browser does not learn an HSTS policy for example.com, even if the final destination (https://www.example.com/) includes it.

Why this cannot be fixed in .htaccess

Many users try to fix this by adding security headers in .htaccess, for example:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

However, testing shows that the redirect from https://example.com/ to https://www.example.com/ is handled before .htaccess is processed.

If a redirect is executed before .htaccess, then:

• .htaccess rules are never executed
• Security headers cannot be added there
• Header always set cannot work

This is an execution-order issue, not a configuration mistake.

Why security scanners are correct

Security scanners such as internet.nl test the exact hostname provided by the user. If https://example.com/ responds with an HTTPS redirect that lacks HSTS, the correct conclusion is:

This webserver does not offer an HSTS policy.

This matches real browser behaviour and is not a false positive.

Why this matters beyond test scores

• Browsers do not enforce HTTPS early for the non-www hostname
• Security audits may flag the site as incomplete
• Canonical URL handling becomes less clean
• Managers receive conflicting security reports

A website can be technically correct and still appear insecure due to hosting platform behaviour.

Preferred redirect behaviour

From a browser and security perspective, the technically preferred approach is a single external redirect that enforces HTTPS and the canonical hostname in one step:

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

Multiple redirects are technically valid, but they increase complexity and can cause missing security headers on intermediate responses.

Why this is a DirectAdmin responsibility

Because these redirects are generated at server level and executed before user configuration, site owners cannot fully resolve this themselves. Security headers must be applied at the same level where the redirect is generated.

Conclusion

• DirectAdmin redirects can bypass user security configuration
• HSTS may be missing on HTTPS redirect responses
• Security scanners correctly report this as a problem

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