/
Peppol PKI 2025 - Dedicated Migration Guideline

Peppol PKI 2025 - Dedicated Migration Guideline

Glossary

Abbreviation

Meaning

Abbreviation

Meaning

G2

Refers to the legacy generation of the Peppol PKI

G3

Refers to the next generation of the Peppol PKI

SML

Service Metadata Locator

SMP

Service Metadata Publisher

Purpose & Scope

This page documents more technical aspects related to the Peppol PKI Certificate Authority Migration 2025 that are non-normative character. It also contains an FAQ section to add commonly asked questions that might arise during the execution of the migration.

SMP Authorisation Certificate Migration

The SMP certificate is used for authorisation when registering and deregistering participants in the SML. This section outlines the steps required to migrate from an old G2 SMP certificate to a new G3 SMP certificate for use in SML authorisation.

The process is identical to the standard certificate renewal procedure already familiar to SMP Service Providers, who must announce renewed certificates to the SML in advance of expiration.

To perform the migration, the UC12 – PrepareChangeCertificate operation defined in the SML Interface Control Document (ICD) v1.06 is used.

Certificate Migration Steps

  1. Prerequisites

    1. The SMP currently has a valid old G2 SMP certificate registered with the SML.

    2. A new G3 SMP certificate has been issued and is available on PEM/X.509 format.

    3. The SMP Service Provider is able to invoke BDMSL operations in the SML (e.g. using native support in the SMP implementation or external tools such as cURL or SOAP clients).

  2. Call PrepareChangeCertificate

    1. Prepare the PrepareChangeCertificate request XML:

      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ec="ec:services:wsdl:BDMSL:data:1.0"> <soapenv:Header/> <soapenv:Body> <ec:PrepareChangeCertificate> <ec:newCertificatePublicKey>?</ec:newCertificatePublicKey> <ec:migrationDate>?</ec:migrationDate> </ec:PrepareChangeCertificate> </soapenv:Body> </soapenv:Envelope>

      • newCertificatePublicKey - Paste the full PEM-formatted public part of your new G3 SMP certificate here.

      • migrationDate - You must provide a future date relative to the current time in the CEST timezone, e.g. '2025-12-05'.

    2. Invoke the PrepareChangeCertificate operation on the SML interface using the old G2 SMP certificate for authentication but with the new G3 SMP certificate specified in the request XML.

  3. Wait for the specified migrationDate

    1. The certificate switch will not take effect immediately. The migration will occur at the specified migrationDate, typically around 01:00 AM CEST.

    2. Once the migration cutoff time has passed, you should verify that the new G3 SMP certificate is active and functional. You can do this by:

      • Attempting to register or deregister a participant using your SMP client (that should now be configured with your new G3 certificate for authentication towards the SML).

Requesting Certificates

The complete process related to requesting, being issued and enrolling for certificates is described in the following document:

FAQ

Between T0 and T1:

  • An AP Service Provider MUST sign and encrypt using the old G2 PKI.

  • An AP Service Provider MUST trust the old G2 PKI CA chains.

  • An AP Service Provider MAY proactively trust the new G3 PKI CA chains to ensure a smooth transition and avoid a last-minute cut-off when dual trust becomes mandatory.

Between T1 and T2:

  • An AP Service Provider MUST sign and encrypt using either old G2 or new G3 PKI.

  • An AP Service Provider MUST trust both the old G2 and new G3 PKI CA chains.

After T2:

  • An AP Service Provider MUST sign and encrypt using the new G3 PKI.

  • An AP Service Provider MUST trust only the new G3 PKI CA chains.


Sending AP (between T1 and T2):
An Access Point acting as as the sender MUST support the following capabilities:

  1. SMP Lookup & Signature Validation
    The Sending AP retrieves the Signed Service Metadata from the SMP. The signature on this metadata may use either an old G2 or new G3 SMP certificate. The Sending AP MUST be able to validate and trust the signature in either case.

  2. Encryption using the Announced Certificate:
    The certificate included in the Signed Service Metadata (used for encryption and signalling) may be an old G2 or new G3 AP certificate. The Sending AP MUST be able to use this announced certificate to encrypt the business document, regardless of PKI version.

  3. AS4 Signal Message Validation:
    After sending the business document, the Sending AP receives an AS4 Signal Message synchronously signed by the Receiving AP. This signature MUST match the certificate previously announced in the SMP lookup. The Sending AP MUST be able to validate and trust the signal message signature, regardless of whether the used certificate is an old G2 or new G3 certificate.

Receiving AP (between T1 and T2):
An Access Point acting as the receiver MUST support the following capabilities:

  1. Decryption of the received transaction:
    The Receiving AP receives an encrypted business document from a Sending AP. The business document will be encrypted using the certificate announced via its own Signed Service Metadata, which might be an old G2 or new G3 certificate. In either case, the Receiving AP MUST be configured with the corresponding private key (as announced in the Signed Service Metadata) and MUST be able to decrypt the business document.

  2. Verification of AS4 Signature from Sending AP:
    The AS4 message received from the Sending AP will be signed using the Sending AP’s certificate, which may be either an old G2 or new G3 AP certificate. The Receiving AP MUST be able to validate and trust the signature in either case.

  3. AS4 Signal Message Signing:
    The Receiving AP will sign an AS4 Signal Message during the exchange of the transaction. The certificate used for the signature MUST be the certificate announced via its own Signed Service Metadata, which might be an old G2 or new G3 certificate. In either case the Receiving AP MUST be configured with the corresponding private key (as announced in the Signed Service Metadata) and MUST be able to sign using this certificate.