Nginx

Nginx is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server, originally written by Igor Sysoev.

Usage

The charm can be deployed using juju:

juju deploy nginx

Enable TLS

TLS is enabled when the ssl_cert (certificate) and ssl_key (private key) parameters are present, and ssl_ca (CA certificate) is optional. The values must be passed as base64 encoded strings.

$ juju config nginx \
  ssl_cert="$(base64 ./repo1.example.com.crt)" \
  ssl_key="$(base64 ./repo1.example.com.key)" \
  port=443

Validate TLS endpoint:

curl https://repo1.example.com -I
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 07 Apr 2022 18:25:00 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 21 Apr 2020 14:09:01 GMT
Connection: keep-alive
ETag: "5e9efe7d-264"
Accept-Ranges: bytes

Cryptography

The charm can optionally enable Transport Layer Security (TLS) to enhance security. Users can provide the following configuration parameters:

• ssl_cert: A base64-encoded SSL certificate for nginx to use.
• ssl_key: A base64-encoded SSL key to use in conjunction with the certificate specified as ssl_cert.
• ssl_ca: A base64-encoded SSL CA certificate to validate the provided certificate, in case a private CA is being used.

If both ssl_cert and ssl_key are provided, the charm will configure nginx config file at /etc/nginx/sites-enabled/nginx to enable TLS and use the provided certificate and key, ensuring encrypted communication.

For further details about how nginx uses TLS please refer to the upstream documentation.

Security Hardening Guidance

Enable TLS on Nginx

Enabling TLS ensures that the connection between clients and NGINX is encrypted, protecting sensitive data in transit (e.g., login credentials, session tokens, personal information) from interception.

To see how to configure depending if it uses a Certificate of Authority or if it’s Self-Signed, see the enable-tls documentation part.

By default nginx uses ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3 and ssl_ciphers HIGH:!aNULL:!MD5, so configuring them explicitly is generally not needed. See the upstream documentation for more information.

It’s recommended to use the TLSv1.3 wherever possible and for that is required to have OpenSSL version 1.1.1 or above.

If you have an old deployment and is not sure what TLS version Nginx is using, you can make a simple test:

openssl s_client -connect <NGINX_IP>:<NGINX_PORT> -tls1_3

If the above command fails, you can generate a new certificate using the TLSv1.3 see the OpenSSL upstream documentation for more details.

Expiration and Renewal

It’s important to rotate (or regenerate) the key pair (private and public key) periodically.

• Every 1–2 years: Even if the certificate itself hasn’t expired, key pairs should be rotated regularly for security purposes.
• High-security environments (e.g., financial institutions or sensitive data): Key pairs may be rotated more frequently, such as every 6–12 months.

Compromise or Change of Use

If you suspect a certificate or private key has been compromised, revoke the certificate and issue a new one immediately.