SSL Certificate Management

Tula provides comprehensive SSL/TLS certificate management for terminating encrypted connections at the load balancer. Certificates can be uploaded through the web interface, inspected for validity and expiry, and assigned to Layer 7 Virtual IPs. Tula supports multiple certificates per VIP via Server Name Indication (SNI), enabling a single load balancer to serve HTTPS traffic for many domains.

Supported Certificate Formats

Tula accepts certificates in the following formats:

PEM (Privacy-Enhanced Mail). The most common certificate format, consisting of Base64-encoded text files. PEM bundles should include the server certificate, any intermediate certificates, and the private key, either combined in a single file or uploaded as separate files. PEM files typically use .pem, .crt, or .key extensions.

PFX/PKCS#12. A binary format that bundles the certificate, private key, and intermediate certificates into a single encrypted file. Commonly used when exporting certificates from Windows-based certificate authorities or IIS. PFX files use the .pfx or .p12 extension and require the export password to be provided during upload.

Tula automatically converts uploaded PFX files to PEM format internally, as HAProxy requires PEM-formatted certificates.

Uploading Certificates via the Web UI

To upload a certificate:

Navigate to SSL > Certificates in the Tula web interface.
Click Upload Certificate.
Select the certificate format (PEM or PFX).
For PEM certificates: Upload the certificate file, the private key file, and optionally a separate chain file. Alternatively, upload a single combined PEM file containing all three.
For PFX certificates: Upload the PFX file and enter the export password.
Provide a descriptive name for the certificate to identify it in the interface.
Click Save to upload and validate the certificate.

Tula validates the uploaded certificate to ensure the private key matches the certificate, the certificate chain is complete, and the files are correctly formatted. Any validation errors are reported immediately.

Certificate Chains

For browsers to trust your certificate, the full chain of trust must be presented during the TLS handshake. This chain includes your server certificate, any intermediate certificates issued by your Certificate Authority (CA), and implicitly terminates at the root CA certificate (which browsers have pre-installed).

When uploading a certificate, ensure you include all intermediate certificates. If intermediates are missing, clients may see trust errors even though the server certificate itself is valid. Tula displays a warning if it detects an incomplete chain during upload.

The correct chain order is:

Server certificate (your domain's certificate)
Intermediate certificate(s), ordered from lowest to highest in the chain
Root certificate (optional -- typically omitted as clients already have it)

Viewing Certificate Details and Expiry

The SSL > Certificates page displays a summary of all installed certificates, including:

Common Name (CN) and Subject Alternative Names (SANs) -- the domains the certificate covers.
Issuer -- the Certificate Authority that issued the certificate.
Valid from / Valid to -- the certificate's validity period.
Days until expiry -- a countdown highlighting certificates approaching expiration.
Key type and size -- RSA (2048, 4096) or ECDSA (P-256, P-384).

Certificates nearing expiration are highlighted with warnings. Tula can also be configured to send SNMP traps or alerts when certificates are within a configurable number of days of expiring.

SNI Support for Multiple Certificates

Server Name Indication (SNI) is a TLS extension that allows the client to specify the hostname it is connecting to during the TLS handshake. This enables the load balancer to select the correct certificate based on the requested domain, allowing multiple HTTPS sites to share a single VIP and IP address.

To configure SNI:

Upload a certificate for each domain.
Navigate to Load Balancing > L7 Virtual IPs and select the VIP.
Assign a default certificate -- this is used when the client does not send an SNI header or when no matching certificate is found.
Add additional SNI certificates and associate each with its corresponding domain name.

HAProxy automatically matches incoming SNI hostnames to the appropriate certificate. Wildcard certificates (e.g., *.example.com) are supported and will match any subdomain within the specified domain.

Security Considerations

Store private keys securely. Tula encrypts private keys at rest and restricts filesystem access to the HAProxy process.
Use RSA 2048-bit keys as a minimum. ECDSA P-256 keys provide equivalent security with better performance.
Disable outdated TLS versions (TLS 1.0, 1.1) and weak cipher suites through the VIP's SSL settings.
Rotate certificates before expiry. Consider using Let's Encrypt automation for hands-free certificate lifecycle management.