EJBCA - Open MPIC Issues and Impacted CAs

[Wayne]

On 2026-04-03 SSL.com proactively published a preliminary incident report 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.

There are quite a few 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

[Henry Birge-Lee]

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.

Best,

Henry

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/fd9c43c1-512d-44d7-9601-bdbc61df4bcen%40mozilla.org.

[Dimitris Zacharopoulos]

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 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 <rdau...@gmail.com> wrote:

On 2026-04-03 SSL.com proactively published a preliminary incident report 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.

There are quite a few 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 "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/fd9c43c1-512d-44d7-9601-bdbc61df4bcen%40mozilla.org.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

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.

[Dimitris Zacharopoulos]

On 4/6/2026 8:31 PM, Wayne wrote:

On 2026-04-03 SSL.com proactively published a preliminary incident report 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.

Hi Wayne,

I just want to clarify that HARICA was not alerted by a security researcher regarding this issue.

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.

Indeed, that's what we currently use for guidance as well. Please note that some CAs had mass revocation procedures even before the requirement from Mozilla, but the policy change pushed for very meaningful improvements to support worst case scenarios (like mass revocation within 24 hours). Having these steps already prepared is extremely helpful in time-sensitive situations like mass-replacement of certificates which precedes the 24-hour mass-revocation. 

Currently only one other CA has reported having the same issue: HARICA.

There are quite a few CAs using EJBCA, I'd be surprised if it were limited to only these two CAs.

They would have to be using the ACME service from EJBCA.


Thanks,
Dimitris.

Could any CA using EJBCA prioritize checking if they are impacted by this issue? The longer this waits, the more certificates will be impacted.

[Fabien Hochstrasser]

Hi,

I am posting this message on behalf of Google Trust Services.
We stopped using EJBCA in 2023. As such, no certificates issued by Google Trust services are affected by this bug.

Best regards,
Fabien