PKI Developers

From Dogtag
Revision as of 22:10, 29 November 2011 by Nkinder (talk | contribs) (Standards and Guidelines)

Jump to: navigation, search


Developers should check out the building guide to see how to build the Dogtag Certificate System from source. Then, you can choose to work on fixing bugs, adding new features, or improving the documentation. For other ideas, see our list on ways to contribute.

Alternatively, developers can jump directly to instructions on installing any of the various subsystems.

If a developer wants to contribute code to the project, look at the contributions page. It contains information on the process required to be able to submit patches that will be accepted. From a more technical standpoint, check out the appropriate coding style guide before submitting a patch.

Also, take some time to review the license. To understand the inner workings of the servers, the developers can read the architecture section.

Source Code

Yum Repository:

Subversion Repository:


Standards and Guidelines

Coding standards and guidelines are available for each language comprising the Dogtag Certificate System.

Our Patch Review Process - how to have a patch reviewed before pushing it to our source repository.

Additionally, the Dogtag Certificate System follows the Filesystem Hierarchy Standard (FHS) packaging standard.


To learn how to build Dogtag Certificate System as a developer, see Building the Dogtag Certificate System.

The Dogtag Certificate System currently does not have nightly builds and tinderbox builds.

A tinderbox is basically a continuous build cycle: pull SVN, build, report, repeat.

This is very useful when a lot of check-ins are happening at once, since feedback will be provided fairly quickly when something breaks.


To learn how to install and configure a PKI instance, see the PKI Installation Guide.

Certificate System Plug-ins

It is possible to write plug-ins that extend the functionality of various aspects of the Certificate System. The various plug-in tutorials listed below contain information about a specific API and the scope of its functionality.


Not a programmer? No problem. Contributors can help by finding new bugs, verifying existing bugs, polishing documentation, and generally improving the quality of the various subsystems.

A good way to contribute to improving the quality of a subsystem would be to add automated tests for each of the features. Developers and contributors to the Dogtag Certificate System Project are encouraged to write unit tests for any new features, updates, and bug fixes being contributed. Where possible, the tests should be data driven. This allows for greater numbers of test cases, covering more of the features under testing, to be written with minimal effort. We suggest that tests be written in a scripting language such as bash, Perl ( Perl::Test ), or Python for ease of maintenance.