Quick answer: A CAC can support different certificate purposes, including identity authentication, digital signatures and encryption. The browser or application should request the certificate appropriate to the operation. Do not pick a certificate solely because its display name contains “email,” import a cardholder certificate as a trusted root, or assume every CAC and application exposes the same set of choices.
The DoD public key infrastructure (PKI) includes people, policies, certification authorities, directories, revocation/status services and relying applications—not just files stored on the card. Understanding those roles makes certificate prompts and errors much easier to diagnose safely.
CAC certificate functions at a glance
| Function | What it establishes | Typical use |
|---|---|---|
| Authentication | The presenter controls the private key associated with an identity certificate | Smart-card logon and certificate-based portal authentication |
| Digital signature | Integrity and attribution for signed content | Signing approved email, forms or documents |
| Encryption/key management | Confidentiality for content encrypted to the certificate holder | Approved encrypted email or data workflows |
| Certification-authority trust | An issuer/trust relationship used to build and validate a chain | Application and operating-system trust stores |
| Server or application identity | The identity of a non-person entity such as a web service | TLS and other system-to-system security |
The exact labels displayed by Windows, macOS, Linux, Firefox, middleware or a portal can differ. Use the requested operation, certificate properties and organization guidance rather than a universal screenshot.
What a public-key certificate contains
An X.509 certificate binds a public key to an asserted identity or system. It includes an issuer, subject, validity interval, serial number, public key, intended uses and extensions used for chain construction and policy. The matching private key performs protected cryptographic operations.
For a CAC, private-key operations occur on the card. The PIN authorizes an operation; it is not the private key itself. Never export, copy or ask someone to send a CAC private key. Public certificates can be distributed for legitimate trust/signature/encryption workflows, but their handling still follows policy.
Authentication and PIV Authentication certificates
Authentication proves possession of the private key associated with the presented certificate. A portal validates the chain and certificate status, then maps the identity to an account. Current DoD CAC modernization guidance established the Personal Identity Verification Authentication certificate as the standard certificate for access to DoD information-technology assets on NIPRNet.
Authentication does not itself grant permission. The application must make a separate authorization decision. A valid CAC can therefore authenticate successfully and still receive “not authorized” when the account, role, affiliation or mission need is missing.
When a browser asks for a certificate for portal login, select the authentication certificate that matches current portal and organization guidance. Do not repeatedly test signature/encryption certificates after failed PIN prompts.
Digital-signature certificates
A digital signature lets a relying party verify that signed content has not changed and attribute the signature to the identity represented by the certificate. Signing is not the same as encrypting: a signed message may still be readable by anyone who can access it.
Use signature certificates only for approved signing operations. Confirm what will be signed, let the application finish the private-key operation, and never approve an unexpected prompt. For workflow-specific steps, use the CAC email-signing guide.
Encryption and key-management certificates
Encryption uses a recipient’s public key so that the matching private key can decrypt the protected content. Because historical encrypted material may need to remain recoverable after a card replacement, encryption-key lifecycle and recovery can differ from authentication and signature use.
Do not delete old encryption certificates or attempt ad hoc recovery. Follow the component’s approved key-recovery process. A new CAC does not automatically make all material encrypted to an older key readable through the new private key.
Do not confuse a website’s TLS encryption with an email/content encryption certificate on the CAC. The website normally presents its own server certificate to establish the TLS connection.
Root, intermediate and issuing CA certificates
Cardholder certificates are issued through a certification-authority hierarchy. A relying application builds a chain from the end-entity certificate through appropriate issuing/intermediate certificates to a trusted anchor, then checks time validity, intended use, policy and revocation status.
Trust is not created by importing every certificate visible in an error. Install only approved CA material from the official DoD Cyber Exchange or an organization-managed package. Never mark a person’s CAC certificate as a trusted root. System/application owners must keep trust stores current as certification authorities rekey or new issuers are introduced.
Certificate validity, revocation and card expiration differ
- Validity interval: the certificate has not-before and not-after times.
- Revocation: the issuer can invalidate a certificate before its scheduled expiration.
- Card expiration: the printed government credential reaches its expiration date.
- Eligibility/affiliation: the person must continue to qualify for the credential or access.
These signals interact but are not interchangeable. A computer clock error can make a valid certificate appear outside its validity interval. A revoked certificate can still show a future expiration date. A server certificate can expire while the CAC remains valid.
If the error specifically reports an expired CAC certificate, use the CAC certificate-expiration diagnostic. For broader chain/status problems, use the certificate-validation guide.
How certificate validation works
- The application receives or locates an end-entity certificate.
- It builds an issuer chain using the appropriate CA certificates.
- It verifies signatures and checks policy/intended-use constraints.
- It checks the current time against validity intervals.
- It determines revocation status through an approved method such as CRL or OCSP.
- For authentication, the application maps the validated identity to an account and applies authorization.
A failure at step six cannot be repaired by installing another root certificate. Conversely, a missing issuing CA cannot be fixed by granting the user a portal role.
Why browsers show multiple choices
A browser can display multiple certificates because the card supports multiple purposes, multiple cards/tokens are connected, old certificates are cached, or the application’s acceptable-issuer/request criteria are broad. Inspect the certificate’s intended use, issuer, validity and identity using the supported certificate viewer.
Do not publish screenshots containing the subject, serial number or identifiers. Do not select certificates repeatedly if each choice triggers a PIN request. Close competing smart-card applications and use the repeated PIN prompt diagnostic when the flow loops.
User versus administrator responsibilities
Users can safely:
- verify the operation they initiated;
- inspect certificate purpose and validity without exposing sensitive fields;
- use approved browser, middleware and portal instructions;
- report the exact sanitized error and affected scope.
Administrators and application owners manage:
- trusted CA deployment and updates;
- revocation/status-checking configuration;
- accepted certificate policies and client-authentication settings;
- certificate-to-account mapping and authorization;
- server and non-person-entity certificates.
End users should not disable revocation checking, edit enterprise trust policy, install an unknown certificate bundle or change server authentication settings to work around a failure.
Frequently asked questions
Which CAC certificate should I choose for website login?
Use the authentication/PIV Authentication certificate specified by the portal and organization. Labels vary, so confirm the purpose and properties instead of relying only on a display name.
Is an email certificate always the right certificate?
No. Email signing, email encryption and portal authentication are different operations. Select the certificate appropriate to the requested operation.
Can I install my CAC certificate as a trusted root?
No. A cardholder certificate is an end-entity certificate, not a certification-authority trust anchor.
Does certificate authentication guarantee access?
No. The system must separately map the validated identity and authorize access.
Should every CAC show the same number of certificates?
Do not use a universal certificate count as the health test. Card configuration, issuance era, affiliation and application presentation can differ. Validate the certificates required for the approved workflow.
Official references
- DoD Cyber Exchange: PKI/PKE overview
- DoD Cyber Exchange: public-key enabling for administrators and applications
- DoD Cyber Exchange: PKI/PKE end-user resources
- DoD ID Card Reference Center: CAC security and card data
- DoD CIO: Modernizing the Common Access Card
Official DoD certificate guidance was checked in August 2026. Application, component and organization policy determines the supported certificate and workflow.
Stay in the loop
Get the latest cac setup.com updates delivered to your inbox.