Certificate creation

What the certificate is for

ServiceDigitalIdentity is the component of a TS 119 602 List of Trusted Entities that says which key material a relying party may trust for this service. For a Wallet Solution Issuance or Revocation service, and for a PID Issuance or Revocation service, it carries the X.509 certificate of that service. Relying parties read the published list, take that certificate, and use it to recognise the service. That is why the list needs the certificate: without it an entry names a provider but gives nothing to verify against.

This publisher populates ServiceDigitalIdentity with X509Certificates only, and it never builds or verifies a certification path. A self-signed certificate is therefore accepted and is the simplest option for testing. A CA-issued certificate is equally accepted; in production the certificate is normally issued by the CA your scheme requires.

The certificate subject must identify the provider. Set the organisation (O) to exactly the Trusted Entity Name you enter during onboarding — the Entity Name field — or the submission is rejected.

Which object do you have?

These names are often used as if they were interchangeable. They are not.

Complete self-signed test workflow

ORGANISATION_NAME="Example Wallet Provider"
SERVICE_NAME="Example Wallet Service"
COUNTRY_CODE="DK"

# 1. Generate the private key. Keep this secret and never upload it.
openssl genpkey \
  -algorithm EC \
  -pkeyopt ec_paramgen_curve:P-256 \
  -out service-private-key.pem

# 2. Export the public key for inspection or use by the service.
# This file is not uploaded to Credimi.
openssl pkey \
  -in service-private-key.pem \
  -pubout \
  -out service-public-key.pem

# 3. Create a self-signed X.509 certificate for testing.
openssl req \
  -new \
  -x509 \
  -key service-private-key.pem \
  -sha256 \
  -days 365 \
  -out service-certificate.pem \
  -subj "/C=${COUNTRY_CODE}/O=${ORGANISATION_NAME}/CN=${SERVICE_NAME}" \
  -addext "basicConstraints=critical,CA:FALSE" \
  -addext "keyUsage=critical,digitalSignature" \
  -addext "subjectKeyIdentifier=hash"

# 4. Inspect the certificate.
openssl x509 \
  -in service-certificate.pem \
  -noout \
  -subject \
  -issuer \
  -dates \
  -fingerprint \
  -sha256

Upload service-certificate.pem. Do not upload service-private-key.pem or service-public-key.pem.

Confirm that the certificate matches the private key

These two commands must produce the same SHA-256 value. If they differ, the certificate does not belong to that key and the service will not be able to use it.

openssl pkey \
  -in service-private-key.pem \
  -pubout \
  -outform DER |
openssl sha256

openssl x509 \
  -in service-certificate.pem \
  -pubkey \
  -noout |
openssl pkey \
  -pubin \
  -outform DER |
openssl sha256

CA-issued certificate workflow

Reuse the private key from step 1 and create a certificate-signing request instead of a self-signed certificate:

openssl req \
  -new \
  -key service-private-key.pem \
  -out service-certificate.csr \
  -subj "/C=${COUNTRY_CODE}/O=${ORGANISATION_NAME}/CN=${SERVICE_NAME}"

Send service-certificate.csr to the CA your scheme selects. The CA returns the service certificate; upload that, converting it to PEM first if it arrives in another encoding. The private key never leaves your side during this exchange.

DER to PEM

openssl x509 \
  -inform DER \
  -in service-certificate.der \
  -out service-certificate.pem

PKCS#12 / PFX certificate extraction

openssl pkcs12 \
  -in service-identity.p12 \
  -clcerts \
  -nokeys \
  -out extracted-certificate.pem

openssl x509 \
  -in extracted-certificate.pem \
  -out service-certificate.pem

What the form rejects

A parseable self-signed or CA-issued X.509 PEM certificate is accepted. Anything else is reported against the certificate field:

A file that contains the private key and the certificate is rejected as a private key. Split it and upload the certificate alone.