Automatic certificates: "During secondary validation: Timeout during connect"

Test now on the Automatic certificates tab, or an order after enabling automatic certificates, stops with a message like this one (the address is your public address):

The trial against the staging environment failed: The certificate authority
could not connect to port 443 for one of the names: During secondary
validation: 203.0.113.10: Timeout during connect (likely firewall problem)
What to do: Open port 443 from the Internet to every node a name resolves to,
and check the IPv6 record if the name has one. The production rate limits
were not touched.

and the technical detail reads:

staging trial: solving challenge: www.example.com: [www.example.com]
authorization failed: HTTP 400 urn:ietf:params:acme:error:connection -
During secondary validation: 203.0.113.10: Timeout during connect
(likely firewall problem)

The readiness check passed, the self check passed, and port 443 is open on the firewall. The "What to do" line of versions up to 8.9.0 is wrong for this case; 8.10.0 says what follows.

What the message means

Let's Encrypt validates a name twice over. Its primary datacenter connects to the name on port 443 first; when that validation fails, the error says so plainly. Only when the primary validation passed does Let's Encrypt repeat it from its remote vantage points, in other countries and cloud regions, and a failure there is reported with the prefix During secondary validation. So the prefix is good news about your setup: the name resolves to the right address, port 443 lands on Syncplify Server!, and the validation certificate was served correctly to at least one place.

What failed is reachability from some of those remote vantage points. Timeout during connect means the connection attempt was never answered, not refused: something between that vantage point and the server dropped it. On a server whose port forward works, that is a rule that does not apply to every source: a country (geo IP) policy on the inbound rule, an IP reputation or threat intelligence feed, a block list of cloud provider ranges, or a filtering service upstream of the firewall.

The numbers matter. Let's Encrypt has validated from four remote vantage points since March 2024 and from six since late October 2026 (staging since October 27, production from November 10), to meet the CA/Browser Forum requirement of at least five remote perspectives across two regional Internet registries by December 15, 2026. A quorum of them must agree with the primary: with six, at most two may fail. Their addresses are not published and change over time, so an allow list of sources can never be kept right. Let's Encrypt's own guidance for the TLS-ALPN-01 method, the one Syncplify Server! uses, is to allow port 443 from everywhere.

Syncplify Server!'s readiness check and self check cannot see this, because they run from the cluster itself, through your own connection or through the NAT hairpin, which the rule lets through. The only signal is the authority's prefix.

How to confirm it in a minute

1. Run a TCP port check on port 443 against your public address from a service that tests from many countries at once (check-host.net has one, as do others). The locations that time out are the ones the rule drops. A check from the United States alone proves nothing: Let's Encrypt's primary datacenter and two of its vantage points are in the United States, and those usually get through.
2. Open the firewall's deny or drop log for destination port 443 at your public address at the time of Test now. The remote attempts start within a second of the primary validation and give up ten seconds later, so the window is small and easy to find.
3. If the log shows nothing, capture on the outside interface of the firewall, before the policy is applied, during a Test now. Connection attempts that arrive there and never reach the server were dropped by the firewall; attempts that never arrive at all were dropped upstream, and your provider's filtering is the next place to look.

What to do

Allow TCP port 443 to the server from any source, with no country, reputation or provider condition on that rule. The traffic the rule admits is small: during a validation, Syncplify Server! answers the validation protocol for the pending name, and a listener on 443 serves what it already served. Then run Test now; when it passes, save with automatic certificates enabled.

If your security policy does not allow port 443 to be open worldwide, automatic certificates through TLS-ALPN-01 are not available for that name, and the certificate you install by hand keeps serving as before. Syncplify Server! does not use the DNS method of validation.

Do not switch on Skip the staging trial before the first production issuance to get around this: the production environment validates from the same vantage points (six from November 10, 2026), the order would fail the same way, and a failed production validation counts toward Let's Encrypt's limit of five failed validations per name per hour. The staging trial exists so that this failure costs nothing.

What changes in 8.10.0

Syncplify Server! 8.10.0 reads the authority's prefix and says so: "The certificate authority's primary datacenter validated the name, but its remote vantage points could not", with a remedy that points at country, cloud provider and IP reputation rules instead of the port forward. The "How this works" panel on the tab gains the same requirement, and so does the manual.