Automatic certificates

Syncplify Server! can request, install and renew TLS certificates from Let's Encrypt, or from any other certificate authority that speaks the ACME protocol, for every virtual site and for the management console, on every license. The feature is optional and off by default: an installation that keeps handling certificates by hand sees no change, no port is bound, and nothing is ordered until an operator enables it and the readiness check passes.

Where things are configured

What	Where	What the certificate serves
The certificate of a virtual site	Admin UI, Certificates and Keys, tab Automatic certificates (permission Certificates and Keys)	The FTPS, FTPES and HTTPS (WebClient!) listeners of that site, on every node
The certificate of the management console	SuperAdmin UI, Certificates, tab Automatic certificates	The SuperAdmin and Admin web interfaces
The host names of the management console, the responder on port 443 and the allowed certificate authorities	SuperAdmin UI, Global Configuration, section Automatic certificates	The names the console's certificate covers, one responder switch for the whole cluster with a bind address, and the list of custom certificate authorities a site Admin may choose

Protocol bindings are a SuperAdmin matter, while the certificate store of a site belongs to its Admins; that is why the site's automatic certificate lives in the Admin UI and the responder, which concerns every node, lives in Global Configuration.

Which names the certificate covers

The names come from two places, and you only ever type the second:

• The host names of the bindings. A SuperAdmin gives each HTTPS binding of a site a host name in the site's bindings, and sets the host names of the management console in Global Configuration, section Automatic certificates. Every such name is covered by the automatic certificate of its scope without any further configuration. A name added later is picked up on its own: the engine looks again right after the save, notices that the certificate no longer matches the names, and requests a new one. FTPS, FTPES and SFTP bindings carry no host name of their own; FTPS and FTPES present the same certificate as the HTTPS listeners of the site.
• Additional host names. For a virtual site, names that are on no binding, for example an alias clients use, added by the site's Admins on the Automatic certificates tab. At most 100, no wildcards, no IP addresses. The console has no separate list: all of its names live in Global Configuration, and its tab shows them read only with a link there.

A binding host name that cannot go on a certificate (an IP address, a single label such as localhost, a wildcard, or a name reserved for the cluster) is left out rather than failing the whole certificate; the readiness check and the tab say which name was left out and why. A certificate authority accepts at most 100 names in all, and the readiness check blocks enabling when the bindings' names and the additional ones together exceed that.

What the certificate authority needs to reach

The certificate authority proves that you control a name by connecting to it. With the TLS-ALPN-01 method, the only one Syncplify Server! uses, that connection goes to TCP port 443 of every host name the certificate covers, and to no other port. Three things must therefore be true for each name:

1. The name resolves to this server. The public DNS record of the name (A, AAAA, or both) must point at an address where this cluster answers. If the name has an AAAA record, Let's Encrypt tries the IPv6 address first; a stale AAAA record that points somewhere else fails the validation even when the IPv4 address is correct.
2. Port 443 at that address lands on this cluster. Either one of the site's HTTPS or implicit FTPS listeners is bound to port 443 (directly, because your router forwards public port 443 to the listener's port, or because a proxy on the machine passes port 443 through unchanged, see below), or the per node responder is switched on in Global Configuration and port 443 is open to the management service. Most installations listen on 6443, 6444 and 990, and for them the responder is what makes automatic certificates work: it answers the validation on 443 and nothing else has to change. The responder stands down by itself on any node where a listener of this installation already holds port 443.
3. Every node the name resolves to can be reached. Let's Encrypt validates from several vantage points on the Internet, and a name that resolves to more than one address is checked at each of them. In a cluster, open port 443 on every node, or point the name only at the nodes that are reachable.

A non empty allow list on the site does not block the certificate authority: while a validation is pending the decision is deferred to the moment the connection says what it wants, and a validation is let through. Bans still apply.

The readiness check

Nothing can be enabled before a readiness check has run and found nothing blocking, and the server repeats the check when it receives the enabling save, so the rule holds for the API as well as for the consoles. The check inspects, on every node, who holds port 443 (one of this installation's listeners, nothing, another program named with its process id, or a port the service may not bind), whether the responder is on, the DNS records of every name and whether they point at a node, a probe of every name on port 443 from every node, the certificate authority directory, and the state of the cluster.

Blocking items keep automatic certificates off until they are fixed: a name that does not resolve, a node that must answer and has no path to port 443, a port held by another program (unless the check's own probe got through that program to this installation, see the next section), an IPv6 record with no IPv6 path, a device in front of the server that terminates TLS, an authority that cannot be read, an offline node that hosts the site, a cluster node that runs an older version. Warnings do not block: a name whose address is not one of the nodes (normal behind a NAT or a load balancer, and impossible to confirm from inside), a probe that could not reach the address from inside the cluster (normal behind a NAT without hairpin), a listener that expects the PROXY protocol header.

On Windows, port 443 is often held by System (PID 4), which is HTTP.sys: IIS, WinRM over HTTPS, and other Windows web services sit behind it. Either move that service to another port, split the machine by IP address, or forward public port 443 to one of the site's HTTPS or implicit FTPS listeners; the IIS and HTTP.sys section explains each.

The check ends with one sentence that says exactly where port 443 will be used, and the first enable asks you to acknowledge it. Once automatic certificates are enabled the readiness panel steps aside and the status takes over; Check readiness on the status runs the same check at any time, for example to see where a validation would land after a change on the network. A scope gets at most one check every two minutes.

The responder on port 443

The responder is a small listener inside the management service, on every node, that exists only while a validation is pending and closes half a minute after the last one. It answers only the validation protocol (acme-tls/1) for names it holds a pending validation for; every other connection is closed at once. It is switched on in Global Configuration, off by default, and it stands down on its own on a node where a listener of this installation holds port 443. Each node reports its standing on the Certificates pages and on the Dashboard: answering, standing down, port held by another program (named), permission denied, switched off.

On Linux the services run as root by default and bind port 443 without further ado; an installation that runs the management service under a dedicated account must grant it CAP_NET_BIND_SERVICE, and a container must allow the capability. On Windows the firewall rules the installer creates are per program and already cover the management service.

A proxy that already holds port 443

On a machine where a reverse proxy or a web server already owns port 443, there are two honest ways forward: free the port (or forward public port 443 elsewhere, as above), or make that program pass port 443 through unchanged to the console or to the site's HTTPS listener. Unchanged means TCP mode, without terminating TLS: the certificate authority must reach Syncplify Server!'s own TLS handshake, because the validation is answered inside it. A proxy that terminates TLS can never pass a TLS-ALPN-01 validation, and the readiness check reports it as "answered by something that is not this server's validation responder".

With a pass through in place the readiness check sees port 443 as held, runs its probe through it, and, when the probe is answered by this installation, reports the holder as a warning instead of blocking: "Port 443 on node X is held by caddy (PID 1234), which passes validations through to this installation." Keep the responder switched off in that case; it could not bind the port on that node anyway, and switched on it would report the failed bind at every validation. The responder is one switch for the whole cluster, so a cluster that mixes proxied nodes with nodes that need the responder lives with those reports on the proxied nodes. A name whose AAAA record points at the node must get through over IPv6 as well; the check says so when it does not.

Have the proxy send the PROXY protocol header and switch Behind HAProxy on for the binding it feeds, so the Shield, the allow lists and the logs see the real client address rather than the proxy's; the two settings must agree, or every connection fails. The Web servers in front of automatic certificates page has the recipes: Caddy with the layer4 plugin, nginx with its stream module, HAProxy in TCP mode, and how to share a machine with IIS and HTTP.sys or with Apache, which cannot pass a validation through.

Settings

• Names: for a site, the host names of the bindings are listed first and cannot be edited there, since they belong to the bindings; below them, the additional host names you add. No wildcards, no IP addresses, at most 100 additional names. For the console the tab lists the names set in Global Configuration, Automatic certificates, and links there. Names are lowercased and converted to their ASCII form on save; internationalised names are accepted as typed and stored in their punycode form.
• Certificate authority: Let's Encrypt (the default), Let's Encrypt staging (for testing only, its certificates are not trusted by browsers), or a custom directory URL. A site Admin may only choose a custom authority a SuperAdmin has listed in Global Configuration; the SuperAdmin may list any. Authorities such as ZeroSSL or Google Public CA require an external account binding: the key identifier and the HMAC key they give you at registration.
• Account email: optional. The authority writes there about policy changes; Let's Encrypt no longer sends expiry reminders, Syncplify Server! does.
• Terms of service: the link is read from the directory and must be agreed to before enabling.
• Key type: ECDSA P-256 by default. Choose RSA only for clients that cannot do ECDSA. Changing the key type requests a new certificate.
• Advanced: a certificate profile the authority offers, the switch that skips the staging trial, the switch that skips the self check. Keep both switches off unless you know why not.

What happens when you save

1. The readiness check runs again on the server.
2. For Let's Encrypt, a full trial against the staging environment runs first, with the same self check: a misconfiguration never consumes production rate limits. The trial is repeated whenever the names, the authority or the key type change, and after three consecutive production failures.
3. The order is placed. For each name the node coordinating the order mints the validation certificate, hands it to every node and every worker, checks from every node that the name answers with it on port 443, and only then tells the authority to validate.
4. The certificate is installed in the certificate store of the site (or of the console), replicated to every node, and the listeners pick it up without a restart. It carries the badge Automatic in the certificate list and cannot be deleted while automatic certificates are enabled.
5. A notification announces the certificate and when it expires.

Renewal

The certificate authority's renewal information (ARI) decides when a certificate is renewed; without it, renewal happens at two thirds of the lifetime. Lifetimes are shrinking: Let's Encrypt moves to 64 day certificates in February 2027 and to 45 days in 2028, which is why no fixed number of days is used anywhere. The status shows the planned renewal moment as soon as the certificate is installed, together with what decided it: the authority's suggestion, or two thirds of the lifetime.

Renew now requests a new certificate ahead of time, at most once every ten minutes and three times a day. Test now runs the staging trial (Let's Encrypt) or the reachability probe (any other authority) on the saved settings without touching the certificate in use; the button waits while the form has unsaved changes.

In a cluster, one node coordinates every order; a site whose hosting node is offline waits for it, and Renew now can acknowledge a node that is permanently gone.

When it fails

The status card names what went wrong in plain words and what to do about it, with the raw error kept for support. A failed order is retried with a growing delay, never more than once an hour, and the authority's own Retry-After is honored; failures that need an operator (a CAA record, a name that does not resolve, an authority that refuses the account) wait six hours between attempts.

The first failure of an episode raises a warning notification. When the certificate in use expires within 14 days and renewal keeps failing, the notification becomes an error, a sentence appears on the sign in screen of both consoles, and the Telegram bot, when configured, is told. The certificate in use keeps serving until it expires; it is never removed by a failure.

Rate limits and reissuance

Let's Encrypt allows five certificates for the same set of names per week, and five failed validations per name per hour. Syncplify Server! stays inside both: one order at a time for the whole cluster, the staging trial before production, a self check that stops an order before the authority counts it, and a renewal that carries the authority's replacement marker and is exempt from the duplicate limit. Changing the host names, the authority or the key type is a new certificate and counts; the console asks for confirmation before such a save.

Switching off and deleting

Switching automatic certificates off keeps the last certificate installed as a normal certificate, so the listeners keep working, and stops renewal; the certificate can then be deleted like any other. Port 443 is no longer used for that scope.

Proxies

The management service reaches the certificate authority over outbound HTTPS and honors the HTTPS_PROXY environment variable. On Linux the service runs with a minimal environment: set the variable in the unit's environment, not in a shell profile.

Upgrading from the old console setting

Versions before 8.7.0 had an unexposed setting that let the console binding use Let's Encrypt. It was retired: the names it certified are the service binding's own host names, which the console's automatic certificate covers as soon as you review and enable it (it stays off until then), the certificates it had obtained are imported as ordinary certificates, and a notification says so.

Log events and notifications

The events of automatic certificates are the 9050 block on the log event page. The notifications are described on the notifications pages of the SuperAdmin and Admin interfaces.