Are self-signed certificates actually usable? Different answers for intranet environments, development/testing, and public websites.

　　In internet security, SSL/TLS certificates are crucial for ensuring encrypted data transmission and verifying server identity. Many beginners or small projects consider using self-signed certificates when setting up HTTPS services, but often hear statements like "self-signed certificates are unusable" or "self-signed certificates are usable." In reality, the suitability of self-signed certificates depends on the use case; the needs of intranet environments, development and testing environments, and public websites differ.

　　First, let's clarify the concept of a self-signed certificate. A self-signed certificate is a certificate generated and signed by oneself, rather than by a trusted Certificate Authority (CA). Technically, it is not fundamentally different from a CA-signed certificate: it contains a public key, private key, certificate validity period, domain information, etc. However, the difference is that self-signed certificates are not recognized by the browser or operating system's root trust list. Therefore, by default, browsers will display an "untrusted certificate" warning and may block access. This is why many people believe self-signed certificates are "unusable."

　　In an intranet environment, self-signed certificates usually meet the requirements perfectly. In enterprise internal systems, test servers, or development environments, access targets are mostly controlled devices and users, and trust relationships can be managed centrally. In this context, self-signed certificates can provide complete encryption, protecting data transmission security and preventing man-in-the-middle attacks. For example, in internal API communication, internal management backends, and intranet database access, secure connections can be established by importing self-signed certificates on various clients or servers, eliminating the need to purchase commercial CA certificates. The advantage of intranet environments is that the trust chain can be manually managed; browsers or clients can directly trust self-signed certificates, thus eliminating "untrusted" warnings. It's important to note that if the enterprise intranet involves cross-departmental or cross-system communication, a unified certificate management strategy is needed to avoid system interruptions due to expired or inconsistent certificates.

　　Self-signed certificates are also very common in development and testing environments. Development teams typically set up test servers locally or on the internal network to debug HTTPS functionality or verify encrypted transmissions. Self-signed certificates are virtually costless and quick to generate, making them ideal for rapid iteration and continuous integration scenarios. Developers can configure browsers to ignore certificate warnings or import certificates on test machines to ensure clients can access the service correctly. Self-signed certificates can also be used in automated testing environments, such as simulating TLS communication between clients and servers, testing certificate update logic, and verifying the correctness of HTTPS configurations. In this scenario, the integrity of the certificate's trust chain is not the primary concern; the main purpose is to ensure encrypted transmission and functional verification within the testing environment.

　　However, self-signed certificates are largely unsuitable for public websites or services targeting end users. This is because most browsers, operating systems, and mobile devices only trust certificates issued by trusted Certificate Authorities (CAs). If a website uses a self-signed certificate, users will see obvious security warnings such as "Your connection is not secure" or "Certificate is not trusted," and some browsers may even block users from continuing access. This severely impacts the website's user experience and user trust. For e-commerce websites, online payment platforms, SaaS services, or any public-facing internet service, self-signed certificates are almost unusable; certificates issued by trusted CAs must be used. Furthermore, search engines have scoring mechanisms for HTTPS security, and self-signed certificates may negatively affect SEO.

　　From a security perspective, self-signed certificates are no different from CA certificates in terms of encryption strength, still providing end-to-end encryption and protection against man-in-the-middle attacks. However, due to the lack of a third-party trust chain, users cannot verify the server's identity, which is the fundamental reason why self-signed certificates are not accepted in public network environments. For internal or testing environments, this issue can be resolved by importing a root certificate or configuring client trust. However, this approach is not feasible on public-facing websites because it is impossible to control the trust chain across all user devices.

　　Furthermore, several issues need to be considered when managing self-signed certificates. First, the certificate validity period should be set appropriately to avoid service interruptions due to expiration. Second, the security of the private key must be strictly guaranteed; otherwise, certificate leakage could lead to man-in-the-middle attacks. Third, if the self-signed certificate is used for communication between multiple servers, a unified root certificate needs to be generated and the public key distributed to ensure a consistent trust chain. For enterprises or development teams, establishing an internal PKI system can better manage self-signed certificates, enabling batch generation, updates, and revocation.

　　In recent years, with the widespread availability of free CA certificates like Let's Encrypt, even test or small public websites can use trusted certificates to achieve zero-cost HTTPS deployment. This has somewhat reduced the practical value of self-signed certificates in public network scenarios, as the high cost no longer hinders the use of official certificates. Relatively speaking, the advantages of self-signed certificates lie mainly in complete self-control, no reliance on external organizations, and the ability to be quickly generated and used in controlled environments.

　　In conclusion, whether self-signed certificates are usable depends on the usage scenario. For intranet environments and development/testing, self-signed certificates are perfectly usable and can provide sufficient encryption protection. For public websites facing end users, self-signed certificates are unusable because user trust cannot be established; browsers and systems will issue security warnings, impacting user experience and business security. Understanding the limitations of self-signed certificates and the principles of trust chains can help developers make appropriate choices in different scenarios, ensuring data security while avoiding unnecessary user inconvenience.