Timestamping in Isolated and Air-Gapped Networks: Running an RFC 3161 TSA Without Internet Access

Why isolated networks need timestamps

Many organizations run networks or segments without internet access: restricted server zones, test and development labs, sites with no outbound connectivity, or environments that are air-gapped by policy. The systems in them still produce records whose time and integrity matter:

• Code and script signing. Internal tools, scripts and applications are signed; timestamps keep those signatures valid after the signing certificate expires.
• Change management. Configuration baselines and change records show when a server, a network device or an application was modified.
• Signed internal documents. Reports, approvals and technical documents are signed and must remain verifiable for years.
• Logs. Security and application events are evidence after an incident, provided they can be shown to be unaltered.

Why a public TSA is not an option

An RFC 3161 exchange is a request and a response over HTTP. That requires a bidirectional connection between the client and the TSA:

• Air-gapped networks have no route to the internet at all.
• Restricted segments are protected by firewall policies that allow no outbound internet traffic. Opening an exception only for timestamping weakens the segmentation the network is built on, and has to be justified, documented and maintained.
• Lab and test environments are often deliberately disconnected, so that tests are reproducible and independent of external services.

Even where a controlled outbound path exists, making a signing or logging process depend on an external service adds an availability risk that isolated environments are meant to avoid. The TSA has to be inside.

Where to place the TSA

Place the TSA where the clients that need it can reach it, and no further. Common options:

• Shared services segment. A TSA next to the domain controllers, the issuing CA and the time servers can serve several isolated segments through the firewall rules that already exist for those services.
• One TSA per isolated segment. Where segments must not communicate with each other at all, each one needs its own TSA, time source and certificate. Separate TSU certificates per segment also keep incident scope contained.
• Build or signing segment. Where timestamps are mainly used for code signing, the TSA can sit next to the build and signing infrastructure.

Expose the service over HTTPS, restrict the source addresses that can reach it, and enable client authentication if the TSA should serve only defined systems.

Time without the internet

A TSA writes into each token the time of the host it runs on. In a connected network, that host is usually synchronised with public NTP servers. In an isolated network, the reference has to be brought in by other means, and its quality determines the quality of every token.

GNSS-referenced time server

If the isolated network can reach an internal time hierarchy that is itself correctly synchronised, for example the corporate domain controllers through an existing firewall rule, use it and monitor the offset. Where no such source exists, the usual solution is a dedicated time server with a GNSS receiver (GPS, Galileo or several constellations) acting as a stratum-1 NTP server, and PTP (IEEE 1588) where hardware timestamping is available. Only the antenna is exposed; the receiver does not need any network connection outside the isolated network. Choose a model with a holdover oscillator (OCXO or rubidium), which keeps the time stable for a defined period if the satellite signal is lost.

GNSS-specific risks

• Jamming and spoofing. GNSS signals are weak and can be disrupted or imitated. Prefer receivers with multi-constellation support and spoofing detection, and alarm on loss of lock.
• Single point of failure. Two independent time servers, ideally with different antennas, allow the TSA host and the monitoring system to detect a reference that drifts away from the other.
• Holdover limits. Know how long the oscillator stays within your accuracy budget without satellite signal, and alarm well before that limit.

Synchronising the TSA host

Point the Windows Time service of the TSA host to the internal time servers, for example:

w32tm /config /manualpeerlist:"ntp1.corp.local,0x8 ntp2.corp.local,0x8" /syncfromflags:manual /update

Check the status with w32tm /query /status and measure the actual offset against a reference with w32tm /stripchart /computer:ntp1.corp.local /dataonly. On a well-designed local network, NTP synchronisation to a stratum-1 server in the same site typically keeps the offset in the order of milliseconds. Declare in the tokens an accuracy that your measured offset reliably stays within, not the best value you have observed.

When the reference is lost

Write down, before go-live, what happens if the time server loses its reference beyond its holdover budget, or if the TSA host offset exceeds the declared accuracy. The safe behaviour is to take the TSA out of service until synchronisation is restored, and to record the interval. Tokens issued with a time that cannot be trusted are worse than no tokens, because they look valid.

PKI and revocation inside the network

The TSU certificate must be issued by a CA that every validator in the network trusts, and everything a validator needs to check that certificate must be reachable from inside.

• Certificate profile. RFC 3161 requires the TSU certificate to contain the id-kp-timeStamping extended key usage, marked critical, as its only purpose.
• Hierarchy. A common design is an offline root CA kept outside or in a vault, and an issuing CA inside the network, for example Microsoft ADCS. Certificate requests and the issuing CA certificate are transferred on controlled media.
• CRL distribution points and AIA. The URLs embedded in the certificates must resolve inside the network. Certificates issued with CDP or AIA pointing to internet hosts will fail revocation checks everywhere inside the network.
• Offline root CRL. Give the root CRL a validity period that matches your operational procedure for bringing a new CRL into the network, and calendar its renewal.
• OCSP. If your validators prefer OCSP, run an internal responder; otherwise make sure CRLs are published and refreshed on time.

A self-signed TSU certificate is possible, but every validator would have to trust it individually, and there is no revocation path if the key is compromised. A certificate from the network's own CA is easier to operate and to replace.

Key protection

The credibility of every token depends on the TSU private key. Keep it non-exportable, preferably in an HSM accessed through PKCS#11, whether a network HSM in the shared services segment or a PCIe or USB module in the TSA host. Restrict administrative access to the TSA configuration, and protect the HSM credentials stored on the server as you would any other privileged secret.

Clients and validation

Requesting timestamps

Standard tools only need the internal TSA URL:

• Authenticode: signtool sign /fd sha256 /tr https://tsa.corp.local/tsa/get.aspx /td sha256 file.exe
• Java: jarsigner -tsa https://tsa.corp.local/tsa/get.aspx app.jar alias
• OpenSSL: create a request with openssl ts -query -data file -sha256 -cert -out req.tsq, send it with Content-Type: application/timestamp-query, and verify the response with openssl ts -verify -data file -in resp.tsr -CAfile chain.pem.
• Adobe Acrobat: add the TSA URL as the default timestamp server in the signature preferences.

Making validators trust the TSA

• Distribute the root certificate of the internal PKI through Group Policy to Windows machines.
• In Adobe Acrobat, import the root certificate as a trusted certificate for signatures and timestamps, or enable trust of the Windows certificate store.
• For Java, OpenSSL and other tools, add the root certificate to the trust store they use.

Long-term validation without external services

Documents that must remain verifiable for years should carry their own validation data: the certificate chains and the revocation information valid at signing time, as in PAdES B-LT and B-LTA. Then verification works inside the network years later, even after the issuing CA has published many newer CRLs or has been replaced.

When evidence leaves the network

Tokens remain verifiable outside the isolated network, provided the verifier receives the certificate chain and the relevant revocation information together with the evidence. Package them with any records you export. If exported records must also convince third parties who do not trust your internal CA, see Qualified vs Self-Hosted Timestamping for the options.

Deployment checklist

1. TSA placed in a segment reachable only from permitted clients, served over HTTPS, with client authentication if required.
2. A reliable internal time source: a correctly synchronised internal hierarchy, or GNSS-referenced time servers with holdover and alarms.
3. TSA host synchronised to the internal time servers; offset monitored; declared accuracy based on measured values.
4. Documented procedure for taking the TSA out of service when time cannot be guaranteed.
5. TSU certificate issued by the internal CA, with id-kp-timeStamping as the only, critical extended key usage.
6. CDP, AIA and OCSP locations resolvable inside the network; offline root CRL renewal scheduled.
7. TSU key non-exportable, preferably in an HSM.
8. Root certificate distributed to every validator; Adobe Acrobat and other tools configured to trust it.
9. Long-lived documents signed at an LTV level, carrying their validation data.
10. Audit trail of the TSA reviewed, and tokens and certificate chains included in backups.

Frequently asked questions