zmuxuny opened a new issue, #5549: URL: https://github.com/apache/rocketmq-dashboard/issues/5549
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version Originally reported on the `rocketmq-studio` branch in #5039; the exact original commit was not recorded in that report. The current fix is #5251, refreshed and validated on 2026-10-04 against `rocketmq-studio@6a68042fa73a513f40436ca721944b4de48181ec`. ### Runtime Environment Studio K8s certificate inventory, `K8sCertService` and the inventory page. Reproduction uses a fixed-clock service test; current focused validation uses Java 21 and frontend Vitest. This is local certificate metadata, not certificate installation on Kubernetes. ### Connected RocketMQ Cluster Not cluster-specific. The certificate-status calculation can be reproduced without a live RocketMQ or Kubernetes cluster. ### Build Toolchain Not a build/startup defect. Current focused Java/frontend commands and their limitations are recorded in #5251. ### Describe the Bug 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 expiry more than 30 days away is reported `valid`, even if it is not yet usable. Operators reviewing readiness can mistake a future-dated TLS/mTLS certificate for one currently usable. ### Steps to Reproduce 1. Use a fixed clock of 2025-07-01 UTC. 2. List a certificate with `notBefore=2025-07-02` and `notAfter=2026-07-02`. 3. Call `listCerts()` and inspect the returned status and inventory label. Uploading a PEM with these validity bounds through the existing create form has the same outcome because the parsed dates flow into `refreshExpirationState`. ### What Did You Expect to See? Show a distinct not-yet-valid state until `notBefore`, then the existing valid/expiring/expired states according to `notAfter`. Keep both dates and `daysRemaining` intact, and render the state explicitly in the UI/API type. ### What Did You See Instead? `listCerts()` returns `status=valid` before the certificate's validity begins, and the page renders a green “有效” tag. ### Additional Context This replaces the previous report [#5039](https://github.com/apache/rocketmq-dashboard/issues/5039), automatically closed by the stale bot on 2026-10-04. That closure was an inactivity action, not a maintainer rejection of the report or fix. Current fix: [#5251](https://github.com/apache/rocketmq-dashboard/pull/5251), which remains open. The former #5042 submission and the 2026-09-26 report of 33 focused Java tests and 8 frontend tests are historical. Fresh 2026-10-04 validation and remaining CI limitations are recorded in #5251; overall CI is not green. Searched open issues for future-dated certificates, `notBefore`, and the previous report reference; no duplicate open report was found. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
