With the growing scale and complexity of attacks on Internet infrastructure, traditional domain validation models have stopped meeting the requirements of modern public PKI. In response to real threats such as selective DNS spoofing and regional BGP hijacking, global certificate authorities, including DigiCert and Sectigo, implemented the mandatory Multi-Perspective Issuance Corroboration (MPIC) mechanism in 2025.

MPIC is not a cosmetic procedural change. It is a redesign of one of the key elements of trust on the Internet, namely the method used to confirm that the entity requesting a certificate actually controls the given domain on a global scale rather than only locally.

Why the traditional DCV model is no longer sufficient?

Until recently, Domain Control Validation was based on the assumption that:

• the DNS or HTTP response seen by the certificate authority reflects the actual state of the domain,
• the network from which validation is performed represents the global Internet,
• any propagation differences are short-lived and insignificant.

Practical experience from recent years has shown that these assumptions are incorrect. Infrastructure attacks increasingly do not involve a global takeover of a domain, but rather a temporary and regional manipulation of routing or DNS responses. In such a scenario:

• the certificate authority sees a correct record,
• the domain owner sees a correct record,
• but only from a single perspective controlled by the attacker.

This was sufficient to issue an unauthorized certificate. MPIC was designed precisely to permanently close this attack vector.

What is Multi-Perspective Issuance Corroboration in practice?

MPIC is a mechanism in which the certificate authority:

• performs domain validation simultaneously from multiple independent network perspectives,
• uses autonomous systems and different network operators,
• compares DNS, CAA, and HTTP/HTTPS responses obtained from different regions of the world.

The key word here is independent. MPIC perspectives are not only geographically distributed. They must be logically separated so that a single routing incident, operator error, or local manipulation cannot affect the entire process. If even one perspective:

• does not receive a response,
• receives a different response,
• is blocked by a firewall or WAF,

the validation is considered inconsistent and the certificate issuance process is interrupted.

MPIC as a new standard for trust chain security.

From the perspective of the PKI ecosystem, MPIC plays a role similar to Certificate Transparency. It is not a mechanism visible to the end user, but it significantly increases the security of the entire system.

The implementation of MPIC:

• reduces the risk of issuing a certificate based on a manipulated DNS view,
• limits the effectiveness of short-term BGP attacks,
• enforces greater configuration discipline on domain owners.

For the industry, this is a clear signal that public PKI is no longer willing to trust single observation points.

“Status Pre-signed Failed” what does this error really mean?

In the context of MPIC, the message Status Pre-signed Failed often appears. This is not a technical failure of the certificate authority or a system outage. It indicates that:

• domain validation did not pass the multi-perspective consistency check,
• at least one MPIC perspective did not confirm control over the domain,
• the client infrastructure is not fully reachable on a global scale.

In practice, this means that the domain works correctly locally but does not meet the requirements of global observability that MPIC treats as a necessary condition of trust.

Most common causes of MPIC issues in production environments.

Inconsistent CAA records.

The CAA record must be identical and globally visible. MPIC very quickly detects situations in which:

• different DNS servers return different values,
• the DNS zone has been only partially updated,
• changes were introduced too shortly before validation.

In the MPIC era, temporary inconsistency is no longer acceptable.

Network restrictions and security filters.

Firewalls, WAFs, or CDNs that:

• block traffic from specific regions,
• filter requests based on User-Agent,
• apply aggressive rate limiting mechanisms,

can effectively prevent MPIC validation even though the domain works correctly for users.

Overly aggressive TTL and automation.

Modern DevOps pipelines often:

• reduce TTL to the minimum,
• automatically remove validation files,
• apply DNS changes immediately after the first positive check.

In the MPIC model, this approach leads to random and difficult-to-diagnose errors.

How to prepare infrastructure for MPIC. An operational approach.

MPIC forces a change in how certificate validation is perceived. It is no longer a one-time operation, but a test of global infrastructure consistency. Recommended actions include:

• DNS audits from multiple locations,
• reviewing security rules for validation traffic,
• stabilizing TTL values and validation procedures,
• educating technical teams that DCV is a multi-stage process.

FAQ Multi-Perspective Issuance Corroboration.

1. Is MPIC mandatory?

Yes. For publicly trusted SSL/TLS certificates, MPIC is now a standard rather than an option.

2. Does MPIC apply to all certificate types?

It applies to DV, OV, and EV certificates. Each requires DCV, and DCV is subject to MPIC.

3. Does MPIC affect certificate issuance time?

It may extend issuance time if the domain infrastructure is not globally consistent.

4. Are local DNS tests sufficient?

No. MPIC requires response consistency across multiple networks simultaneously.

5. Can a CDN cause MPIC issues?

Yes, especially with geo-blocking, WAF rules, or non-standard traffic filters.

6. Is a CAA record always required?

It is not mandatory, but if present, it must be correct and globally consistent.

7. Is a short TTL an error?

No, but very short TTL values increase the risk of inconsistencies during MPIC validation.

8. Does MPIC detect BGP attacks?

Not directly, but it effectively prevents their use for certificate issuance.

9. Does MPIC apply only to DNS?

No. It also covers HTTP and HTTPS depending on the DCV method.

10. Can MPIC be disabled?

No. It is part of the security policy of certificate authorities.

11. Do test environments also fall under MPIC?

Yes, if a publicly trusted certificate is being requested.

12. Is IP allowlisting for certificate authorities required?

In highly filtered environments, it is often necessary.

13. Does MPIC affect automatic certificate renewals?

Yes. Renewals also undergo full DCV validation.

14. Does MPIC increase end-user security?

Yes. It reduces the risk of issuing fraudulent certificates.

15. Is MPIC a temporary change?

No. It is a permanent element of public PKI architecture.

Multi-Perspective Issuance Corroboration is one of the most important steps in the evolution of trust on the Internet in recent years. MPIC clearly demonstrates that certificate security does not end with cryptography. Global consistency of DNS and network infrastructure is equally critical.

For domain owners and administrators, this is the moment to view SSL certificates not as a product, but as a security process that requires conscious management. At HEXSSL, we treat MPIC as a natural and necessary stage in the maturity of public PKI.