Bug in OpenSSL : Timestamping error

[cbgorman]

When attempting to timestamp, we have gotten the error below. Can anybody help us out?

System command failed: 139639965218464:error:2F067065:time stamp routines:TS_CHECK_SIGNING_CERTS:ess signing certificate error:ts_rsp_verify.c:291:, Verification: FAILED”

[NicolasCARPi]

Hello,

Please provide more informations:

• what operating system ?
• what version of elabftw ?
• what version of php/openssl
• do you use the default TSA ?

Can you provide us with a timestamped pdf and a token so we can try to reproduce ?

[Athemis]

Hi Nicolas,
I'm getting a similar error after updating from 1.1.8-p2 to 1.2.0-alpha using the default (DFN) TSA. I can confirm that it was working fine before the update.

System command failed: 1996412112:error:2F067065:time stamp
routines:TS_CHECK_SIGNING_CERTS:ess signing certificate
error:ts_rsp_verify.c:311:, Verification: FAILED

OS: Archlinux x86_64, Kernel 4.5.1
OpenSSL: 1.0.2g
PHP: 7.0.5

Best regards,

Alex

[NicolasCARPi]

Yep, I can confirm too, weird, because it was working fine before, and I don't think I changed anything.

Can you confirm it works in 1.1.8-p2 ? Because if I do a git checkout 1.1.8-p2, it still doesn't work. Or even 1.1.8. And it was working in alpha, because I tested it a few days ago.

Could it be a problem on DFN side ?

[Athemis]

Yep you're right. Downgrading doesn't help, even a fresh install of anything down to 1.1.7 doesn't help.

Could it be a problem on DFN side ?

I'll check if they've changed anything regarding their certificate chain.

[NicolasCARPi]

Yeah thanks, it'll be easier for you (language-wise).

[cbgorman]

Responding to the request for more information:

Installed version: 1.1.8-p2
on a digital ocean droplet running Ubuntu 14.04 x64
PHP 5.5.9-1ubuntu4.11
openSSL 1.0.1f

I didn't customize -- followed the directions at doc/_build/html/install-drop.html

[Athemis]

Just a quick update: The certificate chain is unchanged (aka "the good news") and I can reproduce the faulty behavior with OpenSSL on on the command line level.

The bad news is that we're probably hitting an OpenSSL issue first noticed back in 2013:

• http://openssl.6102.n7.nabble.com/possible-Bug-in-OpenSSL-rfc-3161-TSA-service-tt43128.html#none

The summary is that OpenSSL can't digest TS replies well if attribute certificates are added to them. This scenario (although conformant to the rfc3161) is not supported by OpenSSL. My best guess is that the guys at DFN changed the way their TS replies are formed (software update, etc.). I'll try to get in contact with them to figure out if they are able (and willing) to fix their service for OpenSSL users again. There's absolutely nothing we can do in the meantime (aka "the really bad news").

The consequences are that any timestamps generated before DFN broke for us will still validate because the stored binary responses are ok for OpenSSL, but you will not be able to generate new ones.

I'll report back as soon as I get a response from the DFN.

Cheers,
Alex

[NicolasCARPi]

Yep, thanks for the update Athemis, I saw the page you linked before.

[Athemis]

I got an answer from the DFN. They are aware of the issue. They intentionally included an Attribute Signing Certificate (RFC5035 and RFC5816) to improve security by providing a mechanism to identify the signing certificate inside the timestamping response which means that my initial guess concerning the cause of our problems was correct. They now thoroughly use SHA-2 during the timestamping process which is currently unsupported by openssl. This change happened on April 14th, any timestamps generated before that date will validate without problems. My contact at DFN pointed out that there is a patch under discussion at the openssl github page: openssl/openssl#771

A patched openssl should work again without any problems in combination with the DFN service. Until the patch is mainlined you have to patch openssl yourself. Furthermore they are developing a small java program to verify RFC3161 timestamps and will publish it when it's ready. The release will be announced here: https://blog.pki.dfn.de

Our options are:

1. Wait for the patch beeing mainlined in openssl
2. Patch openssl yourself if using DFN
3. Wait for the DFN to publish their verification tool (which will be usable for all RFC3161 timestamps not only those from the DFN) and provide a backend for their tool as an alternative/in addition to openssl

Cheers,
Alex

EDIT:

To be more precise what the DFN changes mean: They are enforcing at least SHA256 hashes throughout the whole timestamping prodecure including the fingerprints of the signing certificate. In OpenSSL this is hardcoded to SHA1 and that's why it fails.

[NicolasCARPi]

Ok thanks Athemis for this information. I think we'll go with option 1. And maybe I can disable the verification step in timestamping until openssl is patched. And show a message referencing this issue.

[Athemis]

I would opt for keeping the verification functional. There is no point in timestamping if the timestamps are not verified. This issue is not present for all TSAs but only for those who add attribute certificates. We can catch the error message from openssl and display a more meaningful error instead, pointing out that the timestamp cannot be validated because of shortcomings in openssl and suggesting the user to install a patched openssl version or (when mainlined) urging to update to a recent openssl version. Imho that's more transparent then just pretending everything is fine although no verification is done at all.

[NicolasCARPi]

I agree the problem might not arise for another TSA, but I highly doubt people are using something else than the default…

Now I agree that timestamping without actually verifying is useless, so I'll do what you suggest, catch this specific error and display a message :)