OLD | NEW |
1 This directory contains test data for verifying certificate chains. | 1 This directory contains test data for verifying certificate chains. |
2 | 2 |
3 It contains the following types of files: | 3 Tests are grouped into directories that contain the keys, python to generate |
| 4 chains, and test expectations. "DIR" is used as a generic placeholder below to |
| 5 identify such a directory. |
4 | 6 |
5 =============================== | 7 =============================== |
6 generate-*.py | 8 DIR/generate-chains.py |
7 =============================== | 9 =============================== |
8 | 10 |
9 Generates the file for an individual test case. If the python file was | 11 Python script that generates one or more ".pem" file containing a sequence of |
10 named generate-XXX.py, then the corresponding output will be named | 12 CERTIFICATE blocks. In most cases it will generate a single chain called |
11 XXX.pem. | 13 "chain.pem". |
| 14 |
| 15 =============================== |
| 16 DIR/keys/*.key |
| 17 =============================== |
| 18 |
| 19 The keys used (as well as generated) by the .py file generate-chains.py. The |
| 20 private keys shouldn't be needed to run the tests, however are useful when |
| 21 re-generating the test data to have stable results (at least for signature |
| 22 types which are deterministic, like RSASSA PKCS#1 which is used by most of the |
| 23 certificates data). |
| 24 |
| 25 =============================== |
| 26 DIR/*.pem |
| 27 =============================== |
| 28 |
| 29 A sequence of CERTIFICATE blocks that was created by the generate-chains.py |
| 30 script. (Although in a few cases there are manually created .pem files that |
| 31 lack a generator script). |
| 32 |
| 33 =============================== |
| 34 DIR/*.test |
| 35 =============================== |
| 36 |
| 37 A sequence of key-value pairs that identify the inputs to certificate |
| 38 verification, as well as the expected outputs. The format is essentially a |
| 39 newline separated sequence of key/value pairs: |
| 40 |
| 41 key: value\n |
| 42 |
| 43 All keys must be specified by tests, although they can be in any order. |
| 44 The possible keys are: |
| 45 |
| 46 "chain" - The value is a file path (relative to the test file) to a .pem |
| 47 containing the CERTIFICATE chain. |
| 48 |
| 49 "last_cert_trust" - The value identifies the trustedness of the last |
| 50 certificate in the chain (i.e. whether it is a trust anchor or not). This |
| 51 maps to the CertificateTrustType enum. Possible values are: |
| 52 "TRUSTED_ANCHOR" |
| 53 "TRUSTED_ANCHOR_WITH_CONSTRAINTS" |
| 54 "UNSPECIFIED" |
| 55 "DISTRUSTED" |
| 56 |
| 57 "utc_time" - A string encoding for the generalized time at which verification |
| 58 should be done. Example "150302120000Z" |
| 59 |
| 60 "key_purpose" - The expected EKU to use when verifying. Maps to |
| 61 KeyPurpose enum. Possible values are: |
| 62 "ANY_EKU" |
| 63 "SERVER_AUTH" |
| 64 "CLIENT_AUTH" |
| 65 |
| 66 "errors" - This has special parsing rules: it is interpreted as the |
| 67 final key in the file. All lines after "errors:\n" are read as being the |
| 68 error string (this allows embedding newlines in it). |
| 69 |
| 70 Additionally, it is possible to add python-style comments by starting a line |
| 71 with "#". |
12 | 72 |
13 =============================== | 73 =============================== |
14 generate-all.sh | 74 generate-all.sh |
15 =============================== | 75 =============================== |
16 | 76 |
17 Runs all of the generate-*.py scripts and does some cleanup. | 77 Runs all of the generate-chains.py scripts and cleans up the temp files |
18 | 78 afterwards. |
19 =============================== | |
20 keys/XXX/*.key | |
21 =============================== | |
22 | |
23 The keys used/generated by test XXX. The private keys shouldn't be needed to run | |
24 the tests, however are useful when re-generating the test data to have stable | |
25 results (at least for signature types which are deterministic, like RSASSA | |
26 PKCS#1 which is used by most of the certificates data). | |
27 | |
28 =============================== | |
29 *.pem | |
30 =============================== | |
31 | |
32 Each .pem file describes the inputs for certificate chain verification, and the | |
33 expected result. These are the PEM blocks that each file contains and their | |
34 interpretation: | |
35 | |
36 CERTIFICATE: | |
37 | |
38 These PEM blocks describe the ordered chain of certificates starting from the | |
39 target certificate and progressing towards the trust anchor (but not including | |
40 the trust anchor). | |
41 | |
42 - There must be one or more such PEM blocks | |
43 - Its contents are a DER-encoded X.509 certificate | |
44 - The first block is the target certificate | |
45 - The (i+1)th CERTIFICATE is (allegedly) the one which issued the ith | |
46 CERTIFICATE. | |
47 | |
48 TRUST_ANCHOR_{XXX}: | |
49 | |
50 This PEM block describes the trust anchor to use when verifying the chain. | |
51 There are two possible names for this PEM block, which affect how it is | |
52 interpreted: TRUST_ANCHOR_CONSTRAINED or TRUST_ANCHOR_UNCONSTRAINED. | |
53 | |
54 - There must be exactly one TRUST_ANCHOR_{XXX} block. | |
55 - Its contents are a DER-encoded X.509 certificate | |
56 - The subject and SPKI from the certificate define the trust anchor | |
57 - If the block was named TRUST_ANCHOR_CONSTRAINED, then any constraints on the | |
58 certificate are also considered normative when verifying paths. Otherwise | |
59 any standard extensions provided by the root certificate are not used during | |
60 path validation. | |
61 | |
62 TIMESTAMP: | |
63 | |
64 This PEM block describes the time to use when verifying the chain. | |
65 | |
66 - There must be exactly one such PEM block | |
67 - Its contents are a DER-encoded UTCTime. | |
68 | |
69 VERIFY_RESULT: | |
70 | |
71 This PEM block describes the expected result from verifying the path. | |
72 | |
73 - There must be exactly one such PEM block | |
74 - Its contents are a string with value of either "SUCCESS" or "FAIL" | |
75 | |
76 ERRORS: | |
77 | |
78 This PEM block is a pretty-printed textual dump of all the errors, as given by | |
79 CertErrors::ToDebugString(). | |
OLD | NEW |