TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) provide encrypted communication between clients and servers, forming the security foundation of HTTPS. The TLS handshake establishes a secure connection through a multi-step process: the client sends a ClientHello listing supported cipher suites and TLS versions, the server responds with its certificate and chosen parameters, the client verifies the certificate and generates a pre-master secret encrypted with the server's public key, and both sides derive symmetric session keys for encrypting subsequent data. This process authenticates the server's identity and establishes encrypted communication in a fraction of a second.

Self-signed certificates are certificates where the issuer and subject are the same entity, meaning the certificate is signed with its own private key rather than by a trusted Certificate Authority. They are cryptographically identical to CA-signed certificates in terms of the encryption they enable: the TLS handshake proceeds the same way, and the resulting encrypted connection provides the same confidentiality and integrity guarantees. The critical difference is trust. Browsers maintain a curated list of trusted root CAs, and certificates signed by these CAs (or their intermediates) are automatically trusted. Self-signed certificates are not in any trust store, which is why browsers display security warnings when encountering them.

In development environments, self-signed certificates serve essential purposes. Many modern web APIs require a secure context (HTTPS) to function, including Service Workers, Geolocation, WebRTC, Web Crypto, and the Clipboard API. Developing with HTTP means these features are unavailable, creating a gap between the development and production environments. Self-signed certificates bridge this gap by enabling local HTTPS. Tools like mkcert simplify this process by creating a local CA, installing it in the system trust store, and generating certificates signed by that local CA, eliminating browser warnings during development while maintaining the untrusted status of these certificates outside the developer's machine.

The security distinction between self-signed and CA-signed certificates is paramount for production environments. CA-signed certificates provide identity verification: a trusted third party has confirmed that the certificate holder controls the specified domain. Self-signed certificates offer no such assurance because anyone can create one claiming to be any domain. In production, using a self-signed certificate would allow man-in-the-middle attacks because clients cannot verify the server's identity. Let's Encrypt, a free and automated Certificate Authority launched in 2015, has largely eliminated the cost and complexity barriers that once made self-signed certificates tempting for production use, issuing over 300 million active certificates and making properly trusted HTTPS accessible to everyone.