Secure Sockets Layer
Secure Sockets Layer (SSL)
SSL establishes an encrypted connection between a web server and a browser. In modern deployments, the actual protocol is normally TLS, while the familiar term SSL is still widely used for certificates and HTTPS configuration.
An SSL/TLS certificate helps protect sensitive information while it travels between users and the application. It also confirms that the browser is communicating with the intended domain.
On this page
Why SSL/TLS Is Required
Encryption
Prevents transmitted information from being read easily by unauthorised parties.
Authentication
Allows the browser to verify that the certificate belongs to the requested domain.
Data Integrity
Helps detect whether information was changed while travelling between the client and server.
HTTPS Access
Enables secure access to websites, APIs, administration panels, and application endpoints.
How an Encrypted Connection Works
Browser Requests HTTPS
→
Server Sends Certificate
→
Browser Verifies Certificate
→
Encrypted Session Starts
- The browser connects to the application through HTTPS.
- The server or load balancer presents its SSL/TLS certificate.
- The browser verifies the certificate authority, domain name, and validity period.
- The client and server agree on encryption settings and create a secure session.
- Application traffic is encrypted for the duration of the connection.
The certificate itself is public. The related private key must remain protected and should never be shared or stored in an unsecured location.
SSL Options on the Platform
| SSL Option | Purpose | Typical Use |
|---|---|---|
| Built-In SSL | Provides HTTPS for the default environment domain through the platform infrastructure. | Quick secure access without purchasing or uploading a separate certificate. |
| Custom SSL | Uses a certificate issued for a custom domain and installed on a load balancer or application server. | Production websites using their own branded domain. |
| Let’s Encrypt | Automates certificate issuance and renewal for supported custom-domain configurations. | Free domain-validated certificates with automated lifecycle management. |
| Direct SSL with Public IP | Terminates HTTPS directly on a node that has a dedicated public address. | Custom server configuration, direct access, or protocols that bypass the shared load balancer. |
Built-In SSL limitation: Built-In SSL normally protects the platform environment domain. A custom domain generally requires Custom SSL or an automated certificate solution such as Let’s Encrypt.
General Certificate Requirements
- The certificate must include the exact domain used by visitors.
- The certificate must remain within its validity period.
- The complete certificate chain, including intermediate certificates, should be installed.
- The private key must match the certificate.
- The domain DNS records must point to the correct platform entry point.
- The HTTPS port must be accessible through the load balancer, public IP, endpoint, or firewall configuration.
A wildcard certificate can protect several first-level subdomains, while a multi-domain certificate can include several specified hostnames. Confirm that the selected certificate type matches the application’s domain structure.
Security Recommendations
- Redirect all HTTP requests to HTTPS after confirming the certificate works correctly.
- Use current TLS versions and disable outdated protocols and weak cipher suites.
- Protect private keys with strict file permissions.
- Renew certificates before they expire.
- Test the complete certificate chain after installation.
- Keep application servers and load balancers updated.
- Use HSTS only after HTTPS is working reliably for every required hostname.
Certificate renewal: An expired certificate causes browser security warnings and can interrupt API clients and automated integrations. Use renewal reminders or automated renewal whenever possible.
