castris
Verified User
Hi,
DirectAdmin 1.712 (183b67368b137bca2765445f19ece9b2dfc53132), nginx_apache, Let's Encrypt via lego.
Setup
One user, two domains:
What happened
After a successful ACME renewal of example.com (files rewritten, user's nginx.conf and httpd.conf regenerated in the same minute), the HTTPS vhost of example.com was still generated with:
So example.com served the expired certificate stored under example.es (browser: NET::ERR_CERT_DATE_INVALID), even though example.com.cert.combined was valid. The vhost of example.es pointed to the same file.
No custom HTTPD/nginx config for either domain, no pointers, no custom templates involved for this user.
How it was resolved
Requesting an ACME certificate for example.es (letsencrypt.sh request example.es) replaced example.es.cert.combined with a real *.example.es certificate. On that rewrite, DA regenerated the vhost of example.com pointing to example.com.cert.combined. Both domains are fine now.
Questions
Hosting users install certificates manually on the "wrong" domain more often than one would hope, and today this produces a silent outage that survives every successful renewal. Is this expected behaviour, and is there a setting to make each domain always use its own certificate?
Thanks.
DirectAdmin 1.712 (183b67368b137bca2765445f19ece9b2dfc53132), nginx_apache, Let's Encrypt via lego.
Setup
One user, two domains:
- example.com — acme_enabled=yes, renews fine. Its own example.com.cert.combined holds a valid wildcard (*.example.com + example.com).
- example.es — acme_enabled was NOT set. Its example.es.cert.combined held an old, manually installed certificate whose SAN was *.example.com + example.com (not .es). That certificate expired months ago.
What happened
After a successful ACME renewal of example.com (files rewritten, user's nginx.conf and httpd.conf regenerated in the same minute), the HTTPS vhost of example.com was still generated with:
Code:
ssl_certificate /usr/local/directadmin/data/users/USER/domains/example.es.cert.combined;
SSLCertificateFile /usr/local/directadmin/data/users/USER/domains/example.es.cert.combined
So example.com served the expired certificate stored under example.es (browser: NET::ERR_CERT_DATE_INVALID), even though example.com.cert.combined was valid. The vhost of example.es pointed to the same file.
No custom HTTPD/nginx config for either domain, no pointers, no custom templates involved for this user.
How it was resolved
Requesting an ACME certificate for example.es (letsencrypt.sh request example.es) replaced example.es.cert.combined with a real *.example.es certificate. On that rewrite, DA regenerated the vhost of example.com pointing to example.com.cert.combined. Both domains are fine now.
Questions
- How does DA choose which certificate file goes into a domain's vhost? It looks like it picked another domain's certificate because its SAN covered the hostname.
- Should a domain's own valid certificate always win over another domain's certificate that merely covers the same name?
- Should an expired certificate ever be selected when a valid one exists for that hostname?
Hosting users install certificates manually on the "wrong" domain more often than one would hope, and today this produces a silent outage that survives every successful renewal. Is this expected behaviour, and is there a setting to make each domain always use its own certificate?
Thanks.