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:

  1. Generated certificates: A self signed certificate generated in the client panel. Browsers will not trust certificate.
  2. An uploaded certificate: You can provide us with a certificate (and it's key) which we will use on your behalf
  3. AutoSSL: We will serve a certificate specific to the SNI received over TLS which we will generate over ACME

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 SSL certificate will be automatically generated on the first request to a specific domain.

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.

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).

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.

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.

Certificates generated with AutoSSL are subject to all Rate Limits and policies of the Certificate vendor (Lets Encrypt). We create one 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 on a regular basis.

Domain Wildcard

A Regex expression (Perl syntax) can be applied limiting the valid domain names that certificates will be generated for.

Good examples:

  • ^(?:www\.)?domain\.ac\.au$
  • \.domain\.com$
  • (?:\.domain1\.com|\.domain2\.com)$

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 may be fine to use an incorrect email address in this field.

Proxying to HTTPS Backends

This is not recommended for performance reasons. Where possible, at all costs you should avoid this!

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.

Identifying HTTPS Requests:

Clients who access via HTTPS will have the HTTP header X-Scheme set to HTTPS.