TLS certificates are the foundation of encrypted communication. When they're correct, they're invisible. When they expire, they take down your site. When they're misconfigured, they undermine the security they're supposed to provide.
Certificate management is rarely a priority until it causes an incident. This post covers everything you need to prevent the common failures.
What Certificate Failures Look Like
Expiry: The most visible failure. Your site shows a browser security warning. Users bounce. Operations team scrambles. This is completely preventable with automated monitoring.
Weak cipher suites: Your server supports TLS 1.0/1.1 or RC4 ciphers. Connections appear "secure" (padlock icon present) but are vulnerable to known attacks. This is not visible to users but detectable by scanners.
Certificate/hostname mismatch: Certificate issued for www.yourapp.com but served at api.yourapp.com. Browser shows security error. Often happens after domain migrations or improper wildcard certificate deployment.
Self-signed or private CA certificates: Acceptable for internal services but a red flag if served to external users. Indicates either a man-in-the-middle setup or a development certificate accidentally deployed to production.
Certificate transparency violations: Certificates issued by unauthorized CAs for your domain. Detectable via CT logs (crt.sh). Indicates either CA compromise or unauthorized certificate issuance.
TLS Configuration Hardening
A properly configured TLS endpoint should score A+ on SSL Labs. The requirements:
Protocol Versions:
ssl_protocols TLSv1.2 TLSv1.3; # disable TLS 1.0 and 1.1
TLS 1.0 is vulnerable to POODLE and BEAST attacks. TLS 1.1 has no known practical attacks but is deprecated. TLS 1.3 should be preferred where browser support allows.
Cipher Suites:
ssl_ciphers ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:!aNULL:!MD5:!3DES;
ssl_prefer_server_ciphers on;
Exclude: RC4, 3DES, aNULL (no auth), eNULL (no encryption), EXPORT ciphers, MD5.
Perfect Forward Secrecy (PFS): ECDHE and DHE key exchange ensures that past session traffic cannot be decrypted even if the server's private key is later compromised. Ensure cipher suites use ECDHE or DHE key exchange.
HSTS (HTTP Strict Transport Security):
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
HSTS instructs browsers to only use HTTPS for your domain for the max-age duration. Without HSTS, SSL-stripping attacks can downgrade connections to HTTP.
OCSP Stapling:
ssl_stapling on;
ssl_stapling_verify on;
OCSP stapling improves connection performance and privacy by allowing the server to provide revocation status directly, eliminating client-side OCSP lookups.
Certificate Lifecycle Automation
Manual certificate renewal is a single-point-of-failure process. The only sustainable approach is full automation.
Option 1: Let's Encrypt + Certbot (free, automated)
# Initial setup
certbot --nginx -d yourapp.com -d www.yourapp.com
# Auto-renewal cron (runs twice daily, renews if < 30 days)
0 */12 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"
Let's Encrypt certificates expire every 90 days. Certbot's auto-renewal ensures they're renewed at 60 days (30-day buffer).
Option 2: AWS ACM (managed, auto-renews)
AWS Certificate Manager automatically renews certificates it manages. If you're deploying behind CloudFront, ALB, or API Gateway, ACM is the zero-maintenance option.
resource "aws_acm_certificate" "app" {
domain_name = "yourapp.com"
subject_alternative_names = ["www.yourapp.com", "api.yourapp.com"]
validation_method = "DNS"
lifecycle {
create_before_destroy = true
}
}
ACM handles renewal automatically for certificates deployed to AWS services. Certificates not deployed to an AWS service don't auto-renew.
Option 3: Certificate Pinning (mobile apps)
For mobile applications that communicate with known API endpoints, certificate pinning validates the server's certificate against a hardcoded expected value, preventing MitM attacks even from trusted CAs.
Implementation requires an expiry rotation plan — pinned certificates must be updated in app releases before they expire. A 2-year certificate with a 90-day advance rotation window is a common pattern.
Certificate Monitoring Strategy
The goal: know about every certificate issue before your users do.
Expiry Monitoring: Monitor all certificates on your external surface for expiry dates. Alert at:
- 90 days: informational (renewal scheduled?)
- 30 days: warning (trigger renewal if not automated)
- 14 days: urgent (renewal likely failed, manual intervention required)
- 7 days: critical (service disruption imminent)
Certificate Transparency (CT) Monitoring:
CT logs record every publicly issued certificate. Monitoring CT logs for your domains detects:
- Certificates you didn't issue (possible MitM or unauthorized issuance)
- Certificates issued for subdomains you didn't know existed (discovery)
- Expired certificates being presented (deployment issue)
Tools: crt.sh, Facebook CT Monitor, Certspotter.
Configuration Drift Monitoring:
TLS configuration can change without notice — nginx config updates, CDN configuration changes, new services deployed. Scan TLS configuration on a schedule and alert on any degradation (new weak cipher suites added, HSTS removed, TLS 1.0 re-enabled).
PentestCheck Certificate Monitoring
PentestCheck's EASM Engine continuously monitors:
- All certificates on discovered external assets
- Expiry dates with multi-threshold alerting
- TLS protocol versions and cipher suite quality
- Certificate/hostname mismatches
- Self-signed certificate detection
- HSTS presence and configuration
- CT log monitoring for new certificates on your domains
Certificate findings surface alongside vulnerability findings in the same Threat Score calculation — a certificate with < 14 days to expiry affecting a production API is a HIGH finding that contributes to your score.
Certificate expiry and TLS misconfiguration findings are included in every PentestCheck EASM scan. Set up monitoring for your domains in under 2 minutes.