TSS FAQs and solutions

This section addresses the frequently-asked questions about the TSS and provides solutions to common problems. The following answers to frequently-asked questions are in alphabetical order by topic.

Digital certificates

  1. What are the roles and respective keys and certificates of the TSS?

    See this table for the answers:

    Cert Type Role

    TSA

    Sign time-stamps and authenticate DS/NTP communications

    TSA Root Chain

    Certificate fulfillment with CA

    DI Root Chain

    Authentication of devices for DS/NTP

    HTTPS

    Enable https:// communication for browser-based communication

  2. In the TSS, where are the keys and certificates?

    See this table for the answer:

    Product / Cert Type Private Key

    TSA

    nShield Solo

    TSA Root Chain

    nShield Solo

    DI Root Chain

    nShield Solo

    HTTPS

    Host Drive

  3. How are these keys and certificates generated?

    See this table for the answers:

    Product / Cert Type How Keys Are Generated

    TSA

    Keys and certificate request generated by TSS Security Officer. Certificate acquired from public or private CA.

    TSA Root Chain

    Loaded by TSS Security Officer

    DI Root Chain

    Loaded by TSS Security Officer

    HTTPS

    The default test TLS certificate must be replaced before TSS deployment.

  4. How are certificates obtained with the TSS?

    Administrators can use the local, browser-based administration system of the TSS to obtain TSA certificates. In local certification, administrators generate a key pair and a certificate request. The PKCS #10 request can then be submitted to the appropriate CA for certificate fulfillment.

Standards

  1. What Time Stamp Protocol does the TSS support?

    The TSS supports the IETF Time Stamp Protocol (RFC 3161). Time-stamps are requested by means of either the Transmission Control Protocol (TCP) or Hypertext Transfer Protocol (HTTP), as described by RFC 3161. The extensions to RFC 3161 described by RFC 5816 are also supported.

  2. A European standard (ETSI) says that a recommended time-stamp protocol (RFC 3161) should be the http protocol. Do you support the http protocol for time-stamping?

    The TSS includes support for the RFC3161 Time-Stamp Protocol through HTTP (Hypertext Transfer Protocol).

Synchronization

  1. Is the time that is used for Windows synchronized to the time-stamp token’s time?

    No, the time is not synchronized. The time for Windows is from the Windows system clock.

TSS

  1. In the customer’s installation, can the customer integrate the TSS in the firewall? Can the TSS operate correctly in the firewall? Specifically, can the DS/NTP and DSMP be transferred by NAT (Network Address Translation)?

    Yes, you can use firewalls/NAT. Customers presently use TSMCs to audit their TSS devices through a firewall and VPN.

  2. When the user employs the TSS with their application server, is a secure connection required between the TSS and the application server?

    When issuing time-stamps there is no need for a secure connection between the application server and the TSS. The PKIX TSP (time-stamp protocol) includes all the security that should be needed. The data returned from the TSS is signed and includes the original hash and nonce. Security is part of the reason that the time-stamp request includes only a hash of the original data. Someone watching a session would see only hash information, which is safe. If you need security for other reasons such as identifying the user, billing, and so forth, this security should be implemented on an application server that has a direct unsecured connection to one or more TSSs.

  3. How does the TSS acquire time after a restart?

    After a restart, the TSS does not have an operational Time Attribute Certificate and cannot provide time-stamps. The TSS initially contacts the assigned Upper Clock and requests an audit. The first Upper Clock audit may fail, depending on the clock drift rate, and issue a non-operational TAC. The TSS corrects its clock to this first audit. The TSS then does another audit request which is normally successful and receives an operational TAC from the Upper Clock. The Upper Clock then continues to audit the TSS per the configured interval.