Editing Tornedo.tetrain.com Upgrade Plan (section)

== 3.1 URGENT — cert auto-renewal is broken, not just pending (found during Step 0 checks) ==

Three certmonger-tracked certificates expire '''2026-08-07''' (roughly 2 weeks from this check): LDAP (<code><nowiki>dirsrv</nowiki></code>) server cert, <code><nowiki>httpd</nowiki></code> server cert, and the '''KDC's own cert''' (<code><nowiki>/var/kerberos/krb5kdc/kdc.crt</nowiki></code>). All three show <code><nowiki>status: MONITORING</nowiki></code> / <code><nowiki>auto-renew: yes</nowiki></code>, which normally means certmonger will renew them automatically — but all three also carry the same <code><nowiki>ca-error</nowiki></code>:

<pre>
<nowiki>
Error setting up ccache for "host" service on client using default keytab:
Keytab contains no suitable keys for host/ip-172-26-27-51.ap-south-1.compute.internal@.
</nowiki>
</pre>

'''Root cause, confirmed''': this is an AWS EC2 instance. Its live system hostname is the AWS internal DNS name (<code><nowiki>ip-172-26-27-51.ap-south-1.compute.internal</nowiki></code>) — not the FQDN <code><nowiki>tornedo.tetrain.com</nowiki></code> it's actually enrolled under in IPA. <code><nowiki>/etc/krb5.keytab</nowiki></code> only contains keys for <code><nowiki>host/tornedo.tetrain.com</nowiki></code>. certmonger's renewal helper derives the principal it authenticates as from the machine's live hostname, so it's looking for a keytab entry that doesn't exist. '''This means the "auto" in auto-renew will not actually fire''' — left as-is, these three certs expire on schedule and LDAPS/Kerberos-KDC-TLS/HTTPS on this server break.

Most likely cause: a previous reboot let cloud-init reset the hostname back to the AWS default, overwriting whatever had it set correctly before (<code><nowiki>hostnamectl</nowiki></code>/<code><nowiki>/etc/hostname</nowiki></code> reads the AWS name right now).

'''Proposed fix''' (not yet executed, awaiting go-ahead — see chat):

# Set the persistent hostname back to <code><nowiki>tornedo.tetrain.com</nowiki></code> (<code><nowiki>hostnamectl set-hostname tornedo.tetrain.com</nowiki></code>), matching what's already in the keytab and IPA's records — this is a correction of config drift, not a novel change.
# Prevent recurrence: set <code><nowiki>preserve_hostname: true</nowiki></code> in cloud-init's config so a future reboot doesn't silently reset it again (this is almost certainly how it broke in the first place).
# Re-run <code><nowiki>getcert resubmit</nowiki></code> for the three near-expiry request IDs and confirm the <code><nowiki>ca-error</nowiki></code> clears and each shows a new, far-future expiry.
# Re-verify with a fresh <code><nowiki>getcert list</nowiki></code> that all 9 tracked certs (not just these 3) are healthy.

'''RESOLVED.''' Hostname corrected to <code><nowiki>tornedo.tetrain.com</nowiki></code> and locked against cloud-init reset (<code><nowiki>preserve_hostname: true</nowiki></code>). All three certs resubmitted and confirmed: <code><nowiki>status: MONITORING</nowiki></code>, no <code><nowiki>ca-error</nowiki></code>, new expiry '''2028-07-23''' on all three. This item is closed — no further action needed here.