Skip Ribbon Commands Skip to main content

Getting Started for Administrators

Public Key Enabling (PKE) is the process of configuring systems and applications to use certificates issued by the DoD PKI, the NSS PKI, or DoD-approved external PKIs for authentication, digital signature, and encryption. Configuration guides for products by type (web servers, domain controllers, network appliances, thin clients, etc.) are available on the For Administrators, Integrators & Developers page; a full listing of all of the documents and tools available from the site is available on the PKE A-Z page.

The high-level steps generally required to PKE include:

  • DoD PKI and other approved CA certificates for PKIs that serve the system or application's user community must be installed in the certificate trust store used by the system or application. Many Windows-based applications, including Microsoft applications as well as Google Chrome, leverage the Microsoft Cryptographic Application Programming Interface (CAPI) local computer trust store. Other applications such as Mozilla Firefox and Java have their own separate trust stores. The Trust Store Management *PKI brief discusses common PKI certificate trust stores a system can leverage and how to manage them.

    DoD PKE provides the InstallRoot (32-bit, 64-bit or Non Administrator) tool which installs CA certificates into the CAPI and Firefox trust stores on Windows platforms.  CA certificates and other information for approved external PKIs are available from the Interoperability page. For alternate operating systems such as Mac OS and Linux, certificates can be imported from the PKCS7 files (For DoD PKI Only, For ECA PKI Only, For JITC PKI Only, For SIPR PKI Only *Download available on SIPRNet Only). More information on Java's PKI capabilities is available in the Java and Public Key Enabling *PKI brief.

    NOTE: The DoD PKI releases new CAs on an approximately annual basis and system owners must ensure trust stores are updated to avoid denial-of-service issues for users issued CACs with certificates from the new CAs. For notifications of updates to InstallRoot and other DoD PKE tools, subscribe to the Tools RSS feed. For notifications of changes to approved external PKIs, subscribe to the Interoperability RSS feed.

  • Most applications, including web-based systems, require a certificate identifying the system in order to fully PK-enable. A certificate request is generated by the application and submitted to a DoD PKI CA for approval and issuance. A DoD Registration Authority (RA) must be contacted to approve the request. Once the certificate is issued, it can be downloaded and installed by the application owner. The Obtaining a PKI Certificate for a DoD Server *PKI guide provides step-by-step instructions for obtaining a PKI certificate for an unclassified or secret DoD server, including submitting a certificate signing request, requesting approval from your organization's RA, and retrieving the issued certificate. The diagram below shows the process for obtaining a DoD server certificate.

    Diagram demonstrating the process for obtaining a DoD server certificate.
  • Applications must verify certificates have not been revoked prior to relying on them for security functions such as authentication. The DoD PKI supports two primary revocation checking methods:

    • Certificate Revocation Lists (CRLs) are signed files containing the list of serial numbers of the revoked certificates from each CA. To use CRLs for revocation checking, the system or application must download the appropriate CRL and check the list to verify that the serial number of the certificate being validated is not on it. Many applications provide the capability to download CRLs at the time of certificate validation; however, the size of the DoD PKI CRLs prevents this from being a practical option due to the time necessary to download the files. To use DoD PKI CRLs for revocation checking, they must be downloaded and cached on a periodic basis.
    • The Online Certificate Status Protocol (OCSP) uses a request-response paradigm in which an OCSP client submits an HTTP certificate status request to an OCSP responder and the responder, in turn, returns an OCSP response indicating whether the certificate status is good, revoked or unknown. OCSP responses are generated from data contained within CRLs; however, since an OCSP response contains status for only one or a small number of certificates, it is a much lighter-weight way to obtain certificate status than downloading a full CRL. More information about OCSP is available in the OCSP *PKI slick sheet.

    In addition to the primary methods, DoD PKI offers a variety of Axway Tumbleweed and CoreStreet proprietary revocation checking mechanisms that an organization can leverage that are detailed in the Robust Certificate Validation Services *PKI slick sheet. The best method for a particular application will depend on the application's revocation checking capabilities, network bandwidth and connectivity, and volume of traffic. More details can be found in the Certificate Revocation Checking *PKI slick sheet, the Robust Certificate Validation Services *PKI slick sheet, and the Tactical Revocation Checking *PKI white paper.

    DoD PKE also offers the CRLAutoCache tools for Windows and Linux *PKI as well as Tumbleweed Desktop Validator configuration instructions and files for versions 4.9-4.11. These items are available for download from the Tools page.

  • Systems and applications typically have specific configuration properties to control security settings related to PKI functionality. For example, web servers and other applications that support SSL/TLS have configuration properties to enable the application to listen on a port to accept inbound TLS connections. There will usually be another property that controls PKI certificate-based client authentication to the system, with options to require, allow, or disable that functionality. Other settings may control which protocols and algorithms are used by the system, and have an option to restrict these to only FIPS-approved algorithms; this is generally a STIG requirement as well. Security settings should be configured to support all desired PKI functions and comply with DoD authentication policy and STIG settings.

  • PKI provides strong assurance that the identity asserted within a PKI certificate is in fact the identity of the certificate holder. However, in order for that identity to be meaningful to a system or application, the identity from the certificate must be mapped to a user account on the system. If a PKI certificate is not mapped to a known system account, there is only strong assurance that the user has a valid certificate; there is no assurance that the application has any knowledge of the specific identity of the certificate holder upon which to base authorization decisions.

    Certificate mapping is accomplished by associating data from a validated certificate with a particular user account. PKI certificates have several attributes that can be used, either alone or in combination, as unique identifiers for certificate mapping. For DoD PKI certificate holders, the most common values used for certificate mapping are the Subject Alternative Name (SAN) User Principal Name (UPN) and the certificate subject Common Name (CN). These are the most commonly supported mapping values out-of-the-box for Commercial Off-the-Shelf (COTS) products, are guaranteed unique within DoD due to their contents' format (EDIPI@mil for the SAN UPN and lastname.firstname.middleinitial.EDIPI for the subject CN), and are persistent across multiple credentials.

    However, when expanding the user population to multiple PKIs, CN is no longer guaranteed unique and SAN UPN is not guaranteed to be present in partner PKI credentials, so alternative or secondary mapping methods must be identified. For more information, see the Choosing the Right Data for Certificate Mapping article in the DoD PKE Winter/Spring 2013 Post *PKI.


Additional Considerations

  • PKI provides applications with a more secure way to authenticate the identity of a user, application, or device. However, just because a user authenticates with a certificate, it does not mean they are authorized to access the requested data. Applications should implement an authorization process to ensure only authorized users are allowed access to information. For more information on authentication and authorization, see the Authentication vs. Authorization for DoD Web Servers *PKI brief.

  • DoD has implemented an external interoperability strategy for secure information sharing with external partners that reduces cost and overhead for both DoD and its partners. All federal agencies issue Personal Identity Verification (PIV) cards to their employees and affiliates; in addition, some of DoD's industry partners have implemented corporate PKIs, and others have obtained certificates from approved commercial PKIs. Some of DoD's international allied and coalition partners also have established PKIs to issue certificates to their personnel. Systems and applications with user populations that hold approved external credentials should be configured to accept those credentials rather than requiring the users to obtain Common Access Cards (CACs) or External Certification Authority (ECA) certificates. The complete list of DoD approved external PKIs as well as interoperability tools and configuration guides are available on the Interoperability page.

    DoD policy requires that external credentials have an assurance level of medium hardware or higher, so systems accepting external credentials must have an assurance level enforcement capability. Depending on technology, this can be accomplished through use of the Interoperability Root CA (IRCA) or implementation of a local certificate policy object identifier (OID) filtering solution such as the DoD PKE Trust Anchor Constraints Tools (TACT) available in the Interoperability Tools table. A complete list of approved partner OIDs is available in the DoD Approved Assurance Levels from External Partner PKIs *PKI text file.

PKI-PKE