Peppol PKI 2025 - Certificate Authority Migration Plan

PDF version

Abbreviations and terms used in this document.

During the second half of 2025, every Peppol Service Provider must replace the certificates it currently uses, which are issued under the current DigiCert Managed PKI v8 (MPKI8) root and intermediate certificate authorities (CAs), with certificates issued under the newly created DigiCert One Trust Lifecycle (DOTL) root and intermediate CAs. After this initial reference, the terms old PKI and new PKI are used throughout this document to keep the wording concise.

DigiCert will retire the old PKI issuance service on 1st of April 2026. From that date no new or replacement certificates can be issued under the old CA chain. Service Providers that have not switched to the new PKI by then will be unable to renew their old certificates and therefore eventually unable to operate on the Peppol Network.

Existing certificates issued under the old PKI remain valid only until the network-wide revocation on 1st April 2026 or their individual expiry date, whichever comes first. DigiCert will continue to publish CRL/OCSP status for them up to that point. Because the new PKI cannot inherit old keys or certificates, every Service Provider must request new certificates under the new PKI CA chain for both the Test- and Production environments.

Based on experience from earlier PKI transitions in the Peppol Network, no production certificates under the new PKI will be issued until a Service Provider has:

• Obtained test certificates from the new PKI, and

• Proved dual-capability conformance in the Peppol Testbed.

This gate‑keeping milestone ensures that every Service Provider’s technical solution aligns with the new trust model and maintains full interoperability throughout the migration.

The PKI migration follows three clearly defined milestones with six months between T0 and T1 to give Service Providers predictable change windows:

Key rule: No new PKI production certificate shall be issued until the holder has met the following preconditions which must both be fulfilled before T1:

1. Must have obtained new PKI test certificates and 

2. Must have demonstrated full conformance, as verified by the Peppol Testbed.

Detailed tasks, roles, and fallback measures are elaborated in chapters 4 to 6.

This section sets out the actions required of every Service Provider in each migration phase, and the corresponding obligations for the other core components of the Peppol Network.

1. before T0:

   1. Business as usual under the old PKI.

   2. New PKI CA chains published (for both test and production).

2. between T0 and T1: 

   1. Service Providers must request test certificates from the new PKI.

   2. Service Providers must implement dual-capability support for old and new PKI CA chains. They must prove this capability by passing the relevant test suite of the Peppol Testbed.

   3. Peppol core components (SML, Peppol Directory, Peppol Testbed) must implement dual-capability support for old and new PKI CA chains.

   4. New Service Providers joining after T0 will be issued both the old and new PKI test certificates

   5. New Service Providers joining after T0 will be issued only old PKI production certificates until T1. Before obtaining a production certificate, They must also implement dual-capability and pass the relevant test suite of the Peppol Testbed.

3. between T1 and T2:

   1. Issuing of production certificates from the new PKI begins.

   2. Service Providers that have passed dual-capability conformance testing at the Peppol Testbed must request and install new PKI production certificates.

   3. All Service Providers must support both old and new PKI CA chains.

   4. Issuing of old PKI production certificates is no longer allowed.

   5. New Service Providers joining after T1 will be issued both old and new PKI test certificates and will have to pass dual-capability conformance testing at the Peppol Testbed before going into production.

   6. New Service Providers joining after T1 will be issued only new PKI production certificates.

4. after T2:

   1. All issued certificates from the old PKI are revoked at T2.

   2. Old PKI CA chain no longer to be entrusted.

Open

How to implement this from a technical point of view is dependent on the AP or SMP implementation used. There will not be a guideline available for every implementation, but the general approach is described in the following sections.

1. From T0 promptly request new PKI test certificate.

2. Before T1 import new PKI CA chain into application trust store.

3. Before T1 replace old PKI test certificate with new PKI test certificate in non-production environment. Make sure to update test SMP entries to reflect this change. Run and complete Peppol Testbed AP migration conformance tests.

4. After T1 (and passed Peppol Testbed AP migration conformance tests) request new PKI production certificate.

5. Before T2 swap old PKI production certificate to new PKI production certificate (in production environment). Make sure to update SMP entries to reflect this change.

6. After T2 remove old PKI CA chain from trust store.

1. From T0 promptly request new PKI test certificate.

2. Before T1 replace old PKI test certificate with new PKI test certificate in non-production environment. Run and complete Peppol Testbed SMP migration conformance tests.

3. After T1 (and passed Peppol Testbed SMP migration conformance tests) request new PKI production certificate.

4. Before T2 swap old PKI production certificate to new PKI production certificate (in production environment).
   Migrate the authorisation certificate in the SML (so that the new PKI production certificate will be accepted by the SML) by using the UC12 Prepare Change Certificate operation at the SML.

5. After T2 remove old PKI CA chain from trust store.

These sections captures scenarios that affect only a subset of Service Providers yet require explicit treatment to keep the migration on schedule and the network stable.

If you are a currently operating Service Provider with issued certificates (whether test or production) from the old PKI then this is how you are expected to act.

If you are a new Service Provider that will be onboarding during the migration, then these are the recommended actions for you.

This section summarises resources that might be necessary for you to leverage during the migration.

The old PKI CA chains are documented and available for download at:

• https://openpeppol.atlassian.net/wiki/x/EACCCw

The new PKI CA chains are documented and available for download at:

• https://openpeppol.atlassian.net/wiki/x/AQDtAgE

All certificate requests, whether for new certificates or renewals or for new or old PKI are raised through the Peppol Service Desk available at:

• https://openpeppol.atlassian.net/servicedesk/customer/portal/1

Furthermore the issuing and enrolment process for the new PKI is documented at the following resource:

• https://openpeppol.atlassian.net/wiki/spaces/OPMA/pages/4439080961

OpenPeppol will publish a set of implementation neutral guides that complement this migration plan. These documents will explain how to execute critical steps while keeping normative what and when in this document.

• https://openpeppol.atlassian.net/wiki/x/C4BaKQ

Illustrative, non-exhaustive topics:

·       Replacing the SMP authorisation certificate in the SML via the UC12 –PrepareChangeCertificate operation.

·       Requesting (and issuing) AP and SMP certificates in the new PKI portal.

·       Verifying dual-capability conformance (old and new PKI) in the Peppol Testbed.

·       A continuously updated FAQ answering common questions that arise during the migration period.