Symptom

Kraken nightly architectural scan flagged asymmetric startup error semantics: the server could start with hostname 'unknown' silently (no log warning), while a missing TLS password file crashed the process with misleading messages saying “using legacy password” in all three error paths even though no legacy fallback exists. The readPfxPassword() catch block also re-wrapped an IllegalArgumentException in another IllegalArgumentException with a less specific message, making it impossible to distinguish “file missing” from “file empty” in logs.

Root cause

ServerIdentity.resolveHostName() exhausts five resolution strategies and silently returns "unknown" when all fail — no warning log, so operators have no signal that hostname resolution failed. KtorConfig.readPfxPassword() was written with placeholder log messages that referred to a legacy password fallback that was removed during a refactor, and its catch block swallowed the specific IllegalArgumentException thrown for the empty-file case and replaced it with a generic one, collapsing two distinct failure modes into one indistinguishable message.

Fix

• ServerIdentity.kt: added private val logger and emitted a logger.w on every code path that returns "unknown", naming the problem and directing the operator to check network/hostname configuration.
• KtorConfig.kt: restructured readPfxPassword() to use early-return guard clauses — missing file, read error, and empty file are three separate branches each with a distinct exception message that includes the file path. Removed the redundant catch/rethrow pattern. Changed visibility to internal and added a File default parameter so jvmTest can supply a temp-file seam without touching any production call site.
• Added KtorConfigPasswordTest with five cases covering missing file, empty file, whitespace-only content, valid content, and assertion that missing vs. empty produce distinct messages.

Prevention

• Log a warning (at minimum) whenever a resolution or lookup silently degrades to a fallback value — “silent default” patterns hide misconfiguration in production.
• When a function can fail for multiple reasons, each reason should produce a distinct, path-bearing error message; collapsing them into a single generic string makes log-driven diagnosis much harder.
• When a private function reads from a hard-coded production path, add a File/path default-param seam so it can be exercised in tests without touching the real filesystem.