A more typical scenario: generate a timestamp for a logged in
user.
In this example it is assumed that Apache configuration
exists that
authenticates a user against a database, directory, a token, or a previous
certificate.
# use system clock as the time source
CASimpleTime on
# assign a random serial number
CASimpleSerialRandom on
# frontend configuration:
SetHandler timestamp
# standard Apache authorisation
Require valid-user
# sign with this certificate...
TimestampSigningCertificate /etc/pki/ssl/timestamp.cert
# ...and private key
TimestampSigningKey /etc/pki/ssl/timestamp.key
# use a sha256 digest
TimestampDigest SHA256
# set the policy to an oid of your choice
TimestampDefaultPolicy 1.2.3.4
]]>
Client implementations for RFC3160 can be found for most languages; and some applications have these build in (in that case -the URI to enter for the above examples would be https://fqdn.com/timestamp
.
It is also possible to use OpenSSL its build in ts
utility; an example is show below; where a file caled my-novel.doc
is timestamped (any binary file will do).
- First create a signing request for the file. What actually gets signed is the SHA256 (specified by the
-cert
flag).
- Then offer this to the signing server (assumed here to run localhost); as an HTTP POST request with the right content type. The reply is signed receipt (in binary, DER, format).
reply.tsq
]]>
- You can now dump the content of this reply;
or, better, verify it against the timestamp certificate (or, with the chain, against any of the higher CA certificates as the root):
Note: As we dit not set a 'nonce' in step 1 - we did not get one back (which you can use to verify against the one in the request). And in this particular case - we get a random `serial' number set by the time server (As we set CASimpleSerialRandom
to on
in the servr configuration).
In this case - we simply use the certificate set in the configuration file of the signing timeserver (by TimestampSigningCertificate
) to verify. So we have no chain issues.