Security Nginx 1.27.4 Security Bug Fix CVE-2025-23419 Release

Nginx 1.27.4 mainline and 1.26.3 stable releases are out with security bug fix. Centmin Mod 131.00stable and 140.00beta01 have been updated to default to Nginx 1.27.4 for fresh installs.

However, existing Centmin Mod users if they are running older versions like 124.00stable or 130.00beta01, will need to update to latest Centmin Mod 131.00stable and 140.00beta01 releases as outlined at
https://community.centminmod.com/th...ase-with-almalinux-rocky-linux-support.25572/. Then run centmin.sh menu option 4, to update to Nginx 1.27.4 or 1.26.3.

For existing Centmin Mod 131.00stable and 140.00beta01 users, just running cmupdate command will get you latest updated code. Then run centmin.sh menu option 4, to update to Nginx 1.27.4 or 1.26.3.

Code (Text):

--------------------------------------------------------
     Centmin Mod Menu 131.00stable centminmod.com   
--------------------------------------------------------
1).  Centmin Install
2).  Add Nginx vhost domain
3).  NSD setup domain name DNS
4).  Nginx Upgrade / Downgrade
5).  PHP Upgrade / Downgrade
6).  MySQL User Database Management
7).  Option Being Revised (TBA)
8).  Option Being Revised (TBA)
9).  Option Being Revised (TBA)
10). Memcached Server Re-install
11). MariaDB MySQL Upgrade & Management
12). Zend OpCache Install/Re-install
13). Install/Reinstall Redis PHP Extension
14). SELinux disable
15). Install/Reinstall ImagicK PHP Extension
16). Change SSHD Port Number
17). Multi-thread compression: zstd,pigz,pbzip2,lbzip2
18). Suhosin PHP Extension install
19). Install FFMPEG and FFMPEG PHP Extension
20). NSD Install/Re-Install
21). Data Transfer
22). Add Wordpress Nginx vhost + Cache Plugin
23). Update Centmin Mod Code Base
24). Exit
--------------------------------------------------------
Enter option [ 1 - 24 ] 4
--------------------------------------------------------

Code (Text):

Nginx Upgrade - Would you like to continue? [y/n] y
Current Nginx Version: 1.27.4 (050225-201824-almalinux9-kvm-7545125)

Install which version of Nginx? (version i.e. type 1.27.2): 1.27.4

Do you still want to continue? [y/n] y

• Nginx 1.27.4 https://nginx.org/en/CHANGES
• Nginx 1.26.3 https://nginx.org/en/CHANGES-1.26

---

 

Nginx Security Bug CVE-2025-23419 Explained

If you run Centmin Mod Nginx behind Cloudflare CDN Orange cloud-enabled proxy, you are most likely already protected from this security bug. It is advisable to upgrade Nginx anyway.

The security fix addresses a vulnerability (CVE-2025-23419) in which, under TLSv1.3, a client’s SSL session could be reused across virtual servers. In the affected versions before 1.27.4, if a client had an established SSL session on one virtual server, that session could potentially be presented to a different virtual server - even one requiring its own client certificate verification - thus bypassing that security check.

What Was the Problem?

• Vulnerability: In TLSv1.3, during the handshake when using Server Name Indication (SNI), the session’s hostname was not being strictly verified. This allowed a client to reuse an SSL session from one virtual server in the context of another virtual server.
• Security Impact: This flaw could let a client bypass the intended verification of client SSL certificates on a virtual server that requires them.

How Was It Fixed in Nginx 1.27.4 and 1.26.3 ?

• Hostname Check Added: In the updated code (for example, in the SSL servername handling functions), the patch now retrieves the hostname from the SSL session (using SSL_SESSION_get0_hostname) and compares it with the server name requested via SNI.
• Handshake Rejection: If the hostname from the session does not match the SNI value of the current virtual server - and client verification is enabled - the handshake is rejected. This prevents an SSL session established for one server from being used to bypass certificate verification on another server. This extra check ensures that an SSL session cannot “migrate” from one virtual server to another when client certificate verification is expected.

In Summary

• The Vulnerability: Allowed reuse of an SSL session in a different virtual server to bypass client certificate verification.
• The Fix (in Nginx 1.27.4 and 1.26.3 ): Adds an explicit check on the SNI hostname - rejecting a connection if the hostname in the SSL session doesn’t match the requested virtual server’s name.
• For Older Versions: If you are running an older nginx release with TLSv1.3 and the affected SSL libraries, you remain vulnerable to CVE-2025-23419. Upgrading to 1.27.4 (or later) is advisable to ensure this security check is in place.

This patch significantly reduces the risk of an attacker exploiting session reuse to bypass security measures tied to SSL client certificate verification in virtual server configurations.

 

Nginx 1.27.4 New Feature SSL Certificate Caching

Nginx 1.27.4 also introduced a new feature to support SSL certificate caching, Optimizing Resource Usage for Complex SSL Configurations in NGINX – NGINX Community Blog which I have optionally enabled support for in Centmin Mod 140.00beta01 only. It's disabled by default and you can see the details at https://community.centminmod.com/th...ssl-cert-cache-support-in-140-00beta01.27383/.

In Centmin Mod 140.00beta01 or newer, you can enable optional SSL certificate caching by setting in persistent config file /etc/centminmod/custom_config.inc the below variables (latter 2 are optional) and then run centmin.sh menu option 4 to recompile/update to Nginx 1.27.4:

Code (Text):

NGINX_SSL_CACHE='y'
NGINX_SSL_CACHE_COUNT='1000'
NGINX_SSL_CACHE_TTLS='1m'

Below is a summary of the changes introduced in version 1.27.4 with a focus on the new SSL certificate caching functionality and an explanation of what the cache is for, what it stores, how it is updated, and which configuration variables control it.

Overview of the New SSL Certificate Cache Feature

• New Directives and Functions: Several new directives were added (for example, ssl_certificate_cache, proxy_ssl_certificate_cache, grpc_ssl_certificate_cache, and uwsgi_ssl_certificate_cache) along with a related flag (ssl_object_cache_inheritable). These let you enable and fine-tune caching of SSL objects across different parts of nginx (HTTP, stream, grpc, proxy, uwsgi).
• Purpose: The SSL certificate cache is designed to store and re‑use parsed SSL objects (such as X.509 certificate chains and private keys) so that they do not need to be re‑read and re‑parsed for every new connection. This can improve performance—especially on busy servers where many TLS handshakes occur—and help avoid some certificate‐mismatch issues in cache update scenarios.

What Is Being Cached?

• Cached Objects:
The cache stores SSL certificate data and private keys (and, in some cases, other related objects). In the code these are referenced by cache “types” such as NGX_SSL_CACHE_CERT and NGX_SSL_CACHE_PKEY. Essentially, the cache holds:
• The parsed certificate chain (X.509 objects)
• The parsed private key (EVP_PKEY)

• Cache Data Structure:
The new cache uses an internal data structure (ngx_ssl_cache_t) that includes:
• An rbtree (red–black tree) for fast lookup of cached items.
• An expire queue (a linked queue) for managing expiration based on time.
• Fields to track the number of cached items (current) and the maximum allowed (max).
• Timing parameters (valid and inactive) that control how long a cached item is considered fresh.

How the SSL Certificate Cache Works

1. Cache Initialization:

A new function, ngx_ssl_cache_init(), creates and initializes the cache. When invoked (for example, during configuration parsing via the new directives), it allocates an ngx_ssl_cache_t structure and initializes:

• An rbtree (with a custom insert function) to store nodes.
• An expiration queue that is used to track when objects were last accessed.
• The cache limits: the maximum number of items (max), the time a cache entry is considered valid (valid), and an inactivity timeout (inactive).

2. Fetching from the Cache:

When an SSL connection is being established, functions like ngx_ssl_cache_connection_fetch() are used to look up (or create) the needed certificate or private key:

• They generate a cache key based on the file path (or other identifier) and look it up in the rbtree.
• If a matching cache entry exists and it is still “fresh” (i.e. not older than the valid or inactive thresholds), the cached value is returned.
• If the entry is expired (or if a “mismatch” is detected in the case of a key-certificate pair), the code will call the object’s “create” callback to re‑load the certificate or key, update the cache, and return the new value.
• There is also a mechanism (using a “mask” flag, for example NGX_SSL_CACHE_INVALIDATE) to force invalidation and reload of the cache entry if needed.

3. Cache Expiration:

The function ngx_ssl_cache_expire() walks the expire queue and removes cached entries that have not been accessed recently (beyond the configured inactive timeout) or that have exceeded the valid time. This helps prevent the cache from growing indefinitely and ensures that certificate files are re‑loaded if updated on disk.

4. Inheritance Between Cycles:

The new flag and directive ssl_object_cache_inheritable allow the cache to be inherited from an “old” configuration cycle into a new one. This means that even if nginx reloads its configuration, it may reuse previously cached SSL objects (if they are still valid), thus avoiding unnecessary re‑parsing of certificates and keys.

Configuration Variables and Their Roles

When configuring an SSL certificate cache (in HTTP, stream, grpc, proxy, or uwsgi contexts), you typically supply parameters that control the cache’s behavior. For example, in a directive you might see parameters such as:
• max: This parameter specifies the maximum number of items (cache nodes) that the cache can hold. It is mandatory for the cache to be enabled. For example:

Code (Text):

ssl_certificate_cache max=100

This means that up to 100 SSL certificate (or key) objects may be cached.
• valid: This parameter sets the “valid” time (in seconds or with a time unit) during which a cached object is considered fresh. If a cache entry’s age exceeds this value, it will be updated. For example:

Code (Text):

ssl_certificate_cache valid=60

(A valid period of 60 seconds.)
• inactive: This parameter specifies the inactivity timeout. If a cached item has not been accessed within this period, it will be eligible for expiration even if it has not reached the “valid” age limit. For example:

Code (Text):

ssl_certificate_cache inactive=10

(After 10 seconds of inactivity, an item may be removed.)
• off: Passing the parameter "off" disables the cache in that context.

These parameters are parsed in the various module configuration functions (for example, in the SSL module for HTTP, as well as in the proxy, grpc, uwsgi, and stream modules). The parsed values are then used to initialize the cache via ngx_ssl_cache_init().

Summary of Key Points Regarding SSL Certificate Cache

• Purpose: The cache avoids repeated file I/O and parsing of certificate and key files during each TLS handshake, which can improve performance.
• What’s Cached: Parsed SSL certificates (X.509 chains) and private keys.
• Mechanism:
• An rbtree provides fast lookups.
• An expire queue manages time‑based invalidation.
• On cache lookup, if an entry exists and is valid, its reference is returned. Otherwise, the certificate or key is re‑loaded, the cache is updated, and the new value is returned.
• Control Variables:
• max: Limits the number of cached objects.
• valid: Specifies how long an object is considered fresh.
• inactive: Specifies the inactivity period after which an object is expired.
• Inheritance: The ssl_object_cache_inheritable flag allows the cache to be carried over between configuration reloads, thereby further reducing overhead.

This set of changes provides a more efficient way to manage SSL certificate and key loading, especially under high connection rates or when certificates are updated, by reusing previously loaded objects when appropriate.