Use Deep SSL Audit to inspect the TLS connection to your billing site’s configured public address. It reports the negotiated protocol and cipher, certificate details, hostname match, expiry and trust checks.

Open the audit

1. Open PD Modules → Guard → Deep SSL Audit with Pro access active.
2. Check the hostname displayed in the result. The audit prefers the configured public system address and uses its explicit port when one is set; otherwise it uses the usual HTTPS port.
3. Read each Check, Status and Detail, then the Issued to, Issued by, Valid, Cipher and SANs details that are available.

Opening this tab performs live connections from your billing server. It is not a saved certificate history or a renewal action. If your public hostname ends at a CDN or load balancer, the result concerns the endpoint reached from this server, which can differ from an origin-only certificate or another client’s route.

Read the findings separately

1. Expiry: review the validity dates and days remaining. An approaching expiry needs attention even while a connection still works.
2. Hostname: check that the certificate covers the displayed host. A certificate for another name is not made suitable by having a recognised issuer.
3. Trust: the audit makes a separate verified connection using this server’s certificate trust store. A failure needs investigation; it is not by itself proof that every browser will show the same result.
4. Chain: the result shows how many certificates the endpoint supplied. Read a missing-intermediate warning together with the trust result rather than treating chain length as a complete validation.
5. Protocol and Cipher: these describe the connection that was negotiated. They are not an exhaustive test of every protocol and cipher the endpoint might accept.

The Healthy, Review or Action needed headline summarises these checks. Even a healthy result is a point-in-time inspection of this endpoint, not proof of every client’s trust behaviour or the absence of other security issues.

If the audit cannot connect

Could not connect can mean the billing server cannot reach its own public address, including some NAT or load-balancer arrangements. Do not treat that message as proof of a public outage or failed certificate renewal. Check the displayed host and have the administrator responsible for the hosting network and certificate investigate the route and certificate configuration.

After an intended certificate or network change, revisit the tab for a fresh audit. Do not send private keys or change certificate-verification settings to hide a finding.

See the PD Guard Blesta guide for related tasks, or explore PD Guard.