Introduction to OpenXPKI
October 19th, 2010 By shazkhan

OpenXPKI aims to be an enterprise-scale Public Key Infrastructure (PKI) solution, which supports well established infrastructure components like RDBMS and Hardware Security Modules (HSMs). It is the successor of OpenCA, and builds on the experience gained while developing it as well as on our experience in large public key infrastructures.

  • CA rollover: Usually trust center software does not account for the installment of a new CA certificate, thus if the CA certificate becomes invalid, a complete re-deployment has to be undertaken. OpenXPKI solves this problem by automatically deciding which CA certificate to use at a certain point in time.
  • Support for multiple so-called PKI realms: Different CA instances can be run in a single installation without any interaction between them, so one machine can be used for different CAs.
  • Private key support both in hardware and software: OpenXPKI has support for professional Hardware Security Modules. If such modules are not available, access to a key can be protected by using a threshold secret sharing algorithm.
  • Professional database support: The user can choose from a range of database backends, including commercial ones such as Oracle or DB2, which are typically used in enterprise scenarios.
  • Many different interfaces to the server: Currently, one can access the CA server using a web-interface (which also allows for client-side request generation using SPKAC). Embedded devices such as routers can also use the Simple Certificate Enrollment Protocol (SCEP) to talk to the server and apply for certificates – including automatic renewal.
  • Workflow Engine: OpenXPKI aims to be extremly customizable by allowing the definition of workflows for any process you can think of in the PKI area. Typical workflows such as editing and approving certificate signing requests, certificate and CRL issuance are already implemented. Implementing your own idea is normally pretty easy by defining a workflow in XML and (maybe) implementing a few lines in Perl. The workflow engine also comes with configuration versioning support – if you change the configuration while a workflow is still running, the workflow will still use the configuration it started with, while new workflows will be created using the new configuration. This allows for on-the-fly configuration changes that do not wreak havoc with the currently running system.
  • I18N: Localization of the application and interfaces is easily possible and OpenXPKI can of course deal with the whole range of Unicode characters in certificates.
  • Self-Service application for smart card/token personalization: A web application which allows a user to easily create and install certificates to a smartcard is available.
  • Template-based certificate details: Contrary to the typical CA system, your users do not need to know about how you would like the subject to look like – you can just ask them for the information they know (for example a hostname and port) and OpenXPKI will create the corresponding subject and subjectAlternativeNames for you. Regular expression support allows you to enforce certificate naming conventions easily.
  • Better support using Request Tracker: A heavy load of certificate requests that need additional communication with the requesters can be easily dealt with using the notification interface. Currently only Request Tracker, an open source ticketing system is supported, but the interface is implemented in a general way so that adding other ticket systems is pretty easy. Users can thus automatically receive e-mails once a certificate is issued for example.

Note: Adapted from OpenXPKI user manual.

Leave a Reply


(Required)

(Required)