Operations 9 min read

Why a Weird Nginx Reset Was Not Caused by the SSL Certificate

After adding an HTTPS certificate the site worked in browsers but curl requests were reset; through step‑by‑step network captures, buffer tweaks, cipher experiments and finally adding the missing ssl_session_cache directive, the author discovered the true cause and documented common Nginx error messages.

Linux Tech Enthusiast
Linux Tech Enthusiast
Linux Tech Enthusiast
Why a Weird Nginx Reset Was Not Caused by the SSL Certificate

The site was launched with an HTTPS certificate; browsers accessed it normally, but a curl request was reset, as shown in the first screenshot.

Initial diagnostics confirmed that HTTP on port 80 worked, other HTTPS domains on the same server responded correctly, and the certificate was valid (checked via myssl.com ).

Suspecting the cipher suite, the author added a long compatibility list:

"ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"

but the problem persisted.

Using tcpdump and Wireshark (see second screenshot), the author observed that the TLS handshake completed, then the first ACK after data transmission was reset, suggesting a possible buffer issue. Client‑side buffer settings were increased:

client_header_buffer_size 64k;
large_client_header_buffers 4 64k;
client_body_buffer_size 20m;
keepalive_timeout 120;

yet the reset remained.

Switching to an ECC certificate produced a new error:

curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).

Research revealed that on RedHat/CentOS the default curl uses the NSS library, which disables ECC. Specifying a cipher suite manually, e.g. curl --ciphers ecdhe_rsa_aes_128_gcm_sha_256 …, still did not resolve the reset, indicating the issue was unrelated to the certificate.

Comparing other sites' Nginx configurations, the author noticed the missing ssl_session_cache directive. Adding it (either builtin or shared) stopped the reset. The directive has four possible values:

off : disables session caching.

none : tells the client a session may be reused but does not store it.

builtin : uses an in‑process OpenSSL cache (default ~20 000 sessions).

shared : creates a shared memory cache; size is specified in bytes (1 MiB ≈ 4000 sessions) and can be named for reuse across virtual servers.

The author recommends the shared option for better performance.

Further packet analysis showed that the failing connection included a Server Key Exchange step (Diffie‑Hellman), which is optional and can fail when the server does not provide the required parameters. Adding ssl_session_cache eliminated the reset, though the exact interaction remains unclear.

For reference, the article lists common Nginx error‑log messages (e.g., "upstream prematurely closed connection", "recv() failed (104: Connection reset by peer)", "SSL_do_handshake() failed", etc.) with brief explanations.

Additional notes: tcpdump can capture packets, but Wireshark is needed for detailed analysis; ECC certificates are smaller and faster than RSA and are recommended when supported.

NginxWiresharkcurltcpdumpssl_session_cache
Linux Tech Enthusiast
Written by

Linux Tech Enthusiast

Focused on sharing practical Linux technology content, covering Linux fundamentals, applications, tools, as well as databases, operating systems, network security, and other technical knowledge.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.