There is now an "Audit Letter Validation (ALV)" button on intermediate
certificate records in the CCADB. There is also a new task list item on
your home page. In the summary section you will see a line item like the
"Intermediate Certs with Failed ALV Results: 8"
When that is non-zero, you will see a section that can be opened called
"Check failed Audit Letter Validation (ALV) results"
Instructions for the new task list item:
The intermediate certificates listed below have a failed Audit Letter
Validation (ALV) result. Please check the intermediate certificate to
make sure its SHA-256 Fingerprint is correctly listed in the
corresponding audit statements. If you do not agree with the ALV
results, add comments to the ‘Standard Audit ALV Comments’ or ‘BR Audit
ALV Comments’ fields in the intermediate certificate record.
If you find that the SHA-256 fingerprint of an intermediate certificate
is indeed missing from the applicable audit statement(s) and the
certificate chains to a root that is trusted by Mozilla, then create a
Bugzilla bug to provide an incident report along with your plan and
timing to resolve the problem, as described here:
Then add the link to the Bugzilla Bug to the ‘Standard Audit ALV
Comments’ or ‘BR Audit ALV Comments’ field for that certificate.
ALV will sometimes report that it was unable to find the SHA-256
fingerprint of the certificate even though it is in the audit statement.
When you find this to be the situation, please add a comment to the
‘Standard Audit ALV Comments’ or ‘BR Audit ALV Comments’ field in the
record to state that the SHA-256 fingerprint for that cert is in the
To help improve accuracy of ALV finding SHA-256 fingerprints have your
auditors follow these guidelines for the SHA-256 fingerprints that are
listed in the audit statements as being in scope of the audits:
- MUST: No colons, no spaces, and no linefeeds
- MUST: Uppercase letters
- SHOULD: be encoded in the document (PDF) as “selectable” text, not an
Note, the new task list item focuses on the SHA-256 Fingerprints that
are not found in the audit statements, but there are also many failures
regarding dates that we would like resolved in future audit statements.
So please have your auditors use the following date format guidelines in
all future audit statements.
Accepted date formats (month names in English):
- Month DD, YYYY example: May 7, 2016
- DD Month YYYY example: 7 May 2016
- YYYY-MM-DD example: 2016-05-07
- No extra text within the date, such as “7th” or “the”
-- Implementation Details Below --
The new task list item is filtered as follows.
CA Owner/Certificate Record Type equals Intermediate Certificate
AND Technically Constrained equals False
AND Revocation Status equals Not Revoked
AND OneCRL Status not equal to Added to OneCRL
AND Valid To (GMT) greater than TODAY
AND ((Mozilla Root Status equals Included or Change Requested)
OR (Microsoft Root Status equals Included or Change Requested))
AND ((Standard Audit ALV Found Cert equals FAIL)
OR (BR Audit ALV Found Cert equals FAIL))
The "Standard Audit ALV Found Cert" and "BR Audit ALV Found Cert" are
set according to the ALV result AllThumbprintsListed, which looks for
the cert's SHA-256 fingerprint in the corresponding audit statement.
There is a "Derived Trust Bits" field in the "Certificate Data [Fields
NOT editable; extracted from PEM]" section. Very high level logic: If
the cert has EKU in it, then that will be used. Otherwise see which root
store it's parent root cert is in. If in both Mozilla and Microsoft then
create union of the trust bits that the parent/root cert is trusted for.
When "Derived Trust Bits" contains 'Server Authentication', then ALV is
run on the BR audit. Currently, for intermediate certs, we are only
processing the standard and BR audit statements.
When "Audits Same as Parent" is checked, CCADB will look up the parent
chain until audit statements are found, and run ALV using those audit
statements. When "Audits Same as Parent" is not checked, then CCADB will
just pass the audit statements in the intermediate cert record into ALV.
As always, I will appreciate thoughtful and constructive feedback on
this, especially as you try out the new functionality.
dev-security-policy mailing list