Theme

Automatic certificates: the trial against the staging environment failed, TLS handshake timeout ​

Test now on the Automatic certificates tab, or the first issuance after enabling automatic certificates, stops with:

The trial against the staging environment failed: The certificate authority
cannot be reached from this server.
What to do: Allow outbound HTTPS from every node to the certificate authority,
and set HTTPS_PROXY in the service environment when a proxy is required.

and the technical detail reads:

staging trial: provisioning client: performing request:
Get "https://acme-staging-v02.api.letsencrypt.org/directory":
net/http: TLS handshake timeout

The firewall rules are right, outbound HTTPS from the server works, and the status still reads Failing with "Staging trial: Not run yet" and "Last success: Never".

What the message means ​

Before the first production order, and whenever the names, the authority or the key type change, Syncplify Server! runs a full trial issuance against the Let's Encrypt staging environment, so a misconfiguration never consumes production rate limits. The trial talks to acme-staging-v02.api.letsencrypt.org, a different service from the production acme-v02.api.letsencrypt.org that issues the real certificate.

Let's Encrypt takes the staging environment offline for datacenter maintenance, for many hours at a time, while production keeps serving. During such a window a client's TCP connection to staging is accepted but the TLS handshake never completes, which the Go runtime reports as TLS handshake timeout. That is what the message above describes. Nothing on your server, your firewall or your proxy is wrong, and the production environment is fine.

Versions 8.7.0 through 8.9.0 do not tell the two situations apart: a trial that cannot reach staging is reported with the generic remedy about outbound HTTPS, and no production order is sent while the trial fails. Enabling automatic certificates during such a window therefore also stops at the trial, with the same message. No production rate limit is consumed by any of this: the production environment was never contacted.

How to confirm it in a minute ​

  1. Open https://acme-staging-v02.api.letsencrypt.org/directory in a browser, from any network, a phone on mobile data included. When staging is up it shows a short JSON document; during maintenance the page never loads.
  2. Open https://acme-v02.api.letsencrypt.org/directory the same way. It loads: production is up.
  3. Check letsencrypt.status.io for a planned maintenance that lists acme-staging-v02.api.letsencrypt.org.

When the staging URL fails from every network and the production URL loads, this article applies. When the staging URL loads from your desk but not from the server, the server's outbound path is the problem after all, and the remedy in the message stands.

What to do ​

Wait for the end of the maintenance window given on the status page, then run Test now again, or enable automatic certificates and save. The trial passes and the production order follows on its own.

When it cannot wait, open Show advanced settings on the Automatic certificates tab, switch Skip the staging trial before the first production issuance on, enable automatic certificates and save. The order goes straight to production; the self check still runs before the authority is asked to validate, so a host name that does not reach the server stops the order before it counts against any limit. Once the certificate is issued, switch the skip off again and save: this switch is not part of what identifies a certificate, so changing it does not request a new one.

What changes in 8.10.0 ​

Syncplify Server! 8.10.0 asks the production directory when a trial cannot reach staging. When production answers, the trial is skipped for that order, the order goes to production with the self check alone, the status says that the staging environment did not answer instead of blaming the server, and the next order repeats the trial. Test now reports the same, as a condition on the certificate authority's side rather than a failure of the setup. Log event 9069 records it.