A certificate has a long life cycle, from the initial request to when it’s revoked or expired. There are different operations for validating a request, issuing and revoking the certificate, and checking its status; it’s also possible to use smart cards or to recover lost keys. Dogtag Certificate System combines these functions to centralize control for your public key infrastructure – validating requests, issuing certificates, storing keys, processing OCSP requests, and managing tokens.

Each function is performed through a separate, highly-configurable subsystem so that the PKI design is more flexible. Dogtag has six subsystems and a separate client:

• The Certificate Manager is a certificate authority (CA). It issues, renews, and publishes certificates. The Certificate Manager also creates and publishes certificate revocation lists (CRLs).

• The Registration Authority (RA) subsystem is a front-end to the CA. It performs local authentication, gathers information from the requester, and validates the certificate request. The RA forwards valid requests to the CA for signing.

• The Online Certificate Status Manager is an optional subsystem that provides online certificate service protocol (OCSP) responder services. An OCSP responder stores CRLs so that clients can use the OCSP responder to verify certificate status, which takes the load off CAs.

• The Key Recovery Authority (KRA) is an optional subsystem that archives and retrieves private encryption keys.

• The Token Key Service (TKS) manages master keys required to set up secure channels directly to the token management system. Privileged operations, such as key generation, can only be requested on the tokens through a secure channel.

• The Token Processing System (TPS) is the registration authority for tokens and establishes secure channels between the Enterprise Security Client and the backend subsystems.

• The Enterprise Security Client is an easy-to-use interface for users to enroll and format their smart cards (tokens) and receive their private keys from the token management system.

The subsystems are closely integrated with each other, depending on the deployment scenario and how they are used. OCSP and CA instances work together to publish CRLs and verify certificates. CA and KRA instances work together to archive and recover keys. Smart card tokens, processed through the Enterprise Security Client, are managed by the TPS. The TPS, however, is configured to work with at least two essential subsystem instances: a TKS to generate keys and a CA to process token operations. A TPS can also be configured to use a KRA for server-side key generation and key archival and recovery.

You get all subsystems: the CA, RA, OCSP, KRA, TKS, and TPS.

See the Features page.

This is not a commercial product, but rather a development project.

In general, we follow the guidelines of the Fedora Project. When reading the Fedora Project FAQ, substitute Dogtag Certificate System for Fedora Project and Red Hat Certificate System for Red Hat or Red Hat Enterprise Linux in most sections.

You can assist in any number of ways:

• Testing

• Participate in mailing lists

• Write documentation

• Report bugs

• Fix bugs

See Development Guide.

Both Dogtag Certificate System and Fedora Directory Server use the Network Security Services (NSS) library available from the Mozilla Project. NSS supports cross-platform development of security-enabled client and server applications. Applications built with NSS can support PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, TLS, SSL v2 and v3, X.509 v3 certificates, and other security standards. The NSS tools binary package includes all of the NSS command line tools like certutil and modutil for key, certificate, and crypto module management.

Everything is now open source - the core certificate system, the console, the setup program, everything. The Dogtag Certificate System 1.0.0 release is the first release to have completely open source components. We made good on our promise to the open source community to make available all of the desirable enterprise features.

The core Certificate System and some components are covered by the GPL; other components, including the Apache modules, are covered under different licenses. See the License page for more details.

As long as you stick with the restrictions of the license, there’s no reason you can’t redistribute this software. There are a few common modes of redistribution that we list here.

You can certainly rebrand the software to fit your needs. The licensing allows this.

Along with contributors from the community, this project is maintained by Red Hat for the Fedora project.

See our roadmap.

See Submitting Changes to PKI Source Code.