SSL Certificate Management: Renewal and Best Practices

Let's Encrypt revolutionized the SSL landscape: free, automated and trusted certificates accepted by all common browsers and operating systems. Over 350 million (project experience) active certificates (Let's Encrypt, 2026) make it the world's largest certificate authority. For most online shops, Let's Encrypt certificates are the right choice -- they offer the same encryption strength as paid certificates.

Automation via Certbot or alternative ACME clients ensures certificates are automatically renewed before expiration. A Let's Encrypt certificate is valid for 90 days -- deliberately shorter than commercial certificates to enforce more frequent rotation and thus higher security. Certbot renews by default 30 days before expiry -- enough buffer for multiple renewal attempts should the first fail.

For shops with multiple subdomains, wildcard certificates (*.example.com) cover all subdomains with a single certificate. Validation occurs via DNS TXT records instead of HTTP -- requiring a one-time API integration with the DNS provider. For multi-domain setups, SAN certificates (Subject Alternative Name) bundle multiple different domain names in one certificate. Both variants can be automated with Let's Encrypt management.

A valid certificate is only half of SSL security. The web server's TLS configuration determines which protocol versions and encryption algorithms are used. Outdated protocols like TLS 1.0 and 1.1 contain known vulnerabilities and are no longer supported by current browsers. The recommended configuration for 2026: TLS 1.2 as minimum, TLS 1.3 as standard.

TLS 1.3 offers significant advantages: shorter handshake (1 round-trip instead of 2), stronger encryption through removal of insecure algorithms and mandatory forward secrecy. The cipher suite configuration should only allow AEAD ciphers (Authenticated Encryption with Associated Data) like AES-256-GCM and ChaCha20-Poly1305. Weak ciphers like RC4, 3DES and CBC-mode ciphers should be completely disabled.

OCSP stapling improves TLS connection performance: instead of the browser separately querying the certificate's revocation status from the CA, the server delivers the OCSP response together with the certificate. This saves an additional network round-trip and accelerates connection establishment by 50 to 100 milliseconds. Correct TLS configuration is an important part of professional server maintenance.

The SSL Labs Server Test (Qualys) is the industry standard for evaluating TLS configuration. It checks the certificate chain, supported protocols and cipher suites, HSTS configuration and known vulnerabilities like BEAST, POODLE and Heartbleed. The result is a grade from A+ to F. For an online shop, the target should be A+ -- achievable through TLS 1.2/1.3 with strong ciphers, HSTS with preloading, OCSP stapling and a cleanly configured certificate chain.

We recommend running the SSL Labs test monthly and documenting results. Server updates, configuration changes or expiring intermediate certificates can silently degrade the rating. Integration into the monitoring system automates this check and warns of deviations from the target rating.

Mixed content occurs when an HTTPS page loads resources over HTTP -- images, stylesheets, JavaScript or fonts. Modern browsers completely block active mixed content (JavaScript, iframes) and warn about passive mixed content (images). In both cases, user experience and security suffer: an HTTP-loaded script can be manipulated by an attacker, even when the main page is delivered over HTTPS.

The most common mixed content sources in online shops are: product images stored with absolute HTTP paths in the database, embedded content from third parties (videos, maps, widgets), hardcoded URLs in theme files and external tracking pixels still included via HTTP. A systematic scan of all pages identifies all mixed content sources.

Remediation occurs at multiple levels: database update of all HTTP URLs to HTTPS, theme adjustments for hardcoded paths, CSP header with upgrade-insecure-requests as fallback (browser automatically converts HTTP requests to HTTPS) and verification of all third-party integrations. Professional maintenance ensures no new mixed content arises even after updates and content changes.

Beyond obvious mixed content, there are subtle variants harder to detect: font files loaded via HTTP, tracking pixels with HTTP URLs in email templates, favicon references without protocol specification and hardcoded HTTP URLs in CMS database entries. A systematic database search for the string "http://" in the content area reveals these hidden references. After correction, a consistent Content Security Policy with the "upgrade-insecure-requests" directive prevents new HTTP references from going unnoticed -- the browser automatically converts all HTTP requests to HTTPS.

During every TLS handshake, the browser checks whether the certificate has been revoked. Without OCSP stapling, the browser sends a separate request to the certificate authority's OCSP responder -- costing 30 to 100 milliseconds (project experience) per connection setup and creating a privacy concern because the CA learns which websites the user visits. With OCSP stapling, the server attaches the current OCSP response to the TLS handshake. The browser receives the validity confirmation directly from the server without an additional round trip.

Configuring OCSP stapling is straightforward in modern web servers and should be standard in every SSL management setup. Two directives are activated in the server configuration: the OCSP stapling function itself and OCSP verification of the stapled response. Additionally, the server must know the complete certificate chain to correctly sign the OCSP request. A regular test via SSL Labs confirms that OCSP stapling is active -- the report shows the status under "OCSP Stapling: Yes".