The signed module has no trusted signing-time proof, so an expired module certificate produces a gateway warning even though the module still loads and runs. Follow the packet from the build process to the signing tool, any timestamp authority, the module artifact, and finally the Ignition gateway. The path currently stops in the signer: it signs the module but does not request or embed a timestamp.
Where does the timestamp data path stop?
The build process supplies the module and signing credentials to the Ignition Module Signer. A timestamp-capable workflow would then send a digest to a timestamp authority, receive a signed timestamp token, and bind that token to the module signature. The current tool omits that transaction.
| Hop | Expected action | Reading to take | Decision |
|---|---|---|---|
| Build to signer | Pass the module and signing configuration | Confirm that ordinary signing completes | If signing fails, troubleshoot signing before timestamping |
| Signer to timestamp authority | Submit a digest for timestamping | Inspect signer configuration, logs, or a packet capture | No request is expected from the current implementation |
| Timestamp authority to signer | Return a signed time token | Inspect the resulting signature data | No token can return when no request was sent |
| Module to gateway | Present the signature and any timestamp token | Review gateway validation messages | The gateway evaluates certificate expiration but does not use a timestamp to change the result |
If “timestamp” means an RFC 3161 timestamp, both ends need coordinated changes. Adding a token to the artifact alone has no operational benefit when the gateway does not validate and apply that token.
Can the build host reach a timestamp service?
Layer one first. This check matters only after the signer can issue a timestamp request. Confirm the build host has the required physical link, network route, name resolution, and trust path to the selected timestamp service. A public timestamp service normally introduces an Internet dependency at build time; an isolated build network needs an approved reachable service instead.
| Item | Reading | Pass condition | Next check |
|---|---|---|---|
| Address | Resolved destination used by the configured service | The build host resolves and routes to it | Test the service connection |
| Port | Port specified by the selected service | The path is not blocked | Inspect for an outbound timestamp request |
| Timing | Timestamp transaction during module signing | The request and response occur before the signed artifact is finalized | Inspect the artifact |
| Trust | Certificate chain presented for the timestamp token | The validating environment trusts the issuing chain | Test gateway interpretation |
Read the address, port, and certificate chain from the selected timestamp service configuration; no universal values apply here. If ordinary signing succeeds but a capture contains no timestamp transaction, move to signer capability rather than changing switches, firewalls, or DNS.
Does the signer actually issue a timestamp request?
The decisive reading is an outbound request during signing or a timestamp token embedded with the resulting signature. The current Ignition Module Signer does not implement that operation. Network repairs cannot create a request that the application never attempts.
- Build and sign a test module with the current tool.
- Record the signing log and, where permitted, capture traffic from the build host during that operation.
- Inspect the signature data with a tool capable of distinguishing the signer certificate from a timestamp-authority token.
- If the module is signed but no token exists, classify the result as signer capability, not network loss.
A file creation time, archive entry time, or build timestamp is not equivalent to a cryptographically signed time assertion. An RFC 3161 token binds a trusted time assertion to a digest. It proves that the signed data existed by that time only when the consumer validates the token, its digest binding, and its certificate chain.
Does the gateway use the timestamp when loading?
The gateway currently warns when the module signing certificate has expired but does not refuse to load or run the module. It also does not apply timestamp information to decide whether the signature was created while the certificate was valid. That behavior makes the warning the practical worst case for certificate expiration in the described workflow.
| Module state | Current gateway result | Timestamp-aware result would require |
|---|---|---|
| Signed with an unexpired certificate | Normal signature processing | No timestamp-specific decision is needed for the expiration warning |
| Certificate later expires; no timestamp | Warning; module still loads and runs | A policy defining how missing timestamps are handled |
| Certificate later expires; valid timestamp token present | No change from adding the token alone | Gateway logic that validates the token and compares signing time with certificate validity |
| Timestamp token cannot be trusted | No current timestamp decision | A defined warning or rejection policy plus a configured trust chain |
Gateway Internet access is not inherently required merely to verify a timestamp. The gateway must trust the certificate chain used to create the token. Common timestamp-service certificates may already chain to a certificate authority in the main Java CA store; isolated systems may need the applicable trust material installed through the supported certificate-management process.
Which resolving branch matches the requirement?
Choose the branch from the required outcome, not from the presence of an expiration warning.
| Requirement | Action | Verification |
|---|---|---|
| Keep an installed module operating after its signing certificate expires | Retain the current behavior | Confirm the gateway reports a warning and the module loads and runs |
| Remove the warning without changing timestamp policy | Sign a new release with a currently valid certificate | Load the newly signed artifact and check gateway diagnostics |
| Prove the signature existed while the certificate was valid | Add timestamp generation to the signer and timestamp validation to the gateway | Test a valid token, a missing token, an untrusted token, and an altered artifact |
| Avoid public Internet access from the build system | Select an approved reachable timestamp service and distribute its trust chain | Test from the actual isolated build and gateway environments |
An optional signer flag can preserve compatibility for builds that do not need timestamps. The matching gateway policy must define whether a missing or invalid token causes no message, a warning, or rejection. Without that policy, stricter enforcement could stop older modules that were legitimately signed before timestamp support existed.
How should timestamp-aware signing be implemented and verified?
- Define the acceptance policy for valid, missing, expired, malformed, and untrusted timestamp tokens. Keep the current warning-and-load behavior where backward compatibility is required.
- Add an optional timestamp setting to the signer. Read the service address, port, trust chain, and connection requirements from the selected service configuration rather than embedding assumed values.
- Submit the signature-related digest, receive the timestamp token, and bind it to the module signature using the selected
RFC 3161workflow. - Extend gateway validation to verify the token signature, certificate chain, digest binding, and asserted signing time before applying any certificate-expiration policy.
- Test without Internet access if the gateway is expected to operate offline. Confirm that its local trust configuration is sufficient for the chosen token chain.
- Run negative tests: alter the module after signing, remove the token, use an untrusted token chain, and present a malformed token. Record the intended warning or rejection for each case.
- Run the resolving test with a module timestamped while its signing certificate is valid, then evaluate it after that certificate expires. The final pass condition is that the gateway validates the unchanged module and trusted timestamp, applies the defined expiration policy, and produces the specified load result.
FAQ
Why does an expired Ignition module certificate only show a warning?
The current gateway policy warns about certificate expiration but does not refuse to load or run the module. Timestamp enforcement has not been added to that decision.
Why does adding an RFC 3161 timestamp to the signer not fix the warning?
The gateway must validate the RFC 3161 token and use its signing time in the certificate-validity decision. An embedded token alone does not change gateway behavior.
Why is there no timestamp request in the packet capture?
The current Ignition Module Signer does not implement timestamping. Confirm ordinary signing succeeds, then treat the missing request as an application-capability issue rather than a firewall or routing fault.
Does the Ignition gateway need Internet access to verify a timestamp?
Not necessarily. Configure the gateway to trust the timestamp certificate chain, disconnect the external path if offline operation is required, and repeat the final load test to verify local validation succeeds.