-
Notifications
You must be signed in to change notification settings - Fork 138
FAQ
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.
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 should be able to do this as long as your changes are also made under the GPL.
This is also possible because the Certificate System is GPL. The two Apache modules are licensed under the Apache Public License version 2.0 and can be bundled with the rest of the certificate system package for distribution. Even though the APL is considered generally incompatible with the GPL, it is ok in this specific case.
If you make changes to the Certificate System before you distribute it with your application, then you must make sure that you make those changes available under the GPL, as is required under the license.
The Certificate System has a pretty powerful plugin API that can allow you to extend the server in interesting ways. It was our intention that people would be allowed to build plugins under any licensing they chose and to distribute linked copies of the two, as long as they stayed within the limits of the licensing.
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.
|
Tip
|
To find a page in the Wiki, enter the keywords in search field, press Enter, then click Wikis. |