What Kind of Keys and Certificates the Security Server Has?
Starting from version 7.0.0 the Security Server has multiple encryption keys that can be divided into two categories:
Keys that are used to secure data in transit.
Keys that are used to secure data at rest.
In X-Road version 6, only keys that are used to secure data in transit exist. Keys that are used to secure data at rest are available starting from version 7.0.0.
Keys that are used to secure data in transit
The Security Server has five different types of keys (and certificates) to secure data in transit:
Authentication key and certificate – authentication of Security Servers.
Sign key and certificate – signing of messages.
Internal TLS key and certificate – client and server certificate that is used for authenticating Security Server when connecting to an information system.
TLS key and certificate for the UI and management REST API - Security Server’s admin UI’s and management REST API's certificate.
API keys - API keys for Security Server's management REST API.
# | Use | Port | Description |
|---|---|---|---|
1 | Authentication key and certificate | 5500 | Authentication key and certificate certify authenticity of a Security Server. They are used for authentication in connections between Security Servers. Authentication keys are always stored in the soft token. |
2 | Sign key and certificate | - | Signature key and certificate certify authenticity of an X-Road member. They are used for signing and verifying the integrity of mediated messages. Sign keys can be stored in the soft token or in a security token / hardware security module (HSM). |
3 | Internal TLS certificate | 443 (Ubuntu) 8443 (RHEL) | Security Server’s internal TLS certificate is used in connections between the Security Server and an information system. The internal TLS certificate is used as both client and server certificate depending on the roles of the Security Server and information system. |
4 | UI/API TLS certificate | 4000 | The UI/API TLS certificate is used when connecting to the Security Server admin UI or management REST API running in port 4000 (by default). The TLS key and self-signed certificate are auto-generated during the Security Server installation process. |
5 | API Keys | 4000 | API keys are used to authenticate API calls to Security Server’s management REST API. API keys are associated with roles that define the permissions granted to the API key. |
Additional Information
Configuring the authentication key and certificate (1) for the Security Server:
Configuring the signing key and certificate (2) for the Security Server:
Changing the internal TLS key and certificate (3):
API key (5) management operations:
Security tokes, keys and certificates:
Keys that are used to secure data at rest
The Security Server has four different types of keys to secure data at rest:
Internal GPG key - sign/verify and encrypt/decrypt backup files, sign and encrypt message log archive files.
Backup/restore GPG key(s) - additional public keys to encrypt backup files.
Database encryption key - encrypt message body in the message log database.
Message log archive encryption key(s) - encrypt message log archive files.
# | Key | Description |
|---|---|---|
1. | Internal GPG key |
|
2. | Backup/restore GPG key(s) | Additional public keys that are used to encrypt backup files when backup encryption is enabled. |
3. | Database encryption key | The encryption key that is used to encrypt message body in the message log database when database encryption is enabled. |
4. | Message log archive encryption key(s) | Additional per-member public keys that are used to encrypt message log archive files when message log archive encryption and grouping are enabled. The keys are member-specific and they are used to encrypt archives owned by a specific member. |
Additional Information
Configuring backup encryption (2) for the Security Server:
Configuring message log encryption (3) for the Security Server:
Configuring message log archive encryption (4) for the Security Server: