Version
5.4.3
What Kubernetes platforms are you running on?
Other
Steps to reproduce
- configure a
VirtualServer attached to an IngressMTLS policy
- modify the secret referenced in the policy's
clientCertSecret
- observe that nginx is still uses the old Certificate (can be validated by using
openssl s_client -connect <host>:443 -prexit, examining Acceptable client certificate CA names)
Analysis:
When the CA Secret referenced by a Policy resource's ingressMTLS block is updated (e.g. to rotate the CA certificate), the on-disk CA file is rewritten but NGINX continues to use the previously-loaded CA in memory until some unrelated event triggers a reload. This can leave clients authenticating against a stale CA for an indeterminate amount of time.
With ssl-dynamic-reload enabled (the default), handleSecretUpdate only reloads NGINX when the rendered config bytes change. The ssl_client_certificate directive uses a static file path, so a CA secret update rewrites the file on disk without changing the rendered config — and the reload is skipped.
Dynamic SSL reload only covers the server cert directives (ssl_certificate / ssl_certificate_key) via the variable-path mechanism; ssl_client_certificate is parsed into NGINX memory at config-load time and requires a reload to pick up new content.
Proposed fix: #10003
embed a stable SHA-256 digest of the secret's Data payload in the rendered NGINX config as a comment adjacent to the ssl_client_certificate directive. When the CA secret is rotated the digest changes, the rendered config differs, the existing configsChanged detection path picks it up, and a reload is triggered. Dynamic SSL reload for server certs is left untouched.
Version
5.4.3
What Kubernetes platforms are you running on?
Other
Steps to reproduce
VirtualServerattached to anIngressMTLSpolicyclientCertSecretopenssl s_client -connect <host>:443 -prexit, examiningAcceptable client certificate CA names)Analysis:
When the CA Secret referenced by a Policy resource's ingressMTLS block is updated (e.g. to rotate the CA certificate), the on-disk CA file is rewritten but NGINX continues to use the previously-loaded CA in memory until some unrelated event triggers a reload. This can leave clients authenticating against a stale CA for an indeterminate amount of time.
With ssl-dynamic-reload enabled (the default), handleSecretUpdate only reloads NGINX when the rendered config bytes change. The ssl_client_certificate directive uses a static file path, so a CA secret update rewrites the file on disk without changing the rendered config — and the reload is skipped.
Dynamic SSL reload only covers the server cert directives (ssl_certificate / ssl_certificate_key) via the variable-path mechanism; ssl_client_certificate is parsed into NGINX memory at config-load time and requires a reload to pick up new content.
Proposed fix: #10003
embed a stable SHA-256 digest of the secret's Data payload in the rendered NGINX config as a comment adjacent to the ssl_client_certificate directive. When the CA secret is rotated the digest changes, the rendered config differs, the existing configsChanged detection path picks it up, and a reload is triggered. Dynamic SSL reload for server certs is left untouched.