Hypertext Transfer Protocol Secure is a widely used protocol on the internet. It is used to secure sensitive information transferred over the otherwise insecure HTTP protocol. This achieved by placing the SSL encryption layer on top of Web Server and Web Browser communications.
Certificates
There are two files required for SSL communication, a Certificate and a Private Key (matching the certificate). The private key is the key that is capable of decoding any data encrypted with the public certificate. The certificate is a file that is transmitted to connecting users, whereas the key remains private.
Certificate Validation
A certificate is also used to verify identity and trust, this is based on it being signed by a reputable authority. In addition it is checked that the "Common Name" matches the sites domain name. As certificates are for a domain basis (possibly with wildcard sub-domains) as they only usually have one "Common Name" field (Additional names may be possible with some Vendors).
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.
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 certificate.
- An uploaded certificate: You can provide us with a certificate (and it's key) which we will use on your behalf
- 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 non TLS connections.
In your dashboard you will find a 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 users 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 customers 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. Its hence recommended that you set the domain Regex to an approriate wildcard to prevent bots from generating excess certificates and hence exceeding this limit for your domain in Automatic mode.
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) sd 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: Only used for wildcard certificates. This method requires that you create a TXT record in your DNS zone with the value provided. This method is not recommended as it requires manual intervention and is not automated. After (manually) adding a domain on the SSL page of the Dashboard you will need to proceed through the manual next step page.
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$: domain.ac.au and www.domain.ac.au\.domain\.com$: All subdomains of domain1.com(?:\.|^)domain\.com$: All subdomains of domain1.com and domain1.com(?:\.domain1\.com|\.domain2\.com)$: domain1.com or domain2.com- ``: 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: Will match domain1.com.abc.com, abc.domain.dom and other unwanted domains^: 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 renrewal 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 domains.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 it's group pass validation and resolve to services within a users 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
A backend prefixed with "ssl://" on a HTTP or HTTPS type port will be treated as a 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 a HTTPS backend is 443.
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.
