Implementing an SSL/TLS certificate is now an absolute standard for every website, web application, or API interface. However, simply having a certificate does not guarantee security. In practice, many implementations leave gaps that not only lower the level of protection but also affect the domain’s reputation, SEO, and compliance with regulations (e.g. NIS2, GDPR).

This article presents the most common mistakes related to the implementation and maintenance of SSL/TLS, their technical consequences, and ways to eliminate them — in accordance with industry best practices (OWASP, Mozilla SSL Configuration Guidelines, SSL Labs, ENISA).

1. Mixed Content – mixed content on an HTTPS page

What is the issue?

“Mixed content” occurs when the main page is loaded via the secure HTTPS protocol, but some resources (e.g. images, JS scripts, fonts, CSS styles) come from an unsecured HTTP source.

<img src="http://example.com/logo.png">
<script src="http://cdn.insecure.com/script.js"></script>

As a result, the site is no longer fully encrypted, and the browser displays a warning about insecure content.

Consequences

• The user sees messages like “This page is not fully secure” or “Mixed Content detected.”
• Some data (e.g. session or authentication data) may be transmitted over an unencrypted channel.
• In extreme cases, browsers block the loading of certain resources (JS/CSS).
• SEO drop – Google considers the page non-compliant with security standards.

How to avoid it?

• Use relative paths or full HTTPS references (https://).
• Enforce HTTPS in headers (HSTS – HTTP Strict Transport Security).
• Use scanning tools (e.g. Why No Padlock, SSL Labs, HEXSSL SSL Checker) to detect mixed content.
• In CDN and external API integrations, enforce secure endpoints (https://api.example.com).

2. Expired or invalid certificates (Expired / Revoked Certificates)

Root cause

An SSL certificate has a limited validity period – currently, according to CA/B Forum guidelines, a maximum of 398 days. In practice, many organizations lose control over the certificate renewal process, which leads to situations where the domain suddenly becomes untrusted by browsers.

A common mistake is also the lack of reaction to certificate revocation, e.g. due to private key compromise.

Consequences

• The site becomes unavailable — browsers block the connection with the message “Your connection is not private” / “NET::ERR_CERT_DATE_INVALID.”
• Loss of reputation and user trust.
• Downtime of API, mail (SMTP, IMAP, POP3 over TLS), VPN, and automation systems.
• Violation of security policies ISO/IEC 27001, NIS2, PCI DSS.

How to avoid it?

• Implement certificate validity monitoring (HEXSSL SSL Expiry Monitor, Zabbix, Nagios, Cron + OpenSSL).
• Automate renewals – e.g. via ACME/Let’s Encrypt, GoGetSSL API, Certbot, Posh-ACME.
• Maintain a centralized registry of certificates and keys (Certificate Inventory).
• Implement OCSP stapling and CRL checks — this allows the browser to verify the certificate status faster.
• Apply a key rotation and regular audit policy.

3. Incorrect SSL/TLS server configuration

What does it mean?

Administrators often use default server settings or copy configurations from outdated environments. As a result, the system uses deprecated ciphers, old protocols, or an incorrect certificate chain.
Examples of errors:

• Active TLS 1.0 or 1.1
• Use of RC4, 3DES, MD5, SHA-1
• Missing intermediate certificates (incomplete chain)
• Missing security headers (HSTS, X-Frame-Options, X-Content-Type-Options)
• Shared certificate for multiple independent domains

Consequences

• Lower SSL Labs score (C–F rating).
• Vulnerability to attacks: BEAST, POODLE, Heartbleed, ROBOT, DROWN, Logjam.
• Compatibility issues with newer browsers and systems.
• Connection failure on mobile devices or API clients.

How to avoid it?

• Force the use of TLS 1.2 and TLS 1.3.
• Disable all outdated ciphers (!RC4:!MD5:!DES:!aNULL).
• Use strong ciphers recommended by Mozilla SSL Configuration Generator.
• Regularly test the configuration using Qualys SSL Labs or HEXSSL SSL Checker.
• Enable Perfect Forward Secrecy (PFS) – e.g. ECDHE or DHE.
• Use the full cert chain (Root + Intermediate + Leaf).
• Implement security headers in the server configuration:
  Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"


4. Improper private key management

Risk source

The private key is the core of SSL/TLS infrastructure. Its leakage means loss of certificate integrity and requires immediate revocation.

Most common mistakes:

• Storing the key in public Git repositories.
• Lack of permission separation (root/admin = access to keys).
• Sending keys via email or in plaintext.
• No encryption of .key files.

Best practices

• Store private keys in HSM (Hardware Security Module) or at least in an encrypted keystore.
• Set appropriate file permissions (chmod 600).
• Use strong algorithms (RSA ≥ 3072 bit, ECDSA P-256/P-384).
• Rotate keys every 12 months or upon personnel changes.
• Monitor certificate usage and TLS server logs.

5. Lack of post-deployment testing

Why is it a problem?

Many implementations end at the stage “the certificate works.” Few administrators verify whether connections are actually encrypted and whether the configuration follows best practices.

Testing tools

• Qualys SSL Labs Test – full SSL configuration audit.
• HEXSSL SSL Checker – instant analysis of CN, SAN, key length, and algorithm.
• Nmap (nmap –script ssl-enum-ciphers) – identification of supported ciphers.
• testssl.sh – open-source script analyzing compliance with TLS 1.3, HSTS, and PFS.
• Zabbix/Prometheus – monitoring of port 443 and alerts in case of handshake errors.

6. Not using modern solutions – TLSA, DNSSEC, CAA, CT

Mechanisms supporting certificate security

• DNS CAA (Certification Authority Authorization): limits which CAs can issue certificates for a given domain.
• DNSSEC: cryptographically signs DNS records, preventing spoofing.
• TLSA (DANE): binds the certificate to a DNS record.
• Certificate Transparency (CT): a public log of all issued certificates — allows detection of unauthorized issuances.

Implementing these solutions significantly increases trust in certificates and helps meet audit requirements of major institutions (e.g. banks, government, e-commerce).

7. Outdated or incorrect certificate chains (Chain of Trust)

Problem

Errors in the trust chain configuration occur when the server does not send the full set of certificates (Root + Intermediate + Leaf). As a result, the browser cannot verify trust.

Symptoms

• Message “This certificate is not trusted.”
• No green padlock or chain error warning.
• Improper operation on mobile devices.

Solution

• Always install the full chain provided by the issuer.
• Verify correctness using openssl verify -CAfile fullchain.pem domain.crt.
• Check the configuration using SSL Checker (HEXSSL, SSL Labs).
• Ensure the intermediate certificates are up to date — CAs may update them without changing the end certificate.

Summary

A secure SSL/TLS implementation requires a combination of technical knowledge, automation, and continuous supervision. Even a single error — an expired certificate, mixed content, or weak cipher configuration — can lead to a loss of client trust or service unavailability.

Golden rules of SSL/TLS in 2025:

1. Use TLS 1.3 as a minimum.
2. Regularly renew certificates and monitor their validity.
3. Eliminate mixed content and enforce HTTPS across the entire domain.
4. Use only strong ciphers and PFS mechanisms.
5. Implement automated tests and configuration audits.
6. Protect private keys and maintain their registry.
7. Integrate WAF, monitoring, and DNSSEC/CAA in the security ecosystem.

👉 At HEXSSL we help companies implement and maintain the highest standards of encryption and online trust.
We offer:

• SSL/TLS certificates from trusted CAs,
• automatic expiry monitors,
• diagnostic tools (SSL Checker, CSR Verifier, Decoder),
• configuration audits and technical consulting.

Make sure your HTTPS truly means “secure.” Contact our team and learn how to implement an enterprise-class SSL/TLS policy.