Fail fast on invalid certificates at TLS config load#2999
Fail fast on invalid certificates at TLS config load#2999zuiderkwast merged 5 commits intovalkey-io:unstablefrom
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## unstable #2999 +/- ##
============================================
- Coverage 74.38% 74.24% -0.14%
============================================
Files 129 129
Lines 71041 71041
============================================
- Hits 52844 52745 -99
- Misses 18197 18296 +99
🚀 New features to boost your workflow:
|
570801b to
51925b4
Compare
|
Hello @madolson @zuiderkwast @PingXie, I briefly mentioned this PR in last week's weekly meeting. |
|
Thanks for the heads up. A small behavior change doesn't necessarily need to be a major decision, if it's backward compatible and doesn't introduce any new public API (configs, commands, etc.) and doesn't break any user scenario. So what exactly is the behavior change? Before:
After:
CONFIG SET can now return an error where it previously returned OK, but that OK was silencing a severe admin error resulting in clients unable to connect. To me, it doesn't seem like a breaking change, so I don't think it needs to be a major decision, but @valkey-io/core-team please speak up if you think otherwise. I (or someone else) will review this PR soon. |
zuiderkwast
left a comment
There was a problem hiding this comment.
Looks good to me in general. I have only minor comments.
We use camelCase for function names and snake_case for variables, so please follow this style in new code. (Sorry, the style is not written anywhere. We're working on it.)
zuiderkwast
left a comment
There was a problem hiding this comment.
Looks good, thank you!
@madolson do you think the behavior change poses any risk?
|
The new behavior is better so good from my end. Btw, @zuiderkwast once we merge #3076 copilot should be able to take care of the coding style review (and we can keep iterating on the instructions). |
Gotcha. I approved it now. :) |
There was a problem hiding this comment.
Pull request overview
This PR adds fail-fast validation for TLS certificates at configuration load time, rejecting certificates that are expired or not yet valid. This applies to server certificates, client certificates, and CA certificates (both file and directory-based), and works during both server startup and runtime CONFIG SET operations.
Changes:
- Added certificate validity checking functions (
isCertValid,loadCaCertDir,areAllCaCertsValid) to validate X509 certificates - Enhanced TLS configuration to eagerly load and validate all CA certificates from directories
- Generated test certificates (expired and not-yet-valid) for comprehensive testing
- Added integration tests to verify rejection of invalid certificates at startup
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/tls.c | Implements certificate validation logic with three new functions to check certificate validity, eagerly load CA certificates from directories, and validate all loaded CA certificates |
| utils/gen-test-certs.sh | Extends certificate generation script to create expired and not-yet-valid certificates for testing (server, client, and CA certificates) |
| tests/unit/tls.tcl | Adds integration tests to verify that invalid certificates are rejected at server startup for all certificate types |
| tests/README.md | Updates documentation to mention generation of invalid test certificates |
### Overview This PR adds support for automatic background TLS reloading, closes #2649 TLS validity checks and fail-fast behavior on invalid certificates are handled separately in #2999. - New configuration - `tls-auto-reload-interval <seconds>` - `0` disabled (default, backward compatible) - `>0` check interval in seconds - TLS materials change detection in background - SHA-256 fingerprint checking for certificate files - `inode + mtime` checking for CA certificate directories and key files - Skips reload if materials haven't changed `tlsCheckMaterialsAndUpdateCache` - TLS contexts reload - CPU-intensive certificate parsing happens in dedicated BIO worker thread `BIO_TLS_RELOAD` - Main thread never blocks, atomically swaps SSL contexts - Two-phase reload: background preparation `tlsConfigureAsync` + main thread application `tlsApplyPendingReload` **Note**: Original TLS load and reload still remain in main thread using `tlsConfigureSync`, including: - Initial TLS load (server startup) - Runtime reload via CONFIG SET --------- Signed-off-by: Yang Zhao <zymy701@gmail.com>
This comment was marked as off-topic.
This comment was marked as off-topic.
### Overview This PR adds support for automatic background TLS reloading, closes valkey-io#2649 TLS validity checks and fail-fast behavior on invalid certificates are handled separately in valkey-io#2999. - New configuration - `tls-auto-reload-interval <seconds>` - `0` disabled (default, backward compatible) - `>0` check interval in seconds - TLS materials change detection in background - SHA-256 fingerprint checking for certificate files - `inode + mtime` checking for CA certificate directories and key files - Skips reload if materials haven't changed `tlsCheckMaterialsAndUpdateCache` - TLS contexts reload - CPU-intensive certificate parsing happens in dedicated BIO worker thread `BIO_TLS_RELOAD` - Main thread never blocks, atomically swaps SSL contexts - Two-phase reload: background preparation `tlsConfigureAsync` + main thread application `tlsApplyPendingReload` **Note**: Original TLS load and reload still remain in main thread using `tlsConfigureSync`, including: - Initial TLS load (server startup) - Runtime reload via CONFIG SET --------- Signed-off-by: Yang Zhao <zymy701@gmail.com> Signed-off-by: arshidkv12 <arshidkv12@gmail.com>
Signed-off-by: Yang Zhao <zymy701@gmail.com>
Signed-off-by: Yang Zhao <zymy701@gmail.com>
Signed-off-by: Yang Zhao <zymy701@gmail.com>
Signed-off-by: Yang Zhao <zymy701@gmail.com>
Signed-off-by: Yang Zhao <zymy701@gmail.com>
e341ea3 to
cb20800
Compare
|
Rebased onto the latest |
Changes include: - Unify TLS topic naming: previously some references used “encryption” while others used “tls” - Remove source code repo specific information: instructions on building or running unit tests - Add information on new TLS feature and behavior: - valkey-io/valkey#2999 - valkey-io/valkey#3020 --------- Signed-off-by: Yang Zhao <zymy701@gmail.com>
Closes #2997
Overview
This PR adds the certificates validation at TLS load, rejects invalid (expired/not-yet-valid) certificates:
Apply to all TLS config paths:
tls-cert-filetls-client-cert-filetls-ca-cert-filetls-ca-cert-dir(now eagerly loaded to be consistent with file-based CAs)Apply to both scenarios:
CONFIG SETImplementation
isCertValidfunction to check if an X509 certificate is within its validity period (not expired, not future-dated)areAllCaCertsValidfunction to iterate through all loaded CA certificates and validate themloadCaCertDirfunction to eagerly load all certificates from a directory into the X509_STOREcreateSSLContextto validate:Test results
1. Server startup (initial TLS load)
2. Runtime reload via CONFIG SET