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 filterable by topic (web servers, domain management and smart card logon, thin clients and virtualization, etc.) are available below; a full listing of all of the documents and tools available from the site is available on the PKI/PKE Document Library page.
The high-level steps generally required to PKE include:
Install Certification Authority (CA) Certificates
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.
Obtain and Install a Certificate for the System or Application
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.
Configure Certificate Revocation Checking
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.
Configure Security Settings to Support PKI Functions (e.g., PKI-Based Client Authentication, TLS)
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.
Configure Certificate Mapping
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).
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.
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 CAs (IRCAs) or implementation of a local certificate policy object identifier (OID) filtering solution such as the DoD PKE Trust Anchor Constraints Tools (TACT) available from the PKI/PKE Tools page. A complete list of approved partner OIDs is available in the DoD Approved Assurance Levels from External Partner PKIs text file.