Invalid Secrets Is a Container Problem, Not a Password Rule
A rejected credential may never have reached the gateway. Compare the input container, the authentication stage and the account itself first.
Seeing "invalid secrets" usually produces one conclusion: the VPN dislikes punctuation. That conclusion is usually wrong, because the message often comes from local handling before any gateway has looked at the account. Two designs deliver the same password, a graphical field and a credential file, and they fail in different places. Compare the containers before you simplify a password that was fine all along.
The error comes before the gateway
Local validation, a locked secret store, a missing agent and a malformed credential file all produce failures that a user experiences as one rejection. None of them involve the authentication server. The gateway's own rejection is a distinct event, and it usually arrives with a different message and a different timing. It happens after a tunnel exists and credentials have been transmitted.
So the first question is not which characters are legal but where the attempt stopped. A client that never opened a connection has not been rejected by anyone. Write down the stage you observed, because every later step depends on that classification.
The distinction also changes who fixes it. A container problem belongs to the device and its owner, while an account rejection belongs to whoever runs the authentication backend.
Compare the containers, not the characters
A GUI password field, a keychain entry, a two-line credential file and an automation secret each carry the same value in a different envelope. The envelope has its own rules, and those rules are what usually break. The value is rarely the problem; the transport of the value is. Keep the two ideas apart and the diagnosis gets shorter.
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
The Community OpenVPN 2.6 client options describe that two-line file for auth-user-pass, including the behaviour when the password line is absent: the client prompts instead. That single detail explains a class of "it asks for a password I already supplied" reports. It also tells you that an empty second line is a meaningful state rather than a harmless formatting choice.
Quoting is a separate layer again: quotation marks inside a plain credential file are stored as data, while a shell removes them before the program sees anything. The same character is harmless in one place and structural in the other. A table cannot tell you which container your client used, so read the client's own configuration before you pick a row.
Line breaks are structural too. A file with line-delimited fields cannot carry a value containing a newline, and that is a limitation of the format rather than a judgment about password strength. Use the deployment's supported delivery mechanism instead of trimming the secret to fit an improvised file.
Build the credential file without shell damage
The safest local route keeps the secret out of shell history and out of the process argument list. Read both fields interactively, then write the two lines the client expects. Everything else can stay in a configuration file that is easy to review.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsThe first two commands read the username and then the password without echoing it, the third writes both lines, the fourth restricts the file, and the last starts the client with that file. Note that read -r preserves backslashes, which is exactly the kind of detail that turns a working password into a failing one when omitted.
Avoid building the file with an unquoted variable or a here-document full of shell expansions. Both can transform characters before they reach the file, and the resulting failure looks like a VPN rejection because the password on disk is genuinely different from the password you know. Compare the file's byte length with the expected value if you suspect this, without printing the secret itself. A mismatch of one or two bytes is the signature of a quoting accident.
Read the stage from the first error
Keep the first specific message from one attempt, then classify it. A local validation error, a missing private key, an unavailable secret agent and a gateway authentication failure are four different results with four different owners. Only one of them is about the account.
If the gateway really is rejecting a correctly delivered credential, check the account, the authentication backend and any required challenge with the administrator. A generic authentication failure does not name a forbidden character.
Restore the approved value through the correct mechanism rather than reducing it to letters and digits. The password policy belongs to the operator, and a workaround that quietly defeats it is not a fix. It also hides the real defect from the next person, who will meet the same error with a weaker password and no better idea.