Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

The Security Server checks the validity of the signing and authentication certificates via the Online Certificate Status Protocol (OCSP, RFC 6960). An OCSP responder service providing the status information is maintained by the certificate authority that issued the certificates. Each Security Server is responsible for querying the validity information of its certificates and then sharing the information with other Security Servers as a part of the message exchange process. The mechanism is known as OCSP stapling. Only Security Servers with valid authentication certificates and members with valid signing certificates can exchange messages. If the validity information is not available or a certificate is not valid, the message exchange fails. 

To be able to mediate messages, the Security Server must have valid copies of authentication and sign certificates’ OCSP responses all the time. The Security Server downloads the OCSP responses from the OCSP responder service regularly and uses the local copies while processing messages. The Security Server remains operational as long as it has valid copies of the OCSP responses available locally, and the certificates are valid. This means that the OCSP responder service may be unavailable for a limited time without causing any downtime to the ecosystem. The period that the OCSP responder may be unavailable without affecting the ecosystem depends on various factors.

OCSP-Related Configuration

X-Road ecosystem’s resiliency to failures of an OCSP responder service is controlled through three configuration parameters that are all set on the Central Server by the X-Road operator and distributed to the Security Servers in the global configuration.

  • The ocspFetchInterval parameter defines how often the OCSP responses are refreshed.

  • The ocspFreshnessSeconds parameter specifies the validity period of the responses.

  • The verifyNextUpdate parameter defines whether the nextUpdate attribute in the OCSP response is omitted.

The most resilient configuration can be achieved by keeping the fetch interval short, the validity period long, and ignoring the nextUpdate attribute. Besides, when the nextUpdate attribute is omitted, it’s also possible to increase the validity period during a service break of the OCSP responder service, which buys more time to solve the problem without affecting the ecosystem. 

It’s important that the values of the three configuration parameters are aligned with each other and the policies of the Certificate Authority. For example, the ocspFetchInterval parameter must be smaller than the ocspFreshnessSeconds parameter, or otherwise, the Security Server considers the responses expired before new ones are fetched.

OCSP Fetch Interval

The Security Server fetches new OCSP responses using a fixed interval that is 20 minutes by default. The fetch interval is configured on the Central Server using the ocspFetchInterval configuration parameter by the X-Road operator. An OCSP response is considered expired by the Security Server if it was issued too far in the past OR there’s already new status information available.

More information about the ocspFetchInterval parameter is available in the Central Server User Guide.

OCSP Freshness Seconds

The validity period is defined on the Central Server using the ocspFreshnessSeconds configuration parameter by the X-Road operator. By default, the Security Server considers an OCSP response expired if there’s new status information available – meaning that the nextUpdate attribute in the OCSP response is in the past. However, the nextUpdate attribute can be omitted so that ocspFreshnessSeconds alone defines the validity period of an OCSP response.

More information about the ocspFreshnessSeconds parameter is available in the System Parameters User Guide.

Verify Next Update

Omitting the nextUpdate attribute is done on the Central Server using the verifyNextUpdate configuration parameter by the X-Road operator.

More information about the nextUpdate parameter is available in the Central Server User Guide.

Different Types of OCSP Responders

It’s also good to be aware that not all OCSP responder services include the nextUpdate attribute in their OCSP responses. Usually, OCSP responder services that are based on a certification revocation list (CRL) include the attribute, but real-time OCSP services don’t. A CRL based OCSP service reads certificate statuses from a static CRL that’s refreshed regularly. In contrast, a real-time OCSP service checks certificate statuses in real-time. In case the nextUpdate attribute is missing from the OCSP response, the ocspFreshnessSeconds parameter alone defines the validity period for the response just like when the nextUpdate attribute is omitted using the verifyNextUpdate parameter.

Impacts on Logged Messages

When considering the values for the three parameters, it’s essential to consider how the values affect the evidential value of the logged messages. Since the OCSP response of the signing certificate is used to check the validity of the certificate that’s used to sign messages, the age of the OCSP response may affect the validity of the signature. Therefore, it is vital to understand the consequences that enabling the use of old OCSP responses may legally have.

  • No labels