For Administrators, Integrators and Developers

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 on Windows, 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.

DoD PKE provides the InstallRoot (32-bit, 64-bit or Non-Administrator) tool which can install CA certificates into the CAPI, NT AUTH, Firefox and Java 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).

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.

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.

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. The best method for a particular application will depend on the application’s revocation checking capabilities, network bandwidth and connectivity, and volume of traffic.

DoD PKE also offers the CRLAutoCache tools for Windows and Linux as well as Axway/Tumbleweed Desktop Validator configuration instructions and files for versions 4.10-4.12.

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+6@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.

*EDIPI+6 in the SAN UPN is a 16-digit subset of the Federal Agency Smart Credential Number (FASC-N) that for DoD users is the 10-digit EDIPI followed by a 1 to indicate the card was issued by a federal agency, the 4-digit NIST SP 800-87 Agency Code for the organization with which the user is associated, and a final digit representing the user’s Person/Organization Association (POA) Category (e.g. 2 for Civil, 4 for Uniformed Service, 5 for Contractor).