Fix certificate validation when api_endpoint differs from hostname

[guiand888]

Fixes certificate validation failures in multi-server setups where api_endpoint (FQDN) differs from the detected hostname

Problem

When using FQDNs in inventory (e.g., server1.example.com), k3s HA clusters fail to bootstrap because:

1. First server generates certificate with SANs based on ansible_hostname (e.g., server1)
2. Additional servers try to connect using api_endpoint (e.g., server1.example.com)
3. Certificate validation fails: x509: certificate is valid for server1, not server1.example.com

This occurs when:

• Using FQDNs in inventory files
• api_endpoint resolves to a different name than the detected hostname

Solution

Automatically add --tls-san={{ api_endpoint }} to k3s server arguments when api_endpoint differs from ansible_hostname.

Changes

• roles/k3s_server/defaults/main.yml: Add computed TLS SAN logic
• roles/k3s_server/templates/*.service.j2: Use computed server args

Logic

_computed_tls_sans: "{% if api_endpoint is defined and api_endpoint != ansible_hostname %}--tls-san={{ api_endpoint }}{% endif %}"
_final_server_args: "{{ extra_server_args }} {{ _computed_tls_sans }}"

Testing

Verified with:

• FQDN inventory (server1.example.com → adds --tls-san=server1.example.com)
• Hostname inventory (server1 → no additional SAN needed)
• HA cluster bootstrap now succeeds with certificate validation

[dereknola]

Several things:

1. Please sign your commits to comply with DCO
2. Don't generate the logic in the defaults.yaml, those files are by design very simple defaults. Move logic into the server and agent tasks and assign new variables with set_fact
3. (What makes doing this automatically more difficult) You need to validate that a tls-san flag does not exist in both the server_config_yaml and extra_server_args variables (same for agents) before assuming you can assign it.

Your problem is solved just by setting the tls-san flag yourself to whatever external hostname you setup. This is standard K3s practice and its well documented. That's why there has never been a push to automated this step, as other related user intervention was already required.

[dereknola]

Move the logic out of these files, we specifically want these to be very simple default files.

[guiand888]

Thank you for your feedback and sorry, I had forgotten to push changes.

I moved the TLS SAN logic from defaults to tasks using set_fact.

The code also validates that tls-san doesn't already exist in server_config_yaml / agent_config_yaml and extra_server_args before adding it, to prevent duplicate entries.

[dereknola]

Looks good but I want to separate this new tls-san argument from the existing extra_args. No need to handle injecting the extra_args when we don't have to.

[dereknola]

I will wait on merging #442 till after this PR is merged (no need to make you deal with my merge conflict :)