Hi Henry and thank you for the great work leading the OpenMPIC initiative!
On 4/6/2026 10:21 PM, Henry Birge-Lee wrote:
Hi Wayne and all,Thank you for providing this notice Wayne. I agree all CAs (particularly those using Open MPIC + EJBCA) should immediately check their configurations. I will say that based on confidential conversations with Open MPIC users it is my understanding as well that there are many CAs using the combination of EJBCA and Open MPIC.I also wanted to provide a brief statement from the Open MPIC side:Our group maintains the Open MPIC github repositories and we make our best effort to ensure compliance with the Baseline Requirements for aspects that are within the purview of the project (e.g., selection of remote perspectives from an available set, computing correctness of challenges seen by those perspectives etc...). We do not take responsibility for any code or configurations outside of the project including the popular EJBCA integration. We try to have good communication with the maintainers of that project and are always open to ways Open MPIC can help support smooth and compliant usage.Also, our understanding of the issue is that it did not pertain to the multi-perspective check itself (which was performed in a compliant manner via Open MPIC), but was instead caused by the use of Open MPIC solely without a corroborating primary perspective. For web PKI issuance, Open MPIC is always intended to be used in addition to a primary perspective that is performing Baseline-Requirement-Compliant domain control validation and corroborating that result with Open MPIC. No code maintained by Open MPIC is intended to be used for primary perspective domain control validation. There are also important subtle differences between primary DCV and the MPIC DCV (e.g., DNSSEC validation) and open MPIC does not address this.
A quick comment from my side about OpenMPIC. I completely understand the "no guarantees" part of your statement. To be frank, you should not take any responsibility whatsoever, even for code and configurations within the project itself :-) The CA is ultimately responsible for any open source or other software they decide to use for their operations.
A public CA that decides to use OpenMPIC must perform its due diligence to make sure the software is safe to use (security checks) and compliant with the BRs before using it. If a CA decides to use parts or even the entire code, to perform Domain Validation as a Primary Perspective, within its Audit scope, I believe that is doable. Of course, as you correctly highlighted, CAA, MPIC, DNSSEC and all details need to be reviewed to ensure they are properly performed by the primary perspective and not by delegated third parties.
Please also note the recent addition of section 3.2.2.8 of the TLS BRs in section 1.3.2 <https://github.com/cabforum/servercert/blob/main/docs/BR.md#132-registration-authorities> clarifying that CAA is not allowed to be delegated (for the Primary Perspective).
Best, Dimitris.
Best, Henry On Mon, Apr 6, 2026 at 10:31 AM Wayne <[email protected]> wrote: On 2026-04-03 SSL.com proactively published a preliminary incident report <https://bugzilla.mozilla.org/show_bug.cgi?id=2029230> on their use of EJBCA > An incorrect Open MPIC Lambda implementation by the EJBCA ACME service allowed DCV to be completed based only on the remote Network Perspectives. A security reporter had notified them early on 2026-04-02, and presumably have alerted other CAs. To date there's only SSL.com mentioning a report though. The impact is quite large, SSL.com dealt with revoking 1.7m within 24 hours. This should be viewed as a success of the Mass Revocation Plan in practice. Currently only one other CA has reported having the same issue: HARICA <https://bugzilla.mozilla.org/show_bug.cgi?id=2029643>. There are quite a few <https://bugzilla.mozilla.org/buglist.cgi?longdesc_type=allwordssubstr&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=INACTIVE&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=SUPPORT&resolution=EXPIRED&resolution=MOVED&query_format=advanced&product=CA%20Program&component=CA%20Certificate%20Compliance&longdesc=ejbca&list_id=17917927&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other> CAs using EJBCA, I'd be surprised if it were limited to only these two CAs. Could any CA using EJBCA prioritize checking if they are impacted by this issue? The longer this waits, the more certificates will be impacted. - Wayne -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/fd9c43c1-512d-44d7-9601-bdbc61df4bcen%40mozilla.org <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/fd9c43c1-512d-44d7-9601-bdbc61df4bcen%40mozilla.org?utm_medium=email&utm_source=footer>. --You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAGxVKU4cmUKo26m7_iHu%2B15RhmiP6FrukiBvmLGQQ-O%3D4yC4aQ%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAGxVKU4cmUKo26m7_iHu%2B15RhmiP6FrukiBvmLGQQ-O%3D4yC4aQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
-- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/36cce399-fcbc-42c7-b07f-c67a439e476b%40it.auth.gr.
smime.p7s
Description: S/MIME Cryptographic Signature
