Complete Guide to Generating Self-Signed SSL Certificates Using OpenSSL

Fundamental Concepts of Self-Signed SSL Certificates

A self-signed SSL certificate is a digital certificate not signed by any public or private certificate authority, but rather signed using the creator's own private key. This type of certificate holds significant value in development testing environments, internal network applications, and embedded devices, as it eliminates the need for payments to third-party CAs and complex verification processes.

Limitations of Traditional Generation Methods

When configuring HTTPS support on embedded Linux devices, developers typically employ multi-step methods to generate self-signed certificates:

openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem

While this approach can produce functional certificates, it has notable drawbacks. The generated certificates trigger security warnings in modern browsers like Google Chrome, displaying messages such as "This site's security certificate is not trusted." This occurs because browsers use predefined trust anchor lists to validate server certificates, and self-signed certificates cannot chain back to these trusted anchors.

Modern Single-Command Generation Approach

OpenSSL offers a more streamlined single-command generation method that completes both private key generation and certificate creation in one step:

# Interactive generation with 365-day validity
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365

# Non-interactive generation with 10-year validity
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"

This method's advantage lies in simplifying the operational workflow and reducing the potential for errors. The -nodes parameter indicates that the private key should not be password-protected, which is more practical in server deployment scenarios as it avoids the need for manual password entry during each restart.

Detailed Parameter Configuration

When generating self-signed certificates, several critical parameters require proper configuration:

Key Algorithm Selection: RSA 4096-bit is currently the recommended security strength, providing adequate encryption protection. For specific scenarios, ECC algorithms can also be considered:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 -days 3650 -nodes -keyout key.pem -out cert.pem -subj "/CN=example.com"

Validity Period Setting: Since self-signed certificates require manual acceptance, they typically have longer validity periods, such as 10 years (3650 days), to minimize frequent redeployment.

Subject Information Configuration: The -subj parameter allows specification of certificate subject information, including country code, state name, city, organization name, etc. For development testing environments, this can be simplified to include only the common name:

-subj '/CN=localhost'

Browser Compatibility Handling

Modern browsers have increasingly strict requirements for SSL certificates, particularly regarding Subject Alternative Name (SAN) extensions. Starting from OpenSSL 1.1.1, SAN can be added directly via command line:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout example.com.key -out example.com.crt -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:*.example.com,IP:10.0.0.1"

This configuration produces certificates that support multiple domain names and IP addresses, meeting modern browser validation requirements. For older OpenSSL versions (≤1.1.0), configuration files must be used to achieve the same functionality.

Practical Application Scenarios

In embedded device development, self-signed certificates are primarily used for: internal network communication encryption, secure access to device management interfaces, and HTTPS validation in development testing environments. Since these scenarios typically do not involve public internet access, browser trust issues can be resolved by importing CA certificates into devices or browsers.

For production environments requiring higher security, certificates signed by trusted CAs are recommended, or establishing internal PKI infrastructure to issue and manage certificates through self-built CAs.

Security Considerations

When using self-signed certificates, several precautions are essential: private keys must be stored securely to prevent leakage; certificate validity periods should be set appropriately to balance security and maintenance costs; in public networks, self-signed certificates are vulnerable to man-in-the-middle attacks, thus they are recommended only in controlled environments.

With proper configuration and correct usage, self-signed certificates generated by OpenSSL can provide reliable TLS encryption protection for embedded devices and internal applications.