PBX certificate renewal and expiration

Inventory each TLS service

A PBX can expose separate HTTPS administration, provisioning, SIP TLS and secure WebSocket listeners. They may use different certificate files or terminate on different proxies. List each hostname, port, certificate issuer, renewal owner and consuming service. The certificate name must match the name clients are configured to validate; a valid certificate for the web portal does not automatically cover the SIP hostname.

Keep endpoint time synchronized and test the trust chain on representative phones. Browser acceptance alone does not prove an older embedded trust store accepts the same chain.

Renewal has a deployment step

Use supported automated renewal and monitor its outcome. Let’s Encrypt recommends ACME Renewal Information where supported; certificate lifetimes and profiles are changing, so avoid hard-coding assumptions that every certificate lasts 90 days. A renewed file on disk is not proof that a long-running SIP listener has loaded it.

Plan the appropriate reload or restart for the specific software release. Test whether it affects active calls. Probe the live service afterward for the presented certificate, hostname and chain, then reconnect a test endpoint. Protect private keys and narrowly scope any DNS credentials used for validation.

Alert before users lose registration

Monitor remaining validity of the served certificate from a client-relevant network. Alert on failed renewal jobs and on services that still present the previous certificate. Keep a recovery procedure for broken validation, including out-of-band administration and rollback to a still-valid configuration where available. Do not make disabling certificate verification the permanent fix. After recovery, test HTTPS provisioning, SIP TLS and browser calling separately.