When we talk about HTTPS, our first reaction is certificate. To securely encrypt communication, we have to deploy SSL/TLS certificates. For many developers, when they first come into contact with HTTPS, they often don't want to buy a formal certificate immediately, or just test it locally or in an intranet environment, so they will ask: Does Nginx support self-signed certificates? The answer is yes, no problem at all. But support does not mean "suitable for formal use".

　　Before talking about Nginx, let's first understand the meaning of certificates.

　　A self-signed certificate is a certificate you issue to yourself. That is, you generate a set of certificates and private keys with the OpenSSL tool yourself. Without third-party certification, the browser does not trust you. Advantages: free, easy to use, and generated immediately. Disadvantages are also very intuitive, the browser will warn "untrusted connection"

　　Formal certificates (issued by CA), browsers trust their root certificates by default. Advantages: automatic trust, no warnings, and a sense of security. Disadvantages are also very direct, free certificates must be renewed regularly, and paid certificates are expensive.

　　Does Nginx support self-signed SSL?

　　Yes, Nginx does not restrict the source of certificates. Whether you use Let’s Encrypt or a self-signed certificate manually generated by openssl, Nginx can run the same.

　　The core of Nginx’s SSL configuration is these two parameters:

ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;

　　As long as you have a set of .pem (certificate) and .key (private key), Nginx can run an HTTPS service for you.

　　Deploy Nginx HTTPS service with self-signed certificate

　　The following is a complete process, suitable for test environment or LAN application.

　　Step 1: Generate a self-signed certificate

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout self.key \
  -out self.crt \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=example.com"

　　This command will generate:

　　self.crt: public key certificate

　　self.key: private key

　　You can put it in any directory in your system, such as /etc/nginx/ssl/

　　Step 2: Configure Nginx to enable HTTPS

　　Modify or add configuration blocks:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/self.crt;
    ssl_certificate_key /etc/nginx/ssl/self.key;

    location / {
        root /usr/share/nginx/html;
        index index.html;
    }
}

　　Then test the configuration and restart Nginx:

nginx -t systemctl restart nginx

　　Visit https://example.com, it can be opened, but the browser will pop up "Connection is not secure", prompting that the certificate is not trusted.

　　This is normal, because self-signed certificates are not guaranteed by an authority.

　　When can you use a self-signed certificate?

　　Although the browser will warn, it does not mean that the self-signed certificate is wrong. In the following scenarios, it is a good helper:

　　1. Local development and debugging

　　You don't want to run the project with HTTP every time, and want to test whether the HTTPS interface is available. The self-signed certificate can immediately build HTTPS without registration or waiting.

　　2. Intranet service / self-built panel

　　For some management system panels, API gateways, etc., if you know the access source clearly (such as IP whitelist, fixed intranet domain name), you can use a self-signed certificate. Just skip the browser prompt.

　　3. Test HTTPS traffic and verify configuration files

　　Some configurations, such as HTTP/2. TLS1.3. OCSP Stapling, etc., are only valid after HTTPS is enabled. When you want to verify in advance, a self-signed certificate is the "best temporary tool".

　　If you just want to quickly enable HTTPS and verify a set of Nginx + TLS configurations, a self-signed certificate is an ideal choice. But if you are going to open the service to the outside world, it is strongly recommended to use a formally issued certificate.