SSL/TLS Certificates: Complete Server Guide

What Is SSL/TLS

SSL (Secure Sockets Layer) was the original encryption protocol for web communications, developed by Netscape in the 1990s. After several critical vulnerabilities, it was replaced by TLS (Transport Layer Security), which is the current standard. Although the term "SSL" is still used colloquially, all modern connections use TLS (versions 1.2 and 1.3).

An SSL/TLS certificate is a digital file issued by a Certificate Authority (CA) that binds a public key to the identity of a domain (and optionally an organisation). When a browser connects to an HTTPS server, it verifies that the certificate is valid, has not expired, was issued by a trusted CA and matches the requested domain. Only if all these checks pass is the encrypted connection established.

The TLS Handshake: How the Secure Connection Is Established

The TLS handshake is the negotiation process that takes place before any application data is transmitted. In TLS 1.2, the handshake requires two round trips (2-RTT) between client and server. In TLS 1.3, it is reduced to a single round trip (1-RTT) and even supports 0-RTT for reconnections, drastically reducing latency.

• looks_one ClientHello: the browser sends the TLS versions and cipher suites it supports, along with a random number.
• looks_two ServerHello: the server selects the TLS version and cipher suite, sends its certificate and public key.
• looks_3 Key Exchange: both parties generate session keys via Diffie-Hellman (ECDHE in TLS 1.3), ensuring forward secrecy.
• looks_4 Finished: the integrity of the handshake is verified and encrypted data exchange begins using the negotiated symmetric cipher (AES-256-GCM, ChaCha20-Poly1305).

Certificate Types: DV, OV and EV

Not all SSL/TLS certificates are the same. They are classified by the level of validation the CA performs before issuing them:

• verified DV (Domain Validation): only verifies that the applicant controls the domain (via DNS or HTTP challenge). Issued in minutes, it is the most common type. This is what Let's Encrypt and most free providers offer.
• domain_verification OV (Organisation Validation): in addition to the domain, the CA verifies the legal existence of the organisation. It includes the company name in the certificate. It takes 1-3 days and is common for corporate websites.
• workspace_premium EV (Extended Validation): the most rigorous level. Requires thorough verification of the organisation, physical address and applicant authorisation. Historically it displayed the company name in green in the browser bar (now removed in most browsers).

Free vs Commercial: Let's Encrypt and Alternatives

Let's Encrypt revolutionised the certificate landscape by offering free DV certificates with automated issuance and renewal. In 2026, Let's Encrypt protects more than 60% of HTTPS sites on the Internet. Its certificates have a 90-day validity and are renewed automatically with tools such as Certbot or acme.sh.

Commercial certificates (DigiCert, Sectigo, GlobalSign) still make sense in specific scenarios: when you need OV or EV validation, when you require certificates with a financial warranty, when your organisation demands technical support from the issuer, or when you operate in regulated sectors that require certificates from a specific CA.

From an encryption standpoint, there is no difference. A DV certificate from Let's Encrypt and an EV certificate from DigiCert use exactly the same cryptographic algorithms and offer the same level of channel protection. The difference lies in identity validation and the issuer's additional services.

Wildcard and SAN Certificates

When you manage multiple subdomains or domains on the same server, two certificate types simplify operations:

• star Wildcard (*.domain.com): covers the main domain and all first-level subdomains (www, mail, api, app, etc.). It does not cover second-level subdomains (*.sub.domain.com). Let's Encrypt issues them free of charge via DNS-01 challenge.
• playlist_add_check SAN (Subject Alternative Name): a single certificate that lists multiple different domains (domain1.com, domain2.co.uk, domain3.net). Ideal for servers hosting several websites or for including variants with and without www.

Certificate Lifecycle

Every SSL/TLS certificate goes through a lifecycle that the administrator must understand and manage:

• key Key generation: a private key (RSA 2048/4096 or ECDSA P-256/P-384) and public key pair is created. The private key must never leave the server.
• description CSR (Certificate Signing Request): a signing request is generated that includes the public key and domain/organisation data, and is sent to the CA.
• fact_check Validation: the CA verifies domain ownership (DV) or the organisation's identity (OV/EV) and issues the signed certificate.
• install_desktop Installation: the certificate, private key and intermediate certificate chain are configured on the web server (Nginx, Apache, HAProxy).
• autorenew Renewal: before expiry (90 days for Let's Encrypt, 1 year for commercial), the certificate is renewed. Automation is critical here.
• gpp_maybe Revocation: if the private key is compromised, the certificate must be revoked immediately with the CA so it is included in CRL/OCSP lists.

Comparison Table: SSL/TLS Certificate Types

The following table summarises the key differences between the available certificate types:

TLS 1.2 vs TLS 1.3: Key Differences

TLS 1.3 (RFC 8446, published in 2018) is not an incremental improvement: it is a deep rewrite of the protocol that removes insecure algorithms and simplifies negotiation. The fundamental differences are:

• speed Faster handshake: TLS 1.3 completes the handshake in 1-RTT (compared to 2-RTT in TLS 1.2). It supports 0-RTT for reconnections, eliminating handshake latency entirely.
• delete_sweep Legacy algorithms removed: TLS 1.3 removes RSA key exchange (no forward secrecy), CBC mode ciphers, RC4, SHA-1, DES/3DES and compression (vulnerable to CRIME/BREACH).
• lock Mandatory forward secrecy: all TLS 1.3 connections use ECDHE or DHE for key exchange, ensuring session keys cannot be recovered even if the server's private key is compromised.
• enhanced_encryption Encrypted handshake: in TLS 1.3, handshake messages after ServerHello are encrypted, reducing the attack surface for passive interception.

Common SSL/TLS Configuration Mistakes

Even with automated tools, SSL/TLS configuration errors are one of the most frequent causes of incidents on web servers. These are the most common:

• error Incomplete certificate chain: failing to include the CA's intermediate certificates. The server presents the end certificate but the browser cannot build the chain up to the root CA. Solution: concatenate the server certificate with the intermediates in the fullchain.pem file.
• error Expired certificate: the number one cause of HTTPS outages. Without automation, it is only a matter of time before a certificate expires without anyone renewing it.
• error Mixed content: the page is served over HTTPS but loads resources (images, scripts, CSS) over HTTP, triggering browser warnings or content blocking.
• error Weak cipher suites: keeping obsolete algorithms enabled (RC4, DES, CBC without AEAD) exposes the server to attacks such as BEAST, POODLE or Lucky13.
• error Missing HTTP to HTTPS redirect: the server listens on port 80 but does not redirect to 443, allowing unencrypted connections. A permanent 301 redirect must be configured.

Renewal Automation

Manual certificate renewal is unsustainable at scale. With 90-day certificates (Let's Encrypt) or even 1-year certificates (commercial), automation is the only way to prevent unexpected expirations. The main tools are:

• terminal Certbot: the official ACME client for Let's Encrypt. It supports plugins for Nginx, Apache and standalone mode. A cron job running certbot renew twice a day is sufficient to keep all certificates up to date.
• code acme.sh: a lightweight ACME client written in shell. It supports multiple CAs (Let's Encrypt, ZeroSSL, Buypass) and over 100 DNS providers for DNS-01 challenge. Ideal for automated wildcards.
• monitoring Monitoring: in addition to automatic renewal, it is critical to monitor certificate expiry dates with tools such as Prometheus (blackbox_exporter), Nagios or custom scripts that alert days in advance.

EasyDataHost and SSL/TLS

At EasyDataHost, all Cloud IaaS and managed services include full SSL/TLS support. Our team configures, deploys and monitors certificates so your infrastructure is protected without manual intervention.

• check_circle TLS 1.3 by default: all endpoints are served with TLS 1.3 and modern cipher suites (AEAD + forward secrecy).
• check_circle Automatic renewal: Let's Encrypt certificates managed with automatic renewal and expiry monitoring.
• check_circle Wildcard and SAN: support for wildcard and multi-domain certificates on dedicated and cloud servers.
• check_circle Security audits: periodic review of TLS configuration, cipher suites and security headers (HSTS, HPKP, CAA).

Conclusion

SSL/TLS certificates are the foundation of security on any web server. It is not just about enabling HTTPS: it is about understanding the handshake, choosing the right certificate type, correctly configuring TLS versions, avoiding errors that break the chain of trust and automating renewal so that no certificate expires uncontrolled.

• arrow_right SSL/TLS encrypts communications and authenticates the server's identity to the client.
• arrow_right DV certificates (Let's Encrypt) are sufficient for most servers; OV/EV provide organisational identity validation.
• arrow_right TLS 1.3 is the recommended version: fast handshake, mandatory forward secrecy and removal of legacy algorithms.
• arrow_right Renewal automation (Certbot, acme.sh) and expiry monitoring are essential.
• arrow_right EasyDataHost manages SSL/TLS certificates with TLS 1.3, automatic renewal and security audits.

If you need help configuring SSL/TLS on your servers or want an infrastructure with automatically managed certificates, contact our team to design the solution that best fits your requirements.