Use an authorized server administrator and verify the server fully qualified hostname, DNS, current certificate and service assignments. Keep console recovery access and a working administrative session. Confirm the configured ACME provider and challenge prerequisites.

1. Inspect the documented server-hostname ACME configuration for the installed DirectAdmin release. Check the hostname resolution and any CAA restrictions before requesting a certificate.
2. Use the supported hostname certificate workflow. Where the documented administrative command applies, /usr/local/directadmin/scripts/letsencrypt.sh server_cert requests the server certificate using the configured settings.
3. Read the complete issuance result and inspect the certificate name and chain. Do not copy a customer private key into unrelated service files to bypass a failed request.
4. Confirm the supported synchronization of the server certificate to services configured to use it. Review service reload results and keep unrelated domain-specific certificates intact.
5. Test new panel and mail TLS connections using their documented hostnames and ports. Verify renewal monitoring and the next automatic renewal status.

From a trusted workstation with OpenSSL, check the actual DirectAdmin endpoint. Replace server.example.com and port 2222 if your service uses different values. This tests the hostname certificate presented by that port without supplying a panel password.

openssl s_client -connect server.example.com:2222 \
  -servername server.example.com -verify_hostname server.example.com \
  -verify_return_error </dev/null

Read the result: Read any chain, validity or hostname-verification error. A correct certificate for a customer website on port 443 does not prove that the management service on port 2222 serves the same certificate. A proxy or alternate endpoint can also present a different chain.

After using DirectAdmin's supported hostname-certificate workflow, repeat the check against the exact service customers use. Test mail-service hostnames separately where they share or receive a synchronized certificate. Do not export customer private keys or disable certificate verification to conceal a mismatch.

Confirm the management endpoint and intended mail services present a trusted certificate with the correct name. Test a real mail-client connection as well as a browser. Record the renewal owner and a monitored alert path.

If one service presents an older certificate, inspect its configured certificate path and reload behaviour rather than reissuing repeatedly. If clients use a different hostname, supply the correct supported name or configure appropriate coverage. Do not tell users to accept permanent trust exceptions. Keep the prior valid service configuration available for controlled recovery.

• Issuing an automatic TLS certificate in DirectAdmin
• Diagnosing DirectAdmin license and update failures
• Logging in to DirectAdmin securely
• Making persistent per-domain web-server changes in DirectAdmin

• DirectAdmin: Service Ssls And Le
• DirectAdmin: Troubleshooting Letsencrypt

• OpenSSL: TLS connection diagnostics