1523680 - Actalis: Non BR Compliant OCSP Responder

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

The OCSP responder for the Actalis Client Authentication CA G1 is currently returning a "good" response for unknown certificates, as reported at https://crt.sh/ocsp-responders?trustedExclude=constrained%2Cexpired%2Conecrl&trustedBy=Mozilla&trustedFor=Server+Authentication&dir=v&sort=2&url=&get=&post=&randomserial=good

Please provide an incident report for this problem, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 1

[Adriano Santoni]

The "Actalis Client Authentication CA G1" subordinate only issues S/MIME certificates, so we assume it is not be subject to the OCSP Responder compliance requirements set forth in the BR.

Comment 2

[Ryan Sleevi]

It is technically capable of such issuance; https://crt.sh/?id=12716308 lacks any constraints that would prohibit such. As a consequence, if this sub-CA were compromised, it would be capable of issuing a TLS certificate, and the choice to respond to such serial would be indistinguishable from the situation that arose w/r/t DigiNotar.

Comment 3

[Adriano Santoni]

We have modified the configuration of that OCSP responder so to return an "unknown" response for unknown certificates.

Comment 4

[Wayne Thayer]

Confirmed that the problem has been fixed.

Adriano: as described in comment #2, this is a violation of Mozilla policy. Please provide an incident report as requested.

Comment 5

[Adriano Santoni]

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

We first became aware of the problem when this Bugzilla bug #1523680 was filed by Wayne Thayer on Jan 29, 2019.

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

(all times below are GMT+1)
2019-01-29 18:01 We received notification via email that this bug was filed on Bugzilla.
2019-01-30 08:30 We started investigations on the raised issue. That included querying the involved OCSP responder for known and unknown certificates, reviewing the relevant sections of the Mozilla Root Store Policy and of the BR, and internal discussions on why the said OCSP responder was configured the way it was.
2019-01-30 15.30 We came to the conclusion that a change of configuration of the said OCSP responder was in order. Therefore a Change Request was filed into our internal configuration management system. The change was planned for next day early morning.
2019-1-31 08:30 The configuration of the said OCSP Responder was changed and the responder was immediately re-tested to make double-sure the change was effective.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

No certificate mis-issuance has occurred.

The OCSP responder's configuration was changed on Jan 31, 2019, at approx 08:30 (GMT+1) and the change was immediately effective.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

None (see point #3).

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

Not applicable (see point #4).

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

It was our understanding that for the involved SubCA, since it only issues S/MIME certificates, the BR requirement <<MUST NOT respond with a "good" status for such [unknown] certificates>> was not applicable. After this bug was filed, we realized that our assumption was wrong, as we did not take into account the fact that such SubCA is not technically constrained.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

In addition to quickly correcting the configuration of the involved OCSP responder, an internal "awareness" meeting was held with the interested company departments aimed at clarifying that for any non-technically-constrained SubCA under our trusted Root, regardless of what kind of certificates it issues, the associated OCSP responder must be configured so as to never respond "good" for unknown certificates.

Comment 6

[Wayne Thayer]

(In reply to ADRIANO SANTONI from comment #5)

Adriano: thank you for this incident report.

In addition to quickly correcting the configuration of the involved OCSP responder, an internal "awareness" meeting was held with the interested company departments aimed at clarifying that for any non-technically-constrained SubCA under our trusted Root, regardless of what kind of certificates it issues, the associated OCSP responder must be configured so as to never respond "good" for unknown certificates.

It is not just the OCSP responder requirement. All certificates signed by non-technically-constrained subordinate CA certificates under your trusted root must fully comply with all Mozilla requirements. Please confirm that Actalis understands this.

Comment 7

[Adriano Santoni]

We understand this.