HTTPS uses TLS to encrypt connections and authenticate the website. An X4B HTTPS port terminates visitor TLS so Layer 7 protection can inspect HTTP traffic. The separate backend protocol controls whether the connection from X4B to your origin also uses TLS.
Certificates
Provide a certificate and its matching private key. Clients receive the certificate; keep the private key confidential. Upload the certificate with any required intermediate chain and an unencrypted private-key file.
Certificate Validation
Browsers check the requested DNS hostname against dNSName entries in the certificate's Subject Alternative Name (SAN) extension. When connecting directly to an IP address, the certificate must contain that exact address in an iPAddress SAN entry; a DNS name that resolves to the address does not provide IP-address coverage. A certificate can cover multiple identities through these SAN entries.
The subject's Common Name (CN) is historical metadata and must not be used for hostname or IP-address matching under RFC 9525. Check SAN coverage when selecting or uploading a certificate.
Browsers also verify the certificate's validity period and a chain to a trusted certificate authority. A certificate for a different identity does not become valid merely because it was uploaded successfully.
Certificates are verified for trust using a system (or browsers) trusted roots. Your certificate may require one or more intermediary certificates (between your certificate and the root) to be provided. These should be appended in the same file you upload. For more information see this article on SSL trust chains and intermediaries.
Upload and verify a certificate
- Open Services, choose the service's Action → Ports, then an HTTPS port's Action → SSL.
- Under Certificate Upload → Upload a certificate, select the Certificate file and matching Private key file, then choose Upload Certificate. Uploading replaces the existing certificate; retain the previous files if you need to restore them.
- Reload and confirm Certificate: Uploaded, Private Key: Provided, and the expiry status. Then verify the deployed hostname in a browser; a saved upload alone does not prove hostname coverage, trust or public reachability.
TLS protocol options
Open Protocol Options, keep TLSv1.2 and TLSv1.3 selected, and choose Set Protocol Options. Reload and reopen the tab to confirm the saved selection. New ports use these modern defaults. TLS 1.0 and 1.1 require an explicit legacy-compatibility acknowledgement; enable them only when a documented client requirement justifies it. HTTP/2 requires TLS 1.2 or later.
AutoSSL and protocol options apply to all virtual hosts sharing the same IP address and port number. Review other websites on that listener before changing them.
Methods of providing a certificate
To serve your clients over HTTPS we need a certificate.
There are three main types of certificate we may serve:
- Generated certificates: A self signed certificate generated in the client panel. Browsers will not trust this certificate.
- An uploaded certificate: You can provide us with a certificate (and its key) which we will use on your behalf for all requests to the port (virtual host)
- AutoSSL: We will serve a certificate specific to the SNI received over TLS which we will generate with Lets Encrypt
If none of these options suit you can utilize the TCP (Layer 4) type ports. You will not receive Layer 7 protection in this case (HTTPS is secure, we can not MITM your traffic).
X4B AutoSSL (Lets Encrypt)
Free SSL certificates can be generated on the fly for your domains by enabling "AutoSSL" for your port on the SSL page. A base SSL certificate (can be self-signed / generated) must be provided and will be used in case of signing failure, connections to an IP (not domain name) or for clients without TLS SNI support.
In your dashboard you will find an SSL overview with details on the SSL certificates we have on file and for User certificates (AutoSSL) details regarding their renewal. You can also manually generate certificates from this page.
Certificates generated via AutoSSL are specific to a user's account. Attempts to serve the same domain name from a different account will fail. If a domain is to move between accounts please first speak to support. Certificate generation is subject to all Rate Limits and policies of the Certificate vendor (Lets Encrypt). We create one Lets Encrypt account per customer's account, so all per user rate limits apply only to you. If certificate generation (or renewal) fails we will retry up to 8 times (and on a regular basis).
There is a limit of the number of subdomain certificates that can be generated for a domain. It is hence recommended that you set the domain Regex to an appropriate wildcard to prevent bots from generating excess certificates and hence exceeding this limit for your domain in Automatic mode.
To configure automatic issuance, open the port's SSL → AutoSSL tab, select Enable AutoSSL, and enter an anchored Automatic Mode Domains (Regex) expression, such as ^www\.example\.net$. Choose Set AutoSSL options, reload, and reopen AutoSSL to confirm both settings. Use your own hostname and complete the domain validation below. Leave the expression blank when you intend to request domains manually through the dashboard's SSL page.
Usage in Automatic Mode
A SSL certificate will be automatically generated on the first request to a specific domain provided the supplied Regular Expression (Regexp) is matched. To use automatic mode a regexp must be provided.
Usage in Manual Mode
Domains for which you wish to generate a certificate can be added manually on the SSL page of the Dashboard. This is useful if you do not wish to define a Regular expression for automatic generation. This is also useful if you wish to generate a wildcard certificate (e.g *.domain.com) as this is not possible with Automatic mode.
If you do not wish to use Automatic mode you can disable it on the SSL page of the Dashboard by providing a blank regular expression.
Validation of Domain Ownership
http-01 (default): It is important that your domain name resolves to the X4B service in order for a certificate to be generated. Should the site not resolve certificate signing will fail and the base SSL certificate will instead be served. Keep in mind if making DNS changes this means that the DNS will have to propagate (DNS caching).
dns-01: Used for wildcard certificates. The DNS-01 setup page shows a persistent _acme-challenge CNAME. If a matching zone is managed by your account in X4B DNS, you can choose Install DNS validation record to add it. The page previews the exact record first; no DNS changes happen until you submit. Identical records are reused, conflicting records are left untouched, and unrelated records are preserved.
If your active DNS is hosted elsewhere, add the displayed CNAME with that provider. Having a zone in X4B DNS does not move DNS hosting. Once the expected delegation appears in public DNS, certificate issuance proceeds automatically. X4B publishes the changing TXT challenges at the delegated target for issuance and renewal; keep the CNAME in place. DNS publication, propagation and certificate issuance finish separately.
Domain and wildcard coverage
Use these domain formats when requesting an AutoSSL certificate:
| AutoSSL domain | Certificate coverage |
|---|---|
example.com | That exact hostname only. |
*.example.com | Immediate subdomains only; excludes the base domain. |
.example.com | Base domain and immediate subdomains on one certificate. |
A wildcard covers only one subdomain level: neither *.example.com nor the combined .example.com request covers a.b.example.com. Add an exact certificate for that name or suitable wildcard coverage such as *.b.example.com. See the Let’s Encrypt glossary for wildcard terminology.
The port domain .example.com forwards the base domain and all its subdomains, including deeper names. HTTPS still requires certificate coverage for every hostname you use. In website quick setup, Domain only requests exact coverage; Domain and all subdomains requests combined coverage for the base domain and immediate subdomains. For an uploaded certificate, its Subject Alternative Names (SANs) must include both example.com and *.example.com to provide that combined coverage.
Both wildcard formats use the persistent DNS-01 validation CNAME described above, including automatic renewal and RSA/ECDSA variants. Existing separate certificates remain supported and quick setup reuses compatible entries. Overlapping publication paths must be resolved before adding a combined request. Forwarding all domains does not authorize automatic certificates for arbitrary domains.
Domain Regular Expression
A Regex expression (Perl syntax) can be applied limiting the valid domain names that certificates will be generated for. Ideally regular expressions will be anchored to either the start (^) or end ($) or both for performance and accuracy.
Good examples:
^(?:www\.)?domain\.ac\.au$: Only the apex domain.ac.au and the subdomain www.domain.ac.au; excludes all other subdomains.\.domain\.com$: Subdomains of domain.com at any depth; excludes the apex domain.com.(?:\.|^)domain\.com$: The apex domain.com and its subdomains at any depth.^(?:domain1|domain2)\.com$: Only the apex domains domain1.com and domain2.com; excludes all subdomains.- A blank expression will match no domains and can be used to disable automatic generation (useful if you wish to manually add domains)
Bad examples:
domain\.com: Matches domain.com anywhere, including unwanted names such as notdomain.com and domain.com.attacker.test; does not enforce apex or subdomain boundaries.^: Will match all domains resulting in large numbers of certificates being generated by bots
Tips:
- Remember to escape
. - International Domain names are in ASCII format
- Remember to anchor your expression
- Use
(?:)capture syntax to prevent excess captures lowering performance
Performance:- Limits are in place to prevent poorly performing regular expressions from being used
- We strongly recommend that all regular expressions are anchored to the start of the domain name (^)
- If you must allow one or more subdomains we recommend that you use ^(?:[a-z]+\.)? to allow one deep subdomains
- If you must allow multiple levels of subdomains we recommend that you use ^(?:[a-z]+\.)* to allow multiple levels subdomains
Note: If you have certificates generated that can not be served by the regular expressions you have set, and all your ports have Regular Expressions defined (as they should) then these unreachable certificates will be disabled. Additionally if you have existing certificates but no HTTPS ports defined all SSL certificates will be disabled.
Certificate Grouping (SAN)
Subject Alternative Names (SAN) are a method of grouping multiple domain names into a single certificate. This is useful for example if you have multiple subdomains that you wish to serve over HTTPS. This is also useful if you have multiple domains that you wish to serve over HTTPS.
In our dashboard you can group multiple generated certificate domains together for this purpose. Once grouped on next renewal the certificate generated will contain all the domains in the group as subject alternative names. The primary domain will be used as the certificate common name.
Including all names in a single certificate is useful for performance reasons as it reduces the number of certificates that need to be served to clients. This is particularly useful if you have a large number of subdomains, however too many SANs increases the certificate size and hence the time it takes to generate and serve the certificate. We hence recommend grouping domains that are related to each other (likely to be used by the same clients). If in doubt we recommend a limit of 100 SANs per certificate (at most).
We will attempt to automatically group www.domain.com and domain.com certificates when possible. And recommend that if not grouped that you do so manually.
A certificate can be generated/renewed only if all domains within its group pass validation and resolve to services within a user's account.
Email Address Warning
The email address field of the generated SSL certificate is publicly available to anyone with access to the certificate (connecting to the website). This represents an easy method for spam crawling bots to obtain your email address. For this reason we recommend ensuring that the email address in this field is to a spam filtered email address.
If you are using a self-signed certificate, such as the ones we generate on this site it should be acceptable for most applications to use an incorrect email address in this field.
Proxying to HTTPS Backends
In Ports, use the backend padlock control to enable TLS, or open HTTP Options and select Backend Protocol → HTTPS / SSL, then Set. Confirm the origin's HTTPS port, commonly 443; this setting is independent of the visitor-facing protocol.
In raw configuration, a backend prefixed with "ssl://" on an HTTP or HTTPS type port will be treated as an SSL/HTTPS backend. e.g ssl://100.1.1.1 would forward to a ssl service running on 100.1.1.1. The default port for an HTTPS backend is 443. This is visualised in the dashboard as a green lock icon next to the backend.
There is a performance cost to this, particularly when new connections need to be established. For this reason its best that you ensure that on our end your keepalive values are sufficient and that your backend has HTTP keepalive configured with generous limits.
Identifying HTTPS Requests:
Clients who access via HTTPS will have the HTTP header X-Scheme set to HTTPS.
