zmuxuny opened a new issue, #5039: URL: https://github.com/apache/rocketmq-dashboard/issues/5039
### Problem Studio's K8s certificate inventory can mark an uploaded X.509 certificate **valid** before its `notBefore` time. `K8sCertService.createCert` parses and stores both validity bounds from the PEM, but `refreshExpirationState` checks only `notAfter`: any certificate with an expiry more than 30 days away is reported `valid`, even if it is not yet usable. ### Reproduction on `rocketmq-studio` With a fixed clock of 2025-07-01 UTC, list a certificate whose `notBefore` is 2025-07-02 and `notAfter` is 2026-07-02. `listCerts()` returns `status=valid`. Uploading such a PEM through the existing create form has the same outcome because its parsed dates flow into this method. The page renders a green “有效” tag. ### Expected behavior Show a distinct “not yet valid” state until `notBefore`, then the existing valid/expiring/expired states according to `notAfter`. Keep the two dates and `daysRemaining` intact, and have the UI/API type render the new state explicitly. ### Impact Operators using the certificate inventory to review readiness can mistake a future-dated TLS/mTLS certificate for one currently usable. The page is local metadata (it does not install the certificate on Kubernetes), but its validity label should describe the certificate it stores. I searched current issues/PRs for future-dated certificates and `notBefore` status; I did not find an existing fix. I will add a fixed-clock regression test and update the status mapping in a focused PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
