EJBCA support, development and maintenance by

Internal architecture

The following diagram is a very rough schema of the current architecture of EJBCA.

A more developer centric deployment diagram is given below. It displays the internal three layer architecture of EJBCA. The application is packages in an ear file. In this ear file various web applications (war files) handles the interfaces with the surrounding world, mostly through various web interfaces. The web applications uses ejb session beans to perform the business operations. The session beans in turn uses a persistence layer (data entities) to persist data in the database.

You can add your own components by for example deploying another web application (external.war) in the application server, making use of the session bean API of EJBCA.

Sample setup architecture

The following diagram shows a good example setup of a secured CA with external OCSP responders and an external RA server that receives certificate requests. The request are periodically pulled by the CA and responses returned to the external RA. No network traffic flows from the right the left across FW2.

External RA

In some cases, for security reasons, is it preferable to deny all inbound traffic to the CA and instead let the CA periodically fetch and process information from external trusted data sources. For an overview of the solution see the illustration.
The ExtRA API contains the most basic functions like:

• Generate Certificate from PKCS10
• Generate PKCS12 for the end user
• KeyRecovery of the users key (if requested using PKCS12)
• Edit users
• Revoke Certificates

The external API, named extra, is downloaded separately, or checked out separately from the SVN using the module name 'extra'.

Documentation about the ExtRA API is in the doc subdirectory of the extra subproject.