AutoSSL renews the domain certificate but not the copy used by hostname/server services (hostname.crt) → panel, mail and default vhost expire
Environment
- CWPpro, cwpsrv 1.30.6, cwp-httpd 2.4.69, AlmaLinux 8.10
- Server hostname: mail.example.com (example.com is also a hosted domain on the same server)
Steps to reproduce
1. Issue a Let's Encrypt certificate for example.com via AutoSSL with the "mail" SAN
(SAN list: example.com, www.example.com, mail.example.com).
2. Install it for the server services via SSL Certificates → "SSL for server services"
(CWP, Apache/WebServers, Dovecot, Postfix, Hostname). CWP copies it to
/etc/pki/tls/certs/hostname.crt, /etc/pki/tls/certs/hostname.bundle and
/etc/pki/tls/private/hostname.key.
3. Wait for AutoSSL to renew example.com (cron alertandautorenewssl.php / acme.sh).
Expected
AutoSSL renewal also refreshes the hostname.* copies (or the server services reference the
domain's cert files directly), so https://mail.example.com:2031, :2083, IMAP/SMTP TLS and the
default 443 vhost keep a valid certificate.
Actual
- /etc/pki/tls/certs/example.com.cert and .bundle are renewed (new expiry +90 days).
- /etc/pki/tls/certs/hostname.crt / hostname.bundle / hostname.key are left untouched and
expire. Browsers warn on :2031 and :2083, mail clients warn on 993/465, and any subdomain
without its own vhost (e.g. mail.otherdomain.com → default server) gets the expired cert.
- Nothing in /var/log/cwp/autossl*.log mentions the hostname copy after the renewal.
- The "Admin services" dialog on the SSL Certificates page only offers webmail/ftp/cpanel
SAN subdomains, so there is no place to tell CWP "keep server services bound to this
domain's certificate".
- This is the same behaviour reported in 2017
(forum.centos-webpanel.com/ssl/cwp-hostname-certificate-not-renewed/) and never fixed.
- Likely trigger: the hostname certificate and the domain certificate share the same acme.sh
folder (www.example.com_ecc). Re-issuing the domain certificate from the SSL Certificates
page overwrote it; afterwards the acme cron renews only the domain copy, never hostname.*.
Side effect worth noting
If an admin manually copies hostname.crt and hostname.key but not hostname.bundle, Apache fails
on the next graceful reload with:
AH02565: Certificate and private key mail.example.com:443:0 from
/etc/pki/tls/certs/hostname.bundle and /etc/pki/tls/private/hostname.key do not match
and all sites go down. A single "re-apply to server services" step inside the renewal would
avoid both the expiry and this foot-gun.
Suggested fix
Record which domain certificate is bound to the server services (e.g. in vhosts-ssl.json)
and, after every successful AutoSSL renewal of that domain, re-run the "SSL for server
services" install and reload cwpsrv/httpd/nginx/dovecot/postfix.
CWPpro 1.30.4 (stable), cwpsrv package 1.30.6, cwp-httpd 2.4.69, AlmaLinux 8.10
Workaround we applied (manual, until CWP handles it)
1. Renewed example.com normally through AutoSSL (SSL Certificates → Renew Now).
2. Re-applied that certificate to the server services, i.e. the same thing CWP does on
"SSL for server services": copy example.com.cert → hostname.crt, example.com.key →
hostname.key and example.com.bundle → hostname.bundle (all three files, mode 600),
then run /scripts/hostname_ssl_restart_services and reload nginx.
3. Added an external monitor that warns 14 days before hostname.bundle expires, because
CWP's own expiry alerts only cover domain certificates, not the hostname copy.
Caveat for other admins: copy all three files together. Copying only crt+key leaves the old
bundle in place; Apache then fails on the next graceful reload (AH02565 cert/key mismatch)
and every site on the server goes down until the bundle is replaced and httpd restarted.
Do not use /scripts/generate_hostname_ssl for this — it creates a self-signed certificate.