HTTPS Monitoring: Checking Beyond Certificate Validity

Most teams configure HTTPS monitoring to alert when a certificate expires. This catches the most obvious failure mode, but HTTPS security is a system — not just a certificate. A valid certificate doesn't mean your HTTPS configuration is correct, secure, or complete. Comprehensive HTTPS monitoring checks the entire system.

The HTTPS System Components

A properly configured HTTPS setup requires:

1. Valid certificate — Not expired, from trusted CA, covering the hostname
2. Complete chain — Intermediate certificates present and correct
3. Modern TLS version — TLS 1.2 minimum, TLS 1.3 preferred
4. Secure cipher suites — No deprecated or weak algorithms
5. HTTP → HTTPS redirect — HTTP requests redirected to HTTPS
6. HSTS header — Forces future connections to use HTTPS
7. No mixed content — All resources on HTTPS pages served via HTTPS
8. Security headers — Content-Security-Policy, X-Frame-Options, etc.
9. No certificate errors — No name mismatches, no self-signed certs in production

Each of these can be misconfigured independently of the others.

Certificate Monitoring (Beyond Just Expiry)

Certificate Chain Validation

The certificate chain must be complete: end-entity certificate → intermediate CA certificate(s) → trusted root CA.

Common chain problems:

Missing intermediate: Your server only sends your certificate, not the intermediate CA certificate. Some browsers can fetch missing intermediates, but many can't. Users on older clients or mobile devices may see certificate errors.

# Check certificate chain
openssl s_client -connect yoursite.com:443 -showcerts 2>/dev/null | \
  grep -E "Certificate chain|s:|i:"

# Expected output:
# Certificate chain
#  0 s:CN = yoursite.com
#    i:CN = Let's Encrypt Authority X3
#  1 s:CN = Let's Encrypt Authority X3
#    i:O = Digital Signature Trust Co., CN = DST Root CA X3

Cross-signed certificates: Some CAs issue certificates that chain to multiple roots for compatibility. Ensure your server presents the correct chain for maximum compatibility.

Hostname Matching

# Verify certificate covers the hostname being requested
openssl s_client -connect yoursite.com:443 2>/dev/null | \
  openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

# Expected output includes:
# DNS:yoursite.com, DNS:www.yoursite.com

Monitor that the certificate's Subject Alternative Names (SANs) include every hostname you serve via HTTPS.

TLS Version and Cipher Suite Monitoring

Deprecated Protocol Detection

TLS 1.0 and 1.1 are deprecated and disabled in modern browsers (Chrome 84+, Firefox 78+, Safari 13.1+). Servers that only support these old versions present connectivity issues for modern clients.

# Test TLS version support
testssl.sh --protocols yoursite.com

# Or using nmap
nmap --script ssl-enum-ciphers -p 443 yoursite.com

Monitor that your servers:

• Support: TLS 1.2, TLS 1.3
• Reject: TLS 1.0, TLS 1.1, SSLv3

Cipher Suite Security

Some cipher suites are deprecated due to cryptographic weaknesses:

Should not support:

• RC4 (broken, trivially breakable)
• 3DES (SWEET32 attack)
• Export-grade ciphers (deliberately weakened)
• NULL cipher suites (no encryption!)
• Anonymous cipher suites (no authentication)

Should support:

• AES-GCM with 128/256-bit keys (TLS 1.3 uses these exclusively)
• ECDHE key exchange (forward secrecy)
• ChaCha20-Poly1305 (good alternative for mobile performance)

HTTP to HTTPS Redirect Monitoring

Monitor that HTTP requests are correctly redirected to HTTPS:

# AzMonitor: Verify HTTP redirects to HTTPS
monitor:
  url: http://yoursite.com  # HTTP, not HTTPS
  expected_status: [301, 302, 307, 308]
  follow_redirects: false  # Check the redirect itself
  assert_redirect_to: "https://yoursite.com"  # Confirm correct destination

Common redirect problems:

• HTTP served instead of redirecting: Server accessible on port 80 without redirecting
• Redirect loop: HTTP redirects to HTTPS, HTTPS redirects to HTTP
• Wrong destination: Redirect to HTTP version of another domain
• Too many redirects: Multiple redirect hops add latency

HSTS (HTTP Strict Transport Security)

HSTS tells browsers to only access your site via HTTPS for a defined period. This prevents SSL stripping attacks and eliminates the "first visit" HTTP exposure window.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Monitor that HSTS is present on your HTTPS responses:

# AzMonitor: Check HSTS header presence
monitor:
  url: https://yoursite.com
  expected_headers:
    Strict-Transport-Security:
      contains: "max-age="
      minimum_max_age: 31536000  # At least 1 year

HSTS preloading: Submit your domain to the HSTS Preload List to have browsers hard-code HTTPS access before any visit. Monitor that your preload directive is present and max-age is at least 1 year.

Mixed Content Monitoring

Mixed content occurs when an HTTPS page loads resources via HTTP. Modern browsers block active mixed content (scripts, stylesheets) and warn on passive mixed content (images, media).

What triggers mixed content:

• Images referenced with http:// in CMS content
• Old hard-coded HTTP URLs in templates
• Third-party widgets that load HTTP sub-resources
• CDN assets still on HTTP after migrating to HTTPS

Detect mixed content with browser console:

// Run in browser console to check for mixed content
document.querySelectorAll('img, script, link, iframe').forEach(el => {
  const src = el.src || el.href;
  if (src && src.startsWith('http://')) {
    console.warn('Mixed content:', src);
  }
});

Detect in CI with Lighthouse: Lighthouse's "Uses HTTPS" audit catches mixed content issues automatically.

Security Headers Monitoring

Beyond HTTPS itself, security headers add additional protection layers:

| Header | Purpose | Monitoring | |--------|---------|-----------| | Content-Security-Policy | Prevents XSS | Check presence + no unsafe-inline | | X-Frame-Options | Prevents clickjacking | Must be DENY or SAMEORIGIN | | X-Content-Type-Options | Prevents MIME sniffing | Must be nosniff | | Referrer-Policy | Controls referrer info | Check appropriate policy | | Permissions-Policy | Restricts browser features | Check appropriate policy |

Monitor these headers on every check to catch regressions introduced by deployments or server configuration changes.

AzMonitor's HTTPS monitoring covers certificate validity, TLS configuration, redirect behavior, and response headers from 20+ global locations. Configure complete HTTPS monitoring and ensure your HTTPS implementation is as complete as it appears.

See also: TLS version monitoring for detailed TLS configuration guidance.