IdenTrust Inc. Logo
Home | My Account | Contact Us  

BEFORE YOU BUY CERTIFICATE CENTER AFTER YOU BUY TRUSTID ACES ECA IGC
ECA Application Enablement FAQ

Certificates > ECA > ECA Application Enablement FAQ


PKI Basics for Application Owners
1. What is PKI?
2. What is certificate-based authentication?
3. What is mutual authentication?
4. What is a Key Store?
5. What is a Trust Store?
6. What is a Trust Anchor?

Application Enablement for User Authentication
1. How do I enable my application to use PKI credentials?
2. How do I activate certificate use in my web based application?
3. I want fine control on individual user access within my application, how do I map an authentication certificate to individual users within my application?
4. How do I activate digital certificate use in my stand alone application?
5. I already have digital certificate based authentication processes in place in my application. How do I allow certificates issued by IdenTrust to be utilized in my application? How do I install a Trust Anchor to my application?

Application Enablement for E-mail Encryption (For DODI 8582.01)
1. What is DODI 8582.01?
2. What is e-mail encryption?
3. How do I configure my e-mail clients for sending and receiving Encrypted and Signed e-mails?
4. How do I enable my application to encrypt system generated e-mail?

Certificate Validation, Path Validation and Path Discovery
1. What is certificate validation?
2. What is path discovery? What is path validation?
3. What is a Certificate Revocation List (CRL)?
4. What is Online Certificate Status Protocol (OCSP)?
5. Is OCSP or CRL better?
6. Do I need to use both OCSP and CRL?
7. How do I locate the CRL for a Digital Certificate?
8. How do I locate the OCSP location for a Digital Certificate?
9. What is Server-based Certificate Validation Protocol (SCVP)?


PKI Basics for Application Owners
1. What is PKI?
A. A public-key infrastructure (PKI) is a set of hardware, software, policies, and procedures used to create, manage, distribute, and use digital certificates utilized for positive identification of a user within a transaction. A PKI is backed by a governing policy. This policy outlines rules for participation in the PKI and allowed uses of the issued digital certificates.

To learn more, please see the IdenTrust PKI Basics here: https://www.identrust.com/certificates/pki_basics.html

2. What is certificate-based authentication?
A. Most of us are familiar with password authentication, which is based on the premise that you and only you know your password. If someone presents your password to a web site, the web site authenticates this person as you.

Certificate-based authentication is based on the premise that you and only you have access to the secret information that is associated with your digital certificate and related private key. The web site never sees your secret information so your identity is secure (unlike password authentication).

Unlike passwords, certificates are too big to remember and the mathematical operations to prove that you are in possession of the associated secret information are too involved to perform manually. Therefore, certificate-based authentication must be performed by a computer. Fortunately all popular browsers handle certificates and the associated math.

The certificate and secret information are usually held on the computer's hard drive, but can also be stored on a smart card (a portable device the size of a credit card) or on a USB token (a portable device that plugs into an USB port). When a web site asks for user authentication, the browser accesses the certificate and secret information and performs the authentication on behalf of the user. The browser can be configured to automatically authenticate the user, so the user is not aware that the authentication took place.

3. What is mutual authentication?
A. Mutual Authentication is a process by which two parties involved in a transaction authenticate each other suitably. In PKI this can be completed between people by mutual exchange of signed documents. Between a server and a user, this is accomplished via Mutual SSL. In Mutual SSL, the server will present a digital certificate asserting identity and the user will present a digital certificate asserting identity.

4. What is a Key Store?
A. A keystore is a database of key material. Key material is used for a variety of purposes, including authentication and data integrity. There are various types of keystores available, including stand alone "PKCS12", Sun’s "JKS", and keystores native to the operating system.

Generally, keystore information can be grouped into two different categories: key entries and trusted certificate entries. A key entry consists of an entity's identity and its private key, and can be used for a variety of cryptographic purposes. In contrast, a trusted certificate entry only contains a public key in addition to the entity's identity. Thus, a trusted certificate entry cannot be used where a private key is required. In the J2SDK implementation of "JKS", a keystore can contain both key entries and trusted certificate entries.

5. What is a Trust Store?
A. A truststore is a keystore which is used when making decisions about identities to trust. If you receive some data from an entity that you already trust, and if you can verify that the entity is the one it claims to be, then you can assume that the data really came from that entity. An entry should only be added to a truststore if the user makes a decision to trust that entity. By either generating a keypair or by importing a certificate the user has given trust to that entry, and thus any entry in the keystore is considered a trusted entry.

It may be useful to have two different keystore files: one containing just your key entries, and the other containing your trusted certificate entries, including Certification Authority (CA) certificates. The former contains private information, while the latter does not. Using two different files instead of a single keystore file provides for a cleaner separation of the logical distinction between your own certificates (and corresponding private keys) and others' certificates. It is important to note that some commonly available keystores, such as the Microsoft Windows Keystore, combine the concepts of a keystore and a trust store into a singular keystore.

6. What is a Trust Anchor?
A. A Trust Anchor is a digital certificate, typically belonging to an issuer, which is used as a starting point for trust functions. Trust Anchors represent a point in a PKI Hierarchy where initial trust is established. Any certificates issued under the authority of the Trust Anchor will be granted an immediate level of trust. This inherit trust does not automatically indicate trust for all identities issued from the Anchor. All certificates issued under a Trust Anchor should still be checked for validity.

Back to top


Application Enablement for User Authentication
1. How do I enable my application to use PKI credentials?
A. Application enablement methods will vary based on the deployment model, application architecture and technologies used to develop the application. To enable your application to utilize PKI credentials you will need to understand the cryptographic capabilities of the various components involved in your application.
i. If the application is a thin client based on commonly available web servers such as Apache HTTP Server or Internet Information Services (IIS), enablement can be as simple as activating the appropriate services provided by the web server.
ii. If the application is a thick client, the individual application will need to be modified to collect and process digital certificate based authentication requests.
iii. Application enablement will result in the same major steps regardless of the technology used. The major steps are:
  • Present certificate selection UI to the user, triggering signature of an authentication request.
  • Securely receive signed authentication request at processing point.
  • Confirm signature integrity and validate related digital certificate.
  • Using information obtained from the digital certificate, map to a user account within the application.
  • Grant user access as appropriate.
2. How do I activate certificate use in my web based application?
A. Steps will vary between the various server products. The concept for all servers is similar. You will need to establish a Trust Store for your web server, activate SSL capabilities, and require users to present a digital certificate for authentication. Please consult your server documentation for specifics on your server.
Examples:
i. Apache HTTP Server information can be found with the Apache “SSL/TLS Strong Encryption: How-To” documentation: http://httpd.apache.org/docs/current/ssl/ssl_howto.html
ii. Microsoft Internet Information Services utilizes Certificate Mapping Authentication Modules for authentication. Modules are selected based on the current deployment used for IIS. Microsoft offers two modules “IIS Client Certificate Mapping Authentication” and “Client Certificate Mapping Authentication”. Selection of the module to be used is based on your systems current deployment. Differences between the modules are discussed in the links provided.
3. I want fine control on individual user access within my application, how do I map an authentication certificate to individual users within my application?
A. Processes will vary between the various server products. In general, the certificate information will need to be retrieved from the session object and mapped to user accounts in the application. The application will need to have digital certificates associated with individual accounts. This association can be done with the entire certificate or individual data points from within the digital certificate. The more data points used, the more secure the association will be.

IdenTrust suggests, at a minimum, the Subject Distinguished Name, Issuer Distinguished Name, and Certificate Serial Number be utilized.

For IIS based implementations, see the Mapping Modules discussed in the previous topics.

Below is a simple example of an Apache configuration and Java code used to retrieve the user information. This is not the only method available to retrieve user information, and is provided as example only.

i. Apache Configuration:
  • Configure the roots for which you want to allow client-SSL authentication: "SSLCACertificatePath "
  • To cause mod_jk to forward the client ssl certificate to Tomcat through the javax.servlet.request.X509Certificate attribute: "SSLOptions +StdEnvVars +ExportCertData"
  • To cause Apache HTTP to request a client-ssl authentication: “SSLVerifyClient optional” or "SSLVerifyClient required"
ii. Java Code Snippet:
    // Load the requester certificate
    java.security.cert.Certificate[] clientCertChain =
    (java.security.cert.Certificate[])request.getAttribute("javax.servlet.request.X509Certificate");
    java.security.cert.X509Certificate clientCert = null;
    java.security.cert.X509Certificate rootCert = null;
    if(clientCertChain != null && clientCertChain.length != 0) {
    clientCert = (java.security.cert.X509Certificate) clientCertChain[0];
    rootCert = (java.security.cert.X509Certificate) clientCertChain[clientCertChain.length - 1];
    }

    if(clientCert == null) {
    // throw new Exception("Client Cert Not Presented.");
    }

    // Get the subject DN
    String subjectDN = clientCert.getSubjectX500Principal().getName();

    // Get the issuer DN
    String issuerDN = clientCert. getIssuerX500Principal().getName();

    // Get the serial number in hex
    String sn = clientCert.getSerialNumber().toString(16);
4. How do I activate digital certificate use in my stand alone application?
A. For stand alone applications, your development team will need to add the necessary certificate gathering, validation and authentication processes. Approach will vary based on technologies used to develop the application. Many programming languages currently have cryptographic capabilities included. For those which do not have cryptographic capabilities or require enhancement, a third party utility may be necessary. IdenTrust suggests IAIK or The Legion of the Bouncy Castle utilities. Other utilities are available and may be used to support your unique requirements.

IAIK: https://jce.iaik.tugraz.at/

The Legion of the Bouncy Castle: http://www.bouncycastle.org/

Back to top

5. I already have digital certificate based authentication processes in place in my application. How do I allow certificates issued by IdenTrust to be utilized in my application? How do I install a Trust Anchor to my application?
A. Individual steps will vary based on the application. In general, you will simply need to add the CA you wish to trust as a Trust Anchor to your applications Trust Store.

  • The link to the ECA Trust Anchor installation procedure is: http://iase.disa.mil/pki/eca/installation_of_eca_certificates.html


  • Links to IdenTrust popular Trust Anchors are below.
  • IdenTrust ACES: https://identrust.com/certificates/aces_rootie5.html
  • IdenTrust TrustID: https://www.identrust.com/certificates/trustid/install-nes36.html


  • Installation of CA certificates will vary based on the technology used for the application. Examples for popular technologies are listed below. In all cases, you will need to obtain the appropriate CA(s) from the links listed above. Please consult with your product’s instructions for details on adding CAs to the Trust Store.

    Apache:
    Place the CA certificate on the Apache server, in a directory accessible to the Apache service. In the Apache configuration, use the SSLCACertificateFile or SSLCACertificatePath directive from mod_ssl to identify the location of the new CA certificate. If one of the directives is currently in use, place the CA certificate in the location currently identified. More information on mod_ssl and the directives can be found here: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

    Java:
    For a java application, you will need to identify the java keystore in use by your application. Once identified, collect the CA certificates you would like to add to the keystore, each certificate will need to be PEM encoded. Use the keytool command once for each certificate you would like to add to the keystore:
    keytool -import -file cacert.pem -alias CAAlias -keystore truststore.ts -storepass StorePass
    • CAAlias is a convenience tag which allows you to access this particular certificate once it is in the keystore, if needed
    • Truststore.ts is the keystore you are adding certificates
    • StorePass is the password protecting the keystore
    More on the java keytool can be found here: http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html


    Application Enablement for E-mail Encryption (For DODI 8582.01)
    1. What is DODI 8582.01?
    A. Effective June 6, 2012, the Department of Defense (DOD) issued Department of Defense Initiative (DODI) No. 8582.01 requiring encryption of all unclassified DOD information on non-DOD computers. THE DODI specifically calls for encrypting unclassified DOD information that is transmitted via e-mail, text messages, and other electronic methods. The DOD also recommended the use of PKI credentials to protect all DOD unclassified information. In a nutshell, DODI No. 8582.01 means DOD contractors working on their own computers need to implement accepted security protocols to be in compliance with the DODI and continue providing services and conducting business with the DOD.

    Further information can be found here: https://www.identrust.com/company/news/2012/news_120606.html

    2. What is e-mail encryption?
    A. E-mail encryption refers to the process where e-mail messages are encoded in such a way that only the target recipients are able to decode and read the message.

    3. How do I configure my e-mail clients for sending and receiving Encrypted and Signed e-mails?
    A. Configuration for e-mail encryption will vary based on the client used. Please see the manufacturer instructions for activating e-mail encryption capabilities in your client. Links to popular e-mail clients are listed below.

    4. How do I enable my application to encrypt system generated e-mail?
    A. In order to send an encrypted e-mail to a recipient, you will need their public key, in the form of a digital certificate to start the encryption process. Any e-mail encrypted with a public key may only be decrypted with the corresponding private key, which only the recipient will hold. You will need access to a repository containing the recipient digital certificates. This repository can be a public system or a self hosted repository built to suit your needs.

    Exact methods of building the encrypted e-mail will depend on the individual technologies used. The steps will be similar:
    1. Construct the e-mail message.
    2. Add encryption information and trigger encryption.
    3. Send e-mail to recipient.
    Java:
    Java based applications will need to use the JavaMail API (http://www.oracle.com/technetwork/java/javamail/) and a 3rd Party provider for encryption. Oracle maintains a list of third party products to enhance JavaMail.(http://www.oracle.com/technetwork/java/javamail/third-party-136965.html) many contain encryption capabilities.

    IdenTrust recommends IAIK or The Legion of the Bouncy Castle.

    IAIK: https://jce.iaik.tugraz.at/
    The Legion of the Bouncy Castle: http://www.bouncycastle.org/
    • See the org.bouncycastle.mail.smime.examples.CreateEncryptedMail source for an example.
    Back to top


    Certificate Validation, Path Validation and Path Discovery
    1. What is certificate validation?
    A. In order to verify a certificate, a relying party must perform three operations:
    • Ensure the certificate is issued from a trusted PKI.
    • Verify the certificate is not expired.
    • Check that the certificate has not been revoked by the issuing certificate authority (CA).
    Trust is typically a simple matter of installing the Root CA for the PKI that a relying party would like to trust. Although this is trivial when one PKI is involved, it is very quickly getting more complicated in a bridge enabled world.

    Expiration is a time check against the relying party’s system clock. There is always some variation in clock times, but most relying party applications have some wiggle in time checking. Even if they don’t, a matter of a few minutes is really only important for highly valuable or sensitive transactions.

    Of the three steps listed for certificate validation, revocation seems to be the step most organizations have trouble implementing. There are two main revocation check methods, Certificate Revocation List based checks and OCSP based checks. Applications implementing revocation checks will need to be able to process both these methods. More information on certificate validation can be found in section 6 of RFC 5280: http://tools.ietf.org/html/rfc5280

    2. What is path discovery? What is path validation?
    A. Certificate validation consists of two phases: trust path discovery and trust path validation. Trust path discovery is the process of discovering a chain of cross-certificates and CA certificates running from the relying party's trust anchor to the end-entity's certificate. A trust path may be discovered dynamically each time as needed or it may be constructed once and stored (or "cached"); Path Discovery Validation products may vary in how they choose to implement this operation.

    Trust path validation is the process of examining each certificate that comprises the trust path and consulting the issuing CA's CRL or OCSP responder to determine each certificate's validity status at that moment. It is expected that even if a trust path is cached, all certificates in the trust path are validated in real-time at the beginning of each transaction.

    More about path validation and path discovery can be found in RFC 5280: http://tools.ietf.org/html/rfc5280

    3. What is a Certificate Revocation List (CRL)?
    A. CRLs are signed binary files that contain a listing of serial numbers and other information for certificates that have been revoked by an issuing CA. Relying parties wishing to check revocation need to download the CRL and parse the file, confirming the certificate being verified is not listed on the CRL. Each issuing CA issues a CRL (including the Root), so relying parties will likely need to retrieve multiple files. These files can be cached with the relying application as needed, according to the CRL validity period (this value is in the CRL itself). Since a certificate revocation event will cause a CRL to be updated and re-published before the published expiration time, it is recommended that CRL caches are frequently checked for needed updates.

    4. What is Online Certificate Status Protocol (OCSP)?
    A. OCSP is a real time, synchronous HTTP request to learn the status of a certificate. OCSP sessions may contain information on more than one digital certificate at a time. Relying applications will need to make an OCSP call for every certificate requiring validation. Like CRLs, OCSP Responses may be cached for a limited time. However, the cache is somewhat less useful since it contains a small set of certificates. More about OCSP can be found in RFC 2560: http://tools.ietf.org/html/rfc2560

    5. Is OCSP or CRL better?
    A. From a validation stand point, both provide a status of the certificate being validated. OCSP services will typically use the CRL for the PKI as the definite source of information. This prevents inconsistent results when selecting between OCSP and CRL as the validation method. There is no difference in the validation information, only the method by which the certificate is validated.

    OCSP is meant to be a real time assertion from the issuing authority. A CRL is a black list of revoked certificates published by the issuing authority. New CRLs are typically published as the information changes and on regularly scheduled intervals.

    6. Do I need to use both OCSP and CRL?
    A. No, one method is fine so long as the attempt to validate the certificate is completed, regardless of the status of the certificate. Applications should be developed to handle both methods and designed with a preference for one of the validation methods. If the primary method of validation fails (i.e. unreachable service), then the application should move to the secondary method in a continued attempt to validate the certificate. An application validating a certificate should attempt to validate a certificate until a response is received or all validation methods have been exhausted. If a certificate can not be validated or is determined to be expired or revoked, it should not be trusted.

    7. How do I locate the CRL for a Digital Certificate?
    A. The CRL information can be found in the CRL Distribution Point (CRLDP) field of the digital certificate. Using a cryptographic certificate parsing tool appropriate for the development environment, the CRLDP can be extracted from the certificate. Once obtained, the path can be followed to obtain the CRL and perform the necessary lookups for validation.
    CRL

    8. How do I locate the OCSP location for a Digital Certificate?
    A. The OCSP information can be found in the Authority Information Access (AIA) field of the digital certificate. OCSP data in this field is marked with the OCSP Object Identifier (OID) 1.3.6.1.5.5.7.48.1. Using a cryptographic certificate parsing tool appropriate for the development environment, the AIA can be extracted from the certificate. Once obtained, an OCSP Request can be built and delivered to the appropriate location for processing.
    Authority Information Access

    9. What is Server-based Certificate Validation Protocol (SCVP)?
    A. Although SCVP is a standard, support for the protocol is still emerging. SCVP allows for out-sourced trust processing. It is especially valuable in PKI interoperability scenarios. More about SCVP can be found in RFC 5055: http://tools.ietf.org/html/rfc5055

    Back to top



    ECA INQUIRIES
    888.882.1104
    Helpdesk@IdenTrust.com
    ECAsales@IdenTrust.com
    M-F, 6am-6pm MST

    DODI Video

    ECA CERTIFICATE PRICING

    HOW TO BUY
    ECA Medium Assurance
    ECA Medium Assurance Foreign Country
    ECA Medium Token Assurance Foreign Country
    ECA Medium Token
    ECA Medium Hardware Assurance
    ECA Medium Device Assurance SSL/TLS
    ECA Foreign Countries Supported

    LIST OF GOVT AGENCIES

    AFTER YOU BUY
    ECA Application Enablement FAQ
    Request Key Recovery
    Revoke Certificate
    Root Certificate Downloads

    RELATED CONTENT
    BUY ECA
    Instructions for Applicant
    Locations for IdenTrust Identity Verification
    ECA Identity Verification
    ECA Medium Assurance Token Assurance forms instruction
    ECA Medium Hardware forms instruction
    ECA Foreign Subscribers forms instruction
    Accepted IDs for ECA
    ECA Forms and Policies
    ECA FAQs
    Security of Unclassified DoD Information on Non-DoD Information Systems
    Who can sign the Part 2 form

    OTHER
    ECA Digital Certificates
    ECA Trusted Correspondent Program
    How To Become a Trusted Correspondent
    IdenTrust, Inc. BBB Business Review WebTrust WebTrust Baseline EHNAC EHNAC GSA Schedule SOC
    © IdenTrust, Inc. All Rights Reserved.    Home | Contact Us | Legal Policies