root/ubuntu-post-install
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

asterisk: regenerate self-signed TLS cert when DOMAIN_NAME changes

Browse Source 
Vendor's entrypoint.sh only regenerates the self-signed cert if the file
is missing or lacks a SAN extension -- it never checks whether the SAN
actually matches the currently configured DOMAIN_NAME. Since
/etc/asterisk/certs is a bind-mounted host directory, neither an update
nor a full reinstall ever wipes it, so a domain entered once (even a
placeholder, or one later changed) sticks in the cert indefinitely.

Confirmed live: a box kept presenting a cert for a stale, originally-
entered domain long after DOMAIN_NAME had changed and a full reinstall
had run in between. Most SIP/TLS clients refuse a mismatched cert
outright with no clear error, which was the actual cause of a
"port's open but registration still fails" case -- firewall, coturn, and
DNS had all already checked out clean.

Patches the vendored entrypoint.sh (same guarded-sed pattern as the
existing logger.conf patch) to also regenerate when the existing cert's
SAN doesn't include the current DOMAIN_NAME. Verified against a scratch
copy: missing cert regenerates, a cert already matching the domain is
left alone, a mismatched domain now correctly regenerates and then
stabilizes.
This commit is contained in:
Claude
2026-08-12 21:33:24 +00:00
parent 893ab19759
commit b76230b341
1 changed files with 24 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
services/asterisk.sh
+24
View File
@@ -385,6 +385,30 @@ _asterisk_refresh_vendor_files() {
else
log_warning "entrypoint.sh logger.conf template changed upstream — security events won't be logged to a file. Update the sed patch in this installer."
fi
# Regenerate the self-signed TLS cert when it doesn't match the current
# DOMAIN_NAME. Vendor's own check only asks "does the file exist" and
# "does it have a SAN extension" -- never "does the SAN match the domain
# actually configured now" -- so a domain entered once (even a
# placeholder, or one later changed) sticks in the cert FOREVER: it
# survives every subsequent update *and* full reinstall, because
# /etc/asterisk/certs is a bind-mounted host directory neither install
# mode ever wipes (the same reason pjsip.conf/devices survive reinstalls
# too). Confirmed live: a box's TLS transport kept presenting a cert for
# a stale, originally-entered domain long after DOMAIN_NAME had changed
# and a full reinstall had been run in between -- most SIP/TLS clients
# refuse a cert like that outright with no clear error, and this was the
# actual cause of a "port's open but registration still fails" case that
# every other check (firewall, coturn, DNS) had already come back clean.
if grep -q '^if \$regen_cert; then$' ./docker/entrypoint.sh; then
sed -i '/^if \$regen_cert; then$/i\
if [[ "$regen_cert" != true && -n "${DOMAIN_NAME:-}" ]] && ! openssl x509 -in /etc/asterisk/certs/server.crt -noout -ext subjectAltName 2>/dev/null | grep -q "DNS:${DOMAIN_NAME}"; then\
log_info "Existing TLS cert does not match current DOMAIN_NAME (${DOMAIN_NAME}) -- regenerating"\
regen_cert=true\
fi' ./docker/entrypoint.sh
else
log_warning "entrypoint.sh cert-regen check changed upstream — a stale-domain cert won't auto-regenerate. Update the sed patch in this installer."
fi
}
# ── Shared: log rotation for logs/full (unbounded otherwise) ──────────────