X.509 certificates: expiration, self-signed, wildcard and validation errors

X.509 certificates are the mechanism that lets a client verify the identity of the server it's connecting to. A certificate associates a public key with an identity (domain name) and is signed by a certificate authority (CA) the client trusts. Weaknesses in this mechanism enable man-in-the-middle attacks, where an attacker intercepts and decrypts communications without the client noticing.

Self-signed certificate

A self-signed certificate is not signed by any recognised certificate authority. Anyone can create a self-signed certificate for any domain. Browsers and clients display a warning, but users tend to ignore these, especially on internal or development interfaces that have "always worked this way".

Self-signed certificates are acceptable for local development. In production or on accessible internal interfaces, they must be replaced by certificates issued by a recognised CA. Let's Encrypt provides free, automatically renewable certificates for all internet-accessible domains. For internal domains, deploy an internal CA.

Expired certificate

An expired certificate generates warnings that users eventually ignore, exposing them to accepting future fraudulent certificates. This is called warning fatigue: a user used to clicking "Proceed anyway" will do so for a fraudulent certificate presented by an attacker. Beyond the security impact, an expired certificate breaks automatic connections (APIs, services, scripts) that don't ignore errors.

The solution: automate certificate renewal. Let's Encrypt with Certbot or ACME automatically renews 30 days before expiry. Set up monitoring alerts triggered at 30 days, 14 days, and 7 days before expiry.

Overly broad wildcard certificate

A wildcard certificate (*.example.com) covers all first-level subdomains, but not sub-subdomains. The security problem: if a subdomain is compromised, the attacker can use the private key associated with the wildcard to present a valid certificate for any other subdomain. A wildcard certificate is a key that opens every door of your domain.

Prefer SAN (Subject Alternative Names) certificates that explicitly list the covered domains. Reserve wildcards for cases where the number of subdomains is genuinely variable and dynamically managed.

Public key too short

RSA keys shorter than 2048 bits are considered insufficient. 1024-bit keys are breakable with moderate computational resources. The current standard is RSA-2048 minimum, with RSA-4096 or elliptic curves (ECDSA P-256 or Ed25519) recommended for new issuances. ECDSA P-256 offers security equivalent to RSA-3072 with a much shorter key.

Incorrect certificate validation

The most serious flaw is not in the certificate itself but in the code that validates it. Applications disable certificate verification to "simplify" HTTPS connections, especially in development, and forget to re-enable it in production. This is particularly common in mobile applications and integration scripts.

Dangerous validation disabling (Python Requests)

# Dangereux : ignore les erreurs de certificat
response = requests.get(url, verify=False)

# Correct : validation complète
response = requests.get(url)  # verify=True par défaut

# Pour une CA interne :
response = requests.get(url, verify='/path/to/ca-bundle.crt')

Summary

1. Certificates signed by a recognised CA: Let's Encrypt in production, internal CA for internal domains
2. Automate renewal: alert at 30 days, automatic renewal with ACME/Certbot
3. Prefer SANs over wildcards: explicitly list covered domains
4. RSA-2048 keys minimum: prefer ECDSA P-256 for new issuances
5. Never disable validation: properly configure internal CAs rather than bypassing verification