Peer Systems

ENTERPRISE  This is a SignServer Enterprise feature.

A SignServer instance can be connected with an EJBCA instance using peer connections with two different use cases:

• In the first case, the SignServer instance can be set up to be the target of remote operations from an EJBCA instance. Connections are made using dual authenticated HTTPS, similar to how you use a client certificate to authenticate using the Admin Web to manage a SignServer instance. However, in this case, the configured administrator is another EJBCA instance.
• In the other case, the SignServer instance is acting as a Registration Authority (RA) and posts certificate signing requests that are picked up and processed by EJBCA. Connections are made using dual authenticated HTTPS, similar to how you use a client certificate to authenticate using the Admin Web to manage a SignServer instance.

Generally, the instance with higher security requirements (for example, an EJBCA acting as CA) initiates connections to a system with lower security requirements (for example, a SignServer instance or an EJBCA acting as VA or RA). SignServer currently only implements support for incoming peer connections.

Peer Systems for Certificate Renewal

SignServer can be configured to expose the worker's keys as Remote Key Bindings in EJBCA. This allows the EJBCA administrators to issue new certificates to workers in SignServer directly from within the EJBCA interface, without incoming network connections to the CA.

For instructions on how to set up the systems for certificate renewal using peer systems, see Certificate Renewals Using Peer Systems. Alternatively, see Renewal Worker, which instead of Peer Systems uses the EJBCA web services interface and connects to the CA.

Mapping SignServer Workers to Remote Key Bindings in EJBCA

EJBCA has a concept called Internal Key Bindings. When accessed over peer systems, Internal Key Bindings are seen as Remote Key Bindings. SignServer does not explicitly have Internal Key Bindings, but a worker having a key assigned to it could be seen from the EJBCA side as a Remote Key Binding. How this is done is described below.

Listed Key Bindings

All workers of worker type PROCESSABLE can be exposed as a remote key binding to EJBCA over peers, if they have a crypto token either internally or by referencing one using the CRYPTOTOKEN worker property.

By setting the worker property PEERS_VISIBLE=true, the worker will be considered when returning the list of key bindings to EJBCA.

Certificate Fingerprint

After a worker has been renewed over peers, the worker will have the property PEERS_ISSUED=true, indicating that the current certificate is issued by the remote peer. This makes SignServer include the certificate fingerprint when exposing the remote internal key binding. The consequence on the EJBCA side is that if it was the issuer of the certificate, the web GUI displays a link to the certificate and matches it to an end entity. However, if that certificate is not available in the EJBCA database, it will not display the remote internal key binding at all, as it is assumed that the certificate is managed by another CA. For this reason, the PEERS_ISSUED property is not set for new workers (or set to false), so that EJBCA will list it and the first certificate can be issued.

Offline Crypto Token

If the crypto token is offline or the configured key-pair is not available, the remote key-pair can be displayed as disabled in EJBCA, and Renew or issuance buttons can be unavailable. In that case, make sure to first generate and configure the key-pair at the SignServer side.

Peer Systems with SignServer as RA

The OneTimeCryptoWorker allows you to configure a CA Connector that uses the peer system in RA mode.

To set up a peer connection with the SignServer instance acting as a Registration Authority (RA), the following configuration is needed:

• On the EJBCA side, enable processing of incoming requests:
  • In the EJBCA Admin Web, click Peer Systems and enable the Process incoming requests option for the Peer Connector in EJBCA. For more information, refer to the EJBCA documentation on Adding an Outgoing Peer Connection.

• On the SignServer side, enable incoming peer requests and authorize the peer system:

  • In the SignServer AdminWeb, go to the Administrators page and select Allow incoming connections, then click Save to allow incoming connections from peer systems.

  • Wait for EJBCA to connect, or go to EJBCA and issue a Ping request.
  • Then, on the Administrators page the incoming request should be visible under Incoming Connections. Click the Add Authorization link to authorize the peer.

For information on setting up one-time keys using the OneTimeCryptoWorker, see Setting up One-time Keys.

Authentication/Authorization

The incoming peer (the CA) needs to authenticate towards the application server using a TLS client certificate.

Additionally, in order for the peer to be allowed to list key bindings and to perform operations, the certificate must be authorized to the Peer System role. For information on managing authorizations, see Administrators Page (for Admin Web), or the wspeersystems command in the Administration CLI.

Note the Admin Web allows seeing incoming (i.e. ping) requests and adding an authorization rule for it.

Global Configuration Properties

Worker Properties

The following properties can be set on the workers that should be exposed as key binding to peer system(s).