EJBCA - Open Source PKI Certificate Authority


EJBCA is an open source project and appreciates community contributions:

  • Contribute code - we love patches! If you have a new feature or bug-fix, this is the absolute fastest way get it implemented.
    A well written feature or bug-fix with proper JUnit tests have a very high probability of living on, thus removing the maintenance burden of patching EJBCA every time you upgrade.
  • Contribute documentation. Documentation can always be improved.
  • Contribute translations. Translations can always be improved.
  • Report bugs, suggest new features and improvements. You can do it all through the Issue Tracker.
  • Join the EJBCA Team!
  • Due to Common Criteria certification we can not be very generous with SVN commit access. We may get SVN access if you prove yourself, have long-term intentions and sign of on our Development Policy.
See contact & support for ways to contact the EJBCA Team.

Contributor Policy

We want to make EJBCA community friendly, yet secure and respectable. We therefore have a simple contributor policy. If you submit patches to EJBCA you should comply with this simple policy.

Copyright and license:

  • As the author of the contribution, you retain your copyright as is;
  • You license the code under the OSI approved open source license used by EJBCA, i.e. LGPL v2.1 or later;

With respect to your contribution, you represent that:

  • it is an original work and that you can legally grant the rights to the open source license;
  • it does not to the best of your knowledge violate any third party's copyrights, trademarks, patents, or other intellectual property rights;

How to Contribute

If you are not a committer in SVN we are glad to accept patches. You can send us patches either in diff format (svn diff) or created with an IDE. You can also send us complete files that you have changed, we can see the diffs in our IDE.

The normal process for contribution patches is:

  • Contributor send patches, under the LGPLv2.1+ license, to the ejbca-develop mailing list, or directly to PrimeKey.
  • Include a JUnit test case for your change, it may be a simple addition to an existing test. If you do not know how to do this, ask us and we will help you.
  • Someone on the EJBCA core team will review them, when there is time, and if needed suggest improvements.
  • If it is a useful and generic feature it will be integrated in EJBCA to be available in a later release.

Please follow these simple guidelines when submitting patches:

Keep the patch limited, only change the parts related to your patch. Do not change other lines, such as whitespace, adding line breaks to java doc etc. It will make it very very hard for us to review the patch.

Contributors are asked if they want to have their name and optional contact information listed on the contributors page.

Getting Started with EJBCA development

Development Tools

  • An operating system that can run Java (Linux, OSX, Windows..). Most developers use Ubuntu/Debian.
  • Eclipse JEE edition with an additional Subversion (SVN) plugin installed.
  • OpenJDK 8, or OracleJDK 8, or later
  • Apache Ant 1.9.x (with all the extras that comes with the zip from apache.org or 'ant-optional' Ubuntu package)
  • A supported application server (WildFly 9, JBoss EAP, JBoss AS 7.1.1.GA, etc)
  • A favorite database supported by EJBCA that is easy to work with (H2, MariaDB, MySQL, PostgreSQL.).
  • A virtualization solution for testing additional combinations of application servers and databases and external OCSP responders etc.

Changes that affect the database requires more databases to test with, changes that affect the EJBs or setup requires additional application servers etc.. What you need to know to develop EJBCA

  • The tools described in the previous section
  • Public Key Infrastructure and related technologies
    • JEE
      • Enterprise JavaBeans (excluding message passing)
      • Java Persistence API (JPA)
      • Java ServerPages and Java ServerFaces (JSP and JSF)
      • Web Services
    • Databases

Using SVN

How to connect to the EJBCA svn repository is explained over at repository. If you are using Eclipse we recommend the Subversive plug-in, now part of eclipse plug-in repositories.

Commit Privileges Policy

The purpose of the commit privileges policy is to maintain assurance that unauthorized modifications are not being done.

The policy for determining who have commit rights to the repositories are:

  • Only trusted staff or partners who are active in development have commit right to the repository.
  • All persons have previously undergone code review of their work, to ensure they produce good code.
  • After 6 months without repository activity, commit privileges will be withdrawn. To be added again if needed.
  • All commits are monitored in irc-channel, fisheye, release diffs and using a QA review process.

Committer Security Policy

EJBCA is a security project, Common Criteria certified. As such a few security policies are needed. In order for any contributor to get source code repository commit access the contributor must agree on some security policies. Contributors with no commit access are not bothered by this policy.

Password Usage

Passwords used need to comply with the following requirements:

  • Have 8 or more characters.
  • Include letters, numbers and special characters.

Workstation Protection

The user is responsible for protecting the development workstation according to best practices and best effort. This includes, but is not limited to, firewalls, virus and malware protection.

User Responsibilities

This policy applies to all users who are given physical and/or logical access to servers.

Once a server account has been assigned, the user is then responsible for ensuring the adherence to all policies and guidelines. Account information must not be shared, distributed or exchanged with anyone other than the person to whom the information was assigned. This includes, but is not limited to, usernames, user IDs, passwords, IP addresses, network diagrams or any other information which may jeopardize the security of the servers. The user is responsible for informing the management within 24 hours if:

  • His account information has been compromised.
  • His computer has been infected by a virus, or other malware.