SSL/TLS Security
Updated over a week ago

All our HTTP traffic is encrypted through secured SSL/TLS protocols (e.g. https). Connections between the client and our load balancing proxies are secured through different CAs. Internal connections are secured by an internal certification authority.

We use LetsEncrypt for public certificates and Gentlent TrustCert for internal certificates. For the certificates, we can manually import your own certificates on request. The automatic generation or renewal starts around 1 week before the certificate expires. Certificates can also be created with wildcards, as long as the Gentlent DNS is used. Domains in the certificates are grouped if required.

Client: On the client-side, we ensure security through enforcing of different HTTP headers like the content security policy, expect certificate transparency, referrer policy, strict transport security, XSS protection, frame options, content type options and more. Look at our more up-to-date report.

SSL/TLS: On the server-side, SSL certificates are used and enforced on the client-server-side, but also on the server-server-side at the backend. On the client-server-side, we are enforcing standards like TLSv1.2+, different cyphers, strong keys, certificate transparency, DNS CAA records, OCSP stapling and more. Again, you can find a more up-to-date report here.

Internal SSL certificates: In Our server-server connections we use certificates issued over our Root Certificate at The Trusted Root Certificate is created by the Microsofts Trusted Root Program Requirements. The internal certificates are provided with RSA (2048, 3072, 4096, 8192 bit) and ECDSA (384, 512 bit).

Public SSL certificates: The certificates are used for the client-serve connections. The public certificates are provided with ECDSA (384, 512 bit) or RSA (2048, 3072, 4096) keys.

Did this answer your question?