Documentation

CSR Generation for Members

How X-Road member organizations generate certificate signing requests for SIGN and AUTH keys.

Purpose

This guide explains how an X-Road member organization should generate a Certificate Signing Request (CSR) for use in the Security Server. In practice, members typically need CSRs for:

  • signing keys, used to identify the member organization and sign exchange messages
  • authentication keys, used to establish secure TLS connections between Security Servers

The standard workflow uses the Security Server management interface. For teams using a console-based helper, NRDEX also provides a downloadable Python script:

Prerequisites

Before generating a CSR:

  • the operator should have the Security Officer role
  • the relevant security token should be available
  • the token should be logged in from the KEYS AND CERTIFICATES view using the correct PIN
  • the member should know which approved Certification Authority must sign the certificate
  • the required Distinguished Name fields should be confirmed with the governing authority or CA

Generate a CSR for a SIGN key

SIGN keys are tied to the member or subsystem and are used to provide message-level trust and non-repudiation.

  1. Open the KEYS AND CERTIFICATES view in the Security Server management interface.
  2. Find the logged-in token and click ADD KEY.
  3. Enter a label such as sign, then click NEXT.
  4. In the CSR settings, choose:
    • Usage: SIGNING
    • Client: the correct X-Road member or subsystem
    • Certification Service: the approved CA
    • CSR Format: PEM or DER, based on CA requirements
  5. Enter the certificate owner information required by the CA.
  6. Click GENERATE CSR.
  7. Save the generated CSR file and submit it to the approved CA.

Generate a CSR for an AUTH key

AUTH keys are used to authenticate the Security Server itself and establish secure server-to-server transport.

  1. Confirm that the key will be generated on a software security token.
  2. In KEYS AND CERTIFICATES, click ADD KEY under the software token.
  3. Enter a label such as auth, then click NEXT.
  4. In the CSR settings, choose:
    • Usage: AUTHENTICATION
    • Certification Service: the approved CA
    • CSR Format: PEM or DER
  5. In the Distinguished Name fields, set the Common Name (CN) to the server's fully qualified domain name.
  6. Click GENERATE CSR.
  7. Save the CSR file and send it to the approved CA.

ACME-based alternative

If the ecosystem and CA support ACME, manual CSR generation may not be necessary.

Instead of selecting GENERATE CSR, the operator can use ORDER CERTIFICATE. In that flow, the Security Server generates the CSR, submits it through ACME, and imports the returned certificate once the order completes successfully.

This reduces manual handling and is preferable where certificate automation is allowed by policy.

What happens next

After the CA signs the CSR:

  1. import the returned certificate into the Security Server
  2. complete any required registration or approval step in the ecosystem
  3. verify that the key and certificate appear in the expected state
  4. proceed with member onboarding or service publication

Operational notes

  • Keep CSR files and returned certificates associated with the correct member, subsystem, and environment.
  • Use separate handling for test and production certificates.
  • Confirm the exact Distinguished Name requirements before generating the request to avoid rework.
  • Prefer approved automation for renewal and rotation when supported.

Related references