[pauldiee]

Closes #8.

Why

/sbin/generate-certificates builds the certificate CN from the host's own configured hostname, not from the FQDN in the host list. A freshly imaged host that still calls itself localhost.localdomain therefore keeps minting localhost.localdomain certificates no matter how often it is regenerated — and each attempt costs a reboot.

The script already refused to waste that reboot, but it stopped there and left the operator to go fix the hostname by hand and re-run:

  CN does not match hostname. Regeneration needed.
  ESXi hostname 'localhost' does not match expected FQDN 'testhost.localdomain.local'.
  Certificate regeneration skipped: fix the ESXi hostname first or
  the regenerated certificate will still have the wrong CN.

What changed

New Repair-ESXiHostname. On a mismatch the script now offers to correct it:

  ESXi hostname 'localhost.localdomain' does not match expected FQDN 'esxi01.vcf.lab'.
  Fix the hostname on esxi01.vcf.lab so the certificate CN will match? [Y/N]: y
    Setting hostname : esxi01
    Setting domain   : vcf.lab
  Hostname updated to 'esxi01.vcf.lab'. Proceeding with certificate regeneration.

• Y — sets hostname and domain from the host list via Set-VMHostNetwork, reads them back from the host to confirm the change stuck, then continues into regeneration. Regen reboots the host anyway, so the rename needs no reboot of its own.
• N — previous behaviour: regen skipped, host flagged CN mismatch in the report.

Hosts are never renamed silently — hence the prompt, matching the -WipeDisk idiom. -DryRun reports the offer and changes nothing.

Also handled: a short name in the host list (no domain to derive) is refused rather than guessed at, and a rename that throws or silently fails to apply skips regeneration instead of rebooting into the same wrong CN.

Testing

Not yet run end-to-end against a live host — the guard that motivated it was hit on a live host, but the fix path has not been.

Repair-ESXiHostname was exercised in isolation with PowerCLI mocked:

Case	Regen proceeds?	Set-VMHostNetwork called with
Declines (N)	no	not called
Accepts (y)	yes	esxi01 / vcf.lab
Accepts, deep subdomain	yes	esxi01 / mgmt.vcf.lab
Short name, no domain	no	not called
Accepts, but change silently does not stick	no	called; read-back catches it
Set-VMHostNetwork throws	no	called; error caught

Note on versioning

Branched off main, so this is v4.4.0 and assumes #7 (v4.3.0) merges first. If #7 is merged, I can rebase this to keep the changelog linear.

🤖 Generated with Claude Code