TLS (Transport Layer Security)secures communication (e.g., HTTPS) using certificates, per RFC 8446. A certificate includes:

Validity Period:Start and end dates (e.g., "Not After: March 8, 2025").

Purpose:Authenticates the server and encrypts the session.

Scenario:An expired TLS certificate (e.g., past "Not After" date). Modern browsers (e.g., Chrome, Firefox) validate certificates during the handshake:

ClientHello:Browser initiates TLS.

ServerHello:Server sends its certificate.

Validation:Browser checks expiration, CA trust, etc.

If expired, browsers reject the handshake, displaying errors (e.g., "NET::ERR_CERT_DATE_INVALID"). No session key is negotiated, andcommunication doesn’t proceed over TLS. Users may bypass warnings (e.g., "Advanced > Proceed"), but this is unencrypted or uses a fallback (not standard TLS), breaking security guarantees.

Security Implications:Expired certificates expose sites to MITM attacks, as trust is lost. CNSP likely emphasizes certificate management (e.g., automation with Let’s Encrypt) to avoid this.

Why other options are incorrect:

B. The communication is still over TLS:False; an expired certificate halts the TLS handshake in compliant browsers. Legacy systems might negotiate insecurely, but this isn’t "TLS" per standards.

Real-World Context:The 2019 Equifax breach partially stemmed from expired certificates missing vulnerabilities.References:CNSP Official Study Guide (TLS/SSL Security); RFC 8446 (TLS 1.3).