It is recommended to use the EJBCA Web Service API for enrolling Inspection Systems (ISs). The method cvcRequest can be used to implement initial issuance and automatic renewal of IS CVC requests. For more information, refer to the EJBCA Web Service API Reference.

Note the following on the enrollment processing logic using the Web Service API:

  • A new IS with no old certificate issued must be pre-registered, be in status NEW, and use a password.
  • An IS with status REVOKED or HISTORICAL cannot be enrolled.
  • If the request is an authenticated request and the IS have an old valid (in time) certificate (in the EJBCA database) that can verify the outer signature, a new IS certificate is automatically allowed to be enrolled.
  • If the authenticated request cannot be verified because the outer signature cannot be verified at all (invalid signature or no verifying certificate in the EJBCA database), the request is rejected.
  • If the authenticated request cannot be verified because the outer signature can be verified but the verifying certificate is not valid, the user must be in status NEW and use a password.

The complete certificate chain is always returned, with the IS certificate in the first position, DV certificate in the second, and CVCA certificate last.

Revocation of an IS prohibits further issuance of certificates to that IS using the WS API.

The command line client for testing available under dist/clientToolBox CvcWsRaCli can be used for making requests and to parse, print and verify requests and certificates.

  • Note that IS end entity naming (CN, etc) must not be changed once a certificate has been issued to the IS end entity, as this will cause all future renewal to fail. Should this occur, a new IS end entity must be created.
  • Existing IS end entities should not be reused for new systems or when replacing an old IS, but a new one should always be created.

IS Certificate Profiles

To configure a Certificate Profile for Inspection Systems, use the following settings.

As of EAC 2.10, EJBCA also supports certificate hierarchies for Authentication Terminal (AT) and Signature Terminal (ST) end entities, configured using the settings below and specifying the appropriate terminal type.




Use the End Entity type.

Available Key Algorithms, ECDSA curves and bit lengths

Specify to match your EAC hierarchy (all certificates in an EAC chain must use the same type of keys and signature algorithms).


An IS certificate are typically valid for 1-30 days.

Validity offset

Set to 0m to not consider any clock skew. Assume that all components are on the correct time.

CVC terminal type

Use Inspection System.

To use AT or ST certificates, create certificate profiles with the terminal type appropriately configured for your CAs and end entities. 

CVC access rights

DG3, DG4, or both.