SSL protocol and cipher configuration in Nginx - Step-by-Step Execution

Process Flow - SSL protocol and cipher configuration

Start nginx config

↓

Set ssl_protocols

↓

Set ssl_ciphers

↓

Reload nginx

↓

Client connects

↓

SSL handshake uses configured protocols and ciphers

↓

Connection established or rejected

The flow shows how nginx reads SSL protocol and cipher settings, reloads, then clients connect using those settings for secure communication.

Execution Sample

Nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

This config sets nginx to accept only TLS 1.2 and 1.3 protocols and use strong ciphers, preferring server choice.

Process Table

Step	Action	Configuration State	Effect on SSL Handshake
1	Read ssl_protocols	Protocols set to TLSv1.2, TLSv1.3	Only TLS 1.2 and 1.3 allowed
2	Read ssl_ciphers	Ciphers set to HIGH strength, exclude aNULL and MD5	Only strong ciphers accepted
3	Read ssl_prefer_server_ciphers	Server cipher preference enabled	Server chooses cipher from client's list
4	Reload nginx	New SSL settings active	Clients must use allowed protocols and ciphers
5	Client connects with TLS 1.2 and strong cipher	Handshake succeeds	Secure connection established
6	Client connects with TLS 1.0	Handshake fails	Connection rejected due to protocol
7	Client connects with weak cipher	Handshake fails	Connection rejected due to cipher

💡 Execution stops after client connection attempts show which protocols and ciphers are accepted or rejected

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
ssl_protocols	none	TLSv1.2, TLSv1.3	TLSv1.2, TLSv1.3	TLSv1.2, TLSv1.3	TLSv1.2, TLSv1.3
ssl_ciphers	none	none	HIGH:!aNULL:!MD5	HIGH:!aNULL:!MD5	HIGH:!aNULL:!MD5
ssl_prefer_server_ciphers	off	off	off	on	on

Key Moments - 3 Insights

Why does a client using TLS 1.0 fail to connect even if it supports some strong ciphers?

Because ssl_protocols only allows TLS 1.2 and TLS 1.3 (see execution_table step 6), the handshake fails due to unsupported protocol regardless of cipher strength.

What happens if ssl_prefer_server_ciphers is off?

The client chooses the cipher from its list, which may be weaker. With it on (step 3), the server picks the strongest cipher it supports, improving security.

Why exclude aNULL and MD5 ciphers in ssl_ciphers?

aNULL ciphers have no authentication and MD5 is weak. Excluding them (step 2) ensures only secure ciphers are used, preventing weak handshake security.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does nginx activate the new SSL settings?

A Step 4

B Step 2

C Step 6

D Step 1

💡 Hint

Check the 'Action' and 'Configuration State' columns for when nginx reloads to apply settings.

According to variable_tracker, what is the value of ssl_prefer_server_ciphers after step 3?

A on

B off

C none

D undefined

💡 Hint

Look at the ssl_prefer_server_ciphers row under 'After Step 3' column.

If you add TLSv1.1 to ssl_protocols, which step in execution_table would change?

A Step 5

B Step 7

C Step 1

D Step 4

💡 Hint

Adding TLSv1.1 changes the protocols set, which is reflected in the 'Configuration State' at step 1.

Concept Snapshot

nginx SSL config:
ssl_protocols TLSv1.2 TLSv1.3;  # Allowed SSL/TLS versions
ssl_ciphers HIGH:!aNULL:!MD5;    # Strong ciphers only
ssl_prefer_server_ciphers on;    # Server picks cipher
Reload nginx to apply changes.
Clients must use allowed protocols and ciphers to connect.

Full Transcript

This visual execution shows how nginx reads SSL protocol and cipher settings from its configuration. First, it sets allowed protocols to TLS 1.2 and 1.3, then sets strong ciphers excluding weak ones like aNULL and MD5. It enables server preference for cipher selection. After reloading nginx, these settings become active. When clients connect, only those using allowed protocols and ciphers succeed. Connections using older protocols or weak ciphers fail. Variables ssl_protocols, ssl_ciphers, and ssl_prefer_server_ciphers change step-by-step as nginx reads the config. Key moments clarify why protocol restrictions cause connection failures and why server cipher preference improves security. The quiz tests understanding of when settings activate and variable values during execution.

Practice

1. What is the purpose of the ssl_protocols directive in an nginx configuration?

easy

A. To specify which SSL/TLS protocol versions are allowed for secure connections

B. To define the encryption algorithms used for data compression

C. To set the maximum size of SSL certificates

D. To enable HTTP/2 support over SSL

Solution

1. Step 1: Understand the role of ssl_protocols

   The ssl_protocols directive controls which SSL/TLS versions nginx will accept for secure connections.

2. Step 2: Compare options with this role

   Only To specify which SSL/TLS protocol versions are allowed for secure connections correctly describes this purpose; others mention unrelated features like compression or HTTP/2.

3. Final Answer:

   To specify which SSL/TLS protocol versions are allowed for secure connections -> Option A

4. Quick Check:

   ssl_protocols = Allowed SSL/TLS versions [OK]

Hint: ssl_protocols controls TLS versions allowed [OK]

Common Mistakes:

• Confusing ssl_protocols with cipher settings
• Thinking ssl_protocols sets certificate size
• Assuming ssl_protocols enables HTTP/2

2. Which of the following is the correct syntax to enable only TLSv1.2 and TLSv1.3 in nginx?

easy

A. ssl_protocols tlsv12 tlsv13;

B. ssl_protocols tls1.2 tls1.3;

C. ssl_protocols TLSv1.2 TLSv1.3;

D. ssl_protocols TLS1_2 TLS1_3;

Solution

1. Step 1: Recall correct nginx ssl_protocols syntax

   The correct syntax uses capitalized TLS versions separated by spaces, ending with a semicolon, e.g., ssl_protocols TLSv1.2 TLSv1.3;.

2. Step 2: Check each option's format

   ssl_protocols TLSv1.2 TLSv1.3; matches the correct syntax exactly. Options A, B, and C use incorrect casing or underscores, which nginx does not accept.

3. Final Answer:

   ssl_protocols TLSv1.2 TLSv1.3; -> Option C

4. Quick Check:

   Correct syntax = ssl_protocols TLSv1.2 TLSv1.3; [OK]

Hint: Use exact case: TLSv1.2 TLSv1.3 with spaces [OK]

Common Mistakes:

• Using lowercase letters for TLS versions
• Replacing dots with underscores
• Missing semicolon at the end

3. Given this nginx snippet:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

What effect does ssl_prefer_server_ciphers on; have during SSL handshake?

medium

A. Client chooses the cipher from its list ignoring server preference

B. SSL handshake fails if client and server ciphers differ

C. Cipher selection is random between client and server lists

D. Server forces selection of its preferred cipher from the client's list

Solution

1. Step 1: Understand ssl_prefer_server_ciphers directive

   When set to on, nginx forces the server's cipher preference to override the client's during SSL handshake.

2. Step 2: Analyze options

   Server forces selection of its preferred cipher from the client's list correctly states the server enforces its cipher choice from the client's offered list. Client chooses the cipher from its list ignoring server preference is the opposite. Cipher selection is random between client and server lists is incorrect as selection is not random. SSL handshake fails if client and server ciphers differ is false; handshake does not fail just because of differing preferences.

3. Final Answer:

   Server forces selection of its preferred cipher from the client's list -> Option D

4. Quick Check:

   ssl_prefer_server_ciphers on = Server cipher priority [OK]

Hint: ssl_prefer_server_ciphers on means server picks cipher [OK]

Common Mistakes:

• Thinking client always chooses cipher
• Assuming random cipher selection
• Believing handshake fails on cipher mismatch

4. You configured nginx with:

ssl_protocols TLSv1.2 TLSv1.3
ssl_ciphers HIGH:!aNULL:!MD5
ssl_prefer_server_ciphers on;

But nginx fails to start. What is the likely cause?

medium

A. Missing semicolons at the end of directives

B. Using unsupported TLS versions

C. Incorrect cipher string syntax

D. ssl_prefer_server_ciphers must be off

Solution

1. Step 1: Check syntax of nginx directives

   Each directive must end with a semicolon. The given config lines miss semicolons at the end.

2. Step 2: Validate other options

   TLS versions and cipher strings are valid. ssl_prefer_server_ciphers can be on. So the syntax error (missing semicolons) causes nginx to fail.

3. Final Answer:

   Missing semicolons at the end of directives -> Option A

4. Quick Check:

   Missing semicolons cause config errors [OK]

Hint: Always end nginx directives with semicolon [OK]

Common Mistakes:

• Ignoring semicolon syntax errors
• Assuming TLS versions are unsupported
• Thinking ssl_prefer_server_ciphers must be off

5. You want to configure nginx to only allow TLSv1.3 and use strong ciphers, but also ensure clients that do not support TLSv1.3 can still connect securely using TLSv1.2. Which configuration snippet achieves this best?

hard

A. ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384;
ssl_prefer_server_ciphers on;

B. ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:HIGH:!aNULL;
ssl_prefer_server_ciphers on;

C. ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers off;

D. ssl_protocols TLSv1.3 TLSv1.1;
ssl_ciphers HIGH:!aNULL;
ssl_prefer_server_ciphers on;

Solution

1. Step 1: Identify required TLS versions

   We want to allow TLSv1.3 and TLSv1.2 to support clients without TLSv1.3.

2. Step 2: Check cipher configuration

   ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers TLS_AES_256_GCM_SHA384:HIGH:!aNULL; ssl_prefer_server_ciphers on; includes TLS_AES_256_GCM_SHA384 (a strong TLSv1.3 cipher) plus HIGH strength ciphers for TLSv1.2, with server cipher preference enabled.

3. Step 3: Validate other options

   ssl_protocols TLSv1.3; ssl_ciphers TLS_AES_256_GCM_SHA384; ssl_prefer_server_ciphers on; excludes TLSv1.2, blocking older clients. ssl_protocols TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers off; excludes TLSv1.3. ssl_protocols TLSv1.3 TLSv1.1; ssl_ciphers HIGH:!aNULL; ssl_prefer_server_ciphers on; includes insecure TLSv1.1, which is deprecated.

4. Final Answer:

   ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers TLS_AES_256_GCM_SHA384:HIGH:!aNULL; ssl_prefer_server_ciphers on; -> Option B

5. Quick Check:

   Allow TLSv1.2 and TLSv1.3 with strong ciphers = ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers TLS_AES_256_GCM_SHA384:HIGH:!aNULL; ssl_prefer_server_ciphers on; [OK]

Hint: Include TLSv1.2 and TLSv1.3 with strong ciphers [OK]

Common Mistakes:

• Excluding TLSv1.2 and blocking older clients
• Including deprecated TLS versions like TLSv1.1
• Not combining strong ciphers for both TLS versions