When browsers display certificate errors (like domain mismatch, expired certs, or untrusted CAs), many developers wonder about the actual encryption status. The critical distinction lies between authentication and encryption in the TLS handshake process.

Here's what happens at the protocol level:

ClientHello → 
ServerHello → 
Certificate* → 
ServerKeyExchange → 
CertificateRequest* → 
ServerHelloDone → 
ClientKeyExchange → 
CertificateVerify* → 
Finished

The asterisked (*) steps involve certificate verification. Even if these fail, the key exchange and encryption setup still complete.

You can test this behavior using OpenSSL's s_client:

openssl s_client -connect example.com:443 -servername example.com \
  -verify_return_error -status -tlsextdebug

When forcing a connection to a mismatched domain:

openssl s_client -connect wrong.host.com:443 -servername real.host.com

Major browsers maintain encryption despite cert errors:

• Chrome: "Your connection is not private" but data remains encrypted
• Firefox: "Warning: Potential Security Risk Ahead" with continued TLS
• Safari: "This Connection Is Not Private" with active padlock icon

While encryption persists, consider these risks:

// Dangerous practice in production code
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"; 

// Better approach for testing only
const https = require('https');
const agent = new https.Agent({ 
  rejectUnauthorized: false // ONLY for development!
});

Certificate errors create opportunities for:

• DNS spoofing with valid cert for wrong domain
• Compromised CAs issuing fraudulent certificates
• Self-signed certs in internal attacks

Always implement certificate pinning in sensitive applications:

// Node.js certificate pinning example
const tls = require('tls');
const pins = new Set([
  'sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='
]);

tls.checkServerIdentity = (hostname, cert) => {
  const fingerprint = cert.fingerprint256;
  if (!pins.has(fingerprint)) {
    throw new Error(Certificate pinning violation for ${hostname});
  }
};

When encountering SSL/TLS certificate errors (e.g., domain mismatch, expired cert, or untrusted CA), many developers wonder whether the encrypted tunnel remains intact. The short answer: yes, the encryption persists, but trust verification fails.

HTTPS operates in two distinct phases:

1. Key Exchange: Uses asymmetric encryption (RSA/ECDHE) to establish a shared secret
2. Data Transfer: Uses symmetric encryption (AES) for actual communication

The certificate only participates in phase 1 for identity verification.

Here's how to verify encryption persists using OpenSSL:

openssl s_client -connect example.com:443 -servername example.com \
  -showcerts < /dev/null 2>/dev/null | grep "Cipher is"

This will show active encryption even with certificate warnings.

While encryption remains, certificate errors indicate potential risks:

• Man-in-the-middle attacks
• Phishing attempts
• Compromised private keys

Modern browsers implement certificate pinning to mitigate these risks.

When handling certificate errors programmatically:

// Node.js example with certificate validation bypass
const https = require('https');
const agent = new https.Agent({
  rejectUnauthorized: false // DANGEROUS in production!
});

// Use only for debugging/internal tools
https.get('https://invalid-cert.example.com', { agent }, (res) => {
  // Encrypted but unverified connection
});

Legitimate cases for bypassing certificate checks include:

• Internal development environments
• Testing CI/CD pipelines
• Corporate proxy scenarios

Always implement proper certificate validation in production code.