Audit Results Session 2015.4

Audit Type

Operational Audit

Report Status

Final Report

Audit initiated by

Directive of Board

Audit Subject

Audit over Test Root Re-Signing

Follow up status

2015-10-14 Send to Board for approval

2015-10-25 Approved by board in m20151018.1

Executive Summary

The cryptographic hash function MD5 is depreciated and its support will be removed from all browsers in the future. CAcert is using MD5 as hash algorithm in its self-signed root certificate. This would be no problem, since it is the trust anchor by itself but the removal of browser support will make the use impossible on one day.

For this reason, the software team created a github repository with scripts re-signing the current root certificates using SHA256 as signature algorithm; based on Bug 1305.

During the audit four recommendations have been identified.

Purpose, Scope and Methodology

Re-signing root keys is - as generating them - a significant task for a certificate authority. It should be carefully designed and monitored. To validate the correctness and completeness is therefore an important task. The test run on root re-signing has exactly the goal to provide evidence on correctness and completeness of the process, while audit verifies additionally the sanity of the keys generated. The Audit was conducted as an inspection of the process. The scripted process was validated.

The process to audit includes only the review of the generation scripts, the preparation (build and sign the software) and the resigning of the certificate itself, the transferral of the keys to data center and any further steps are not part of the audited process.

Audit Results and Recommendations

Tool review

The software and the script to re-sign the root certificate with SHA256 has been audited. There is no objection with software and tool. Prior use with CAcert's root keys, two formal software assessments must be done and the procedure accepted by board.

Test run attendance

The test generation session was attended by BennyBaumann (Lead), FelixDörre, WytzevanderRaay (Critical Admin, Acting), MartinSimons (Critical Admin), MartinGummi (Observer), BenediktHeintel (Protocol), MarcusMaengel (Observer, 1st run only), DirkAstrath (Observer, 2nd run)

Test run preparation

Test run preparation I protocol

All steps at the notebook had been conducted by WytzevanderRaay:

  1. Notebook booted from live CD
  2. Start rypescript/timelog for logging activities on the console
  3. Mounted USB stick with source code
  4. installed additional packages from stick
  5. Copy source code from USB stick to /ramdisk
  6. Generated public-private key pair with key size 2048 bit
  7. Divided public key from private key
  8. Displayed fingerprint of public key:

37ef a6a2 6692 bcc2 e610 f5c7 
4306 ee2f 6618 8b80 7c1d 96b8 
d83c 81a4 3369 0655
  1. Validated source codes fingerprint (hash value), last minute changes approved by BennyBaumann

Disturbance of the re-signing test session for non-urgent business for about 10 minutes. The procedure was not compromised, but the participants concentration was for the next 15 minutes

  1. Created signature for test root key with private key
  2. Stored software, fingerprints, and public key on USB stick
  3. Deleted private key
  4. Copied transcript to online USB stick
  5. Unmounted USB sticks and shut down notebook

Decision to automate the software build and signing process and reduce the steps needed. 45 minutes break before the second test run.

Test run preparation II protocol

Created script for certificate re-sign.

SHA256 fingerprint of

602b 8c23 17ea 8afa 1e84 b845
0cb4 0aa4 abcf f499 f1c8 fcee
bddd 81be 4578 a9ab
  1. Notebook booted from live CD
  2. Start typescript/timelog for logging activities on the console
  3. Mounted USB stick with source code
  4. installed additional packages from stick
  5. Copy source code from USB stick to /ramdisk
  6. Unmounted USB stick with source code
  7. Mounted plain USB stick
  8. Verified SHA256 hash sum of (matches)

  9. Run

  10. Displayed fingerprint of public key:

8d96 662f e571 c54d 9cb3 b466
bacf 8e0c fbd0 6102 8fb1 6243
9a56 c724 4e3b 3f11
  1. Script finished successfully
  2. Stored typescript on USB stick
  3. Unmounted USB stick and shut down notebook

Test run re-signing protocol

The actual re-sign must be done on the signer; the test run was conducted on same notebook used for the preparation.

  1. Notebook booted from live CD
  2. Start typescript/timelog for logging activities on the console
  3. Created needed directories in /ramdisk
  4. Mounted USB stick with source code
  5. Mounted USB stick with signer software
  6. Unencrypted root.crt with root.key

  7. Re-signing software main executed; finished without error

  8. Checked results of root_256.crt:

Hash Algorithm: SHA256
x509v3CRL distribution point added
NetscapeCARevocationURL added
AuthorAuthorityInformationAccess (OCSP) added
  1. copied root_256.crt and typescript to USB stick

  2. Unmounted USB stick and shut down notebook

The content from the sealed envelope and the Re-signed Test Server root Certificate.

Certificate handling

There are two sets of the USB sticks created. Each USB stick put in one envelope, both envelops sealed,

BenediktHeintel is supposed to disclose the content of his stick after the installation of the new root on the test server.


The process description was read aloud and followed during the creation with the following mutual between Software, Critical Admins, and Audit agreed derivations:

All of these derivations are okay since this was only a test run. Nevertheless, the decision was unanimously taken, to use the re-signed certificate for the test root signer. The certificate is therefore flagged as test root certificate.




  1. Enclose the last echo commands in in quotation marks. (implemented)

  2. Transfer the procedure from github to CAcert's Wiki.
  3. Disturbance should be avoided under all circumstances. Before the session, every mobile phone and pager should be switched off and put on top of a table, also the door should be closed during the session and entering and leaving the room should be forbidden while the session is running. (This of course does not apply in a case of emergency.)
  4. Have USB sticks of different brands available to avoid failures of hardware and compatibility issues.


-- BenediktHeintel 2015-10-14 19:40:17

Audit/Results/session2015.4 (last edited 2015-12-11 22:14:44 by BenediktHeintel)