kakwa / uts-server

Micro RFC 3161 Time-Stamp server written in C.

uts-server

Micro RFC 3161 Time-Stamp server written in C.

---

Doc:	Uts-Server documentation on ReadTheDoc
Dev:	Uts-Server source code on GitHub
License:	MIT
Author:	Pierre-Francois Carpentier - copyright © 2019

---

Demo

A demo is accessible here: https://uts-server.kakwalab.ovh/

License

Released under the MIT Public License

What is RFC 3161?

An RFC 3161 time-stamp is basically a cryptographic signature with a date attached.

Roughly, it works as follow:

1. A client application sends an hash of the data it wants to time-stamp to a Time-Stamp authority server.
2. The Time-Stamp authority server retrieves the current date, concatenates it with the hash and uses its private key to create the time-stamp (kind of like a signature).
3. The Time-Stamp authority server returns the generated time-stamp to the client application.

Then a client can verify the piece of data with the time-stamp using the Certificate Authority of the time-stamp key pair (X509 certificates).

It gives a cryptographic proof of a piece of data content, for example a file, at a given time.

Some use cases:

• time-stamp log files at rotation time.
• time-stamp file at upload to prove it was delivered in due time or not.

Quick (and dirty) Testing

Here a few steps to quickly try out uts-server, for production setup, please compile civetweb externally and create proper CA and certificates:

# Building with civetweb embedded (will recover civetweb from github).
# Note: the BUNDLE_CIVETWEB option is only here for fast testing purpose
# The recommended way to deploy uts-server in production is to build civetweb
# separatly and to link against it.
$ cmake . -DBUNDLE_CIVETWEB=ON
$ make

# Create some test certificates.
$ ./tests/cfg/pki/create_tsa_certs

# Launching the time-stamp server with test configuration in debug mode.
$ ./uts-server -c tests/cfg/uts-server.cnf -D

# In another shell, launching a time-stamp script on the README.md file.
$ ./goodies/timestamp-file.sh -i README.rst -u http://localhost:2020 -r -O "-cert";

# Verify the time-stamp.
$ openssl ts -verify -in README.rst.tsr -data README.rst -CAfile ./tests/cfg/pki/tsaca.pem

# Display the time-stamp content.
$ openssl ts -reply -in README.rst.tsr -text

Powered by

uts-server's Issues

compile failed on CentOS 7

the cmake finds the openssl dirs and libs right, but in the make process the ld says it cannot find the -lssl and -lcrypto, although they are exactly in those dirs it detected
using openssl 1.0.2k

zlib

zlib is required to compile civetweb, so it's better to add check

find_package(ZLIB REQUIRED)
MESSAGE(STATUS "ZLIB libraries: ${ZLIB_LIBRARIES}")
MESSAGE(STATUS "ZLIB version: ${ZLIB_VERSION_STRING}")

in CMakeLists.txt (near find_package(OPENSSL REQUIRED))

uts-server does not respect digest algorithm

First of all thank you for wrapping the OpenSSL calls in a webserver interface, very useful!

Problem: Regardless which digest algorithm is specified in the timestamp request, uts-server always applies the same digest algorithm to the timestamp response. Example:
signtool sign /sha1 <CodeSignCert> /fd sha512 /tr http://uts-server /td sha512 file.exe

Expected result: The code signature as well as the timestamp both use SHA512.
Actual behaviour: While the code signature is using SHA512, the timestamp is applied with a SHA256 digest. Changing the /td in the example parameter to any other value has no effect, uts-server always uses SHA256.

It seems that the code to select the digest algorithm is commented out in src/lib/rfc3161.c lin 154+ but I don't know enough about the timestamp query structure on how to extract this value.
Using TS_CONF_set_signer_digest(conf, section, NULL, resp_ctx) I can set the digest algorithm to something else than sha256 via the uts-server configuration file (eg signer_digest = sha512), but then the algorithm is just hardcoded to something else and still not picked up from the request.

dockerize it

Hi, thank you so much for this project.

I'm trying to dockerize this application for our use-case (multiple servers in a swarm) and for publishing on Dockerhub but I'm running into a couple problems.

It's funny because I dockerized civetweb as a play project and it worked fine.

There are 2 issues:

1. Log output is erratic apparently due to buffering issues. In Docker we don't daemon the process but rather let it run on the foreground and output to stdout. However only in Docker the log output is very erratic. If I make a request, the log is cut halfway and I have to make many more requests for the rest of the logs to come up and is buffered halfway again. Is there a variable or a setting to reduce or tune buffering?

2. This is most likely related to Docker and not to uts-server (although it doesn't happen with civetweb in docker): once docker is up and the service is running I cannot ctrl-c it, I can only stop it by killing the container. If I log into the container using bash and run the server on my own, it works just fine - both log output and killing it with ctrl-c.

Could you shed some light if possible?

duplication parameters

in CMakeLists.txt
-DCIVETWEB_DISABLE_CGI=ON
is set twice, in 75 and 78 lines

and, just curiosity question: what's the sense of patching civetweb sources - replacing DATE with "110973"?

static linking

in order to make statically linked executable, add:

option(STATIC "static linked binary" OFF)

if (STATIC)
SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
SET(BUILD_SHARED_LIBRARIES OFF)
SET(CMAKE_EXE_LINKER_FLAGS "-static")
endif (STATIC)

in CMakeLists.txt before first "find_package"

Source for Time Stamp Certificate

Hi

Script given for certificate generation in this project is created test certificates for time stamping( Which has no Trusted CA - Certificate Authority)

Can anyone provide the link or provider detail who can provide the Time stamping certificate with Trusted CA ?

C99 mode error

/root/uts-server-master/src/lib/rfc3161.c: In function ‘get_ctxw’:
/root/uts-server-master/src/lib/rfc3161.c:73: error: ‘for’ loop initial declarations are only allowed in C99 mode
/root/uts-server-master/src/lib/rfc3161.c:73: note: use option -std=c99 or -std=gnu99 to compile your code
make[2]: *** [CMakeFiles/uts-server.dir/src/lib/rfc3161.c.o] Error 1
make[1]: *** [CMakeFiles/uts-server.dir/all] Error 2
make: *** [all] Error 2

PKCS11

Hi,

Is your product compatible with the PKCS11 standard ?
If not, is it possible to add this functionality?

Best regards,

Yxoti

kakwa/civetweb

"make" doesn't work because of removing "kakwa/civetweb" project

sed error on FreeBSD

Try to build on FreeBSD 11, "cmake <...> && make" gives an error:
[ 15%] Performing patch step for 'civetweb'
Execute: 'cd /root/uts-server-master/civetweb-prefix/src/civetweb && sed -i s/DATE/"110973"/ src/main.c src/civetweb.c'

• cd /root/uts-server-master/civetweb-prefix/src/civetweb
• sed -i 's/DATE/"110973"/' src/main.c src/civetweb.c
  sed: 1: "src/main.c": unterminated substitute pattern
  *** Failed target: civetweb-prefix/src/civetweb-stamp/civetweb-patch

In FreeBSD sed, -i requires an backup extension (or ""). After adding -i "" in CMakeFiles/civetweb.dir/build.make, sed works ok.

Crashes when used with C2PA

Configuration:

• UTS Server on Linux.
• Using test certificates.
• Using 'c2patool' and specifying the local uts server as the ta_server for the c2patool manifest.

uts_server crashes when queried by c2patool.

FreeBSD CLang problem

Compiling statically linked executable (as described in issue #4 ), ends with error:

[100%] Linking C executable uts-server
/usr/bin/ld: undefined reference to symbol `__register_frame_info@@GCC_3.0' (try adding -lgcc_s)
//lib/libgcc_s.so.1: could not read symbols: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

FreeBSD 11.0, CLang 3.8.0. Using gcc 4.9.4 - compiles ok.