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.
# backend configuration:
<IfModule mod_ca_simple.c>
# use system clock as the time source
CASimpleTime on
# assign a random serial number
CASimpleSerialRandom on
</IfModule>
# frontend configuration:
<IfModule mod_timestamp.c>
<Location /timestamp>
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
</Location>
</IfModule>
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).
openssl ts -query -data my-novel.doc -cert -sha256 -no_nonce -out request.tsq
- 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).
curl -H Content-type:application/timestamp-query --data-binary @request.tsq http://127.0.0.1/timestamp > reply.tsq
- You can now dump the content of this reply;
openssl ts -reply -text -in reply.tsq
openssl asn1parse -inform DER -in reply.tsq
or, better, verify it against the timestamp certificate (or, with the chain, against any of the higher CA certificates as the root):
openssl ts -verify -in reqply.tsq -data my-novel.doc -CAfile /etc/pki/ssl/timestamp.cert
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.