The configuration and deployment of digital signature components is complex and usually the responsibility of an Public Key Infrastructure (PKI) administrator. If you are only using self-signed certificates for simple signing workflows, you can disregard much of the information here, including that about registry settings.
To leverage Acrobat’s rich digital signature capabilities, follow these best practices:
Familiarize yourself with this guide, the Preference Reference, and the Customization Wizard.
Learn about setting registry and plist preferences, including feature locking, paths, the relationship between the UI and the registry, and other topics.
When using the Preference Reference, pay attention to the supported versions, OS, and other details.
Install the application and configure it via the UI. Set the preferences in the Security and Signatures categories.
Use the Wizard to copy the registry settings and files from your installed application to the new installer. This is the easiest way to create new settings as well as leverage existing installs.
Use the Wizard’s UI to set additional preferences. Refer to the Files and Folders section for an example of deploying signature-related acrodata files.
Deploy the application as described in the Administration Guide.
Understand how workflow behavior is determined by registry configuration, certificate extensions, and seed values.
In general, the smaller the scope of the variable, the more controlling it is. For example, an application has a default timestamp server configured, a certificate contains an OID that specifies a different timestamp server, and a seed value specifies a third timestamp server for a particular signature field; in this case, the seed value timestamp server is used.
The product ships with default settings, and all of these steps are optional. Review this list to craft the installation you need. Additional settings and details appear in the Preference Reference
Establish PKI Trust via CDS, AATL, or local trust lists.
Set up Directory Server Connections.
Set up the Signing Environment requirements, workflow, and method. You may also want to create enterprise signature appearances as described in Custom Signature Appearances.
Configure the Timestamp Servers list, defaults, and usage.
Configure Signature Validation logging, revocation checking, service providers, and so on.
Tune Certificate Revocation Checks for OCSP, CRL, and the interaction of each.
Review the Preference Reference for additional other signature-related preferences you may need.
If required, enable FIPs compliance.
Review the application security preferences to secure your application, data, and network. Configuration involves two main tasks:
- Enabling protections that restrict potentially malicious content and actions.
- Trusting specific files, folders, and hosts in your workflow. For example, certified documents can be trusted for exemption from the restrictions above.
Test.
Deploy.
Versions 9 and later of Acrobat and Reader can provide encryption via the Federal Information Processing Standard (FIPS) 140-2 mode (Windows only). FIPS 140 is a cryptographic security standard used by the federal government and others requiring higher degrees of security. Through registry configuration it is possible to force Acrobat to use only FIPS 140-certified cryptographic libraries. Doing so only affects the production and not the consumption of PDF files, and it only affects encryption and digital signature workflows.
When the FIPS mode is on, encryption uses FIPS-approved algorithms provided by the RSA BSAFE as follows:
FIPS mode changes Acrobat’s default behavior as follows:
Every PKI leverages a method for trusting the public key certificates of the participants of signature workflows. Signers embed a copy of their certificate in their signature, and document recipients validate that signature by determining if the certificate is both valid and trusted. Establishing trust involves issuing signing certificates that chain up a certificate with a high level of integrity. In this way, trust propagates down from the certificate issuer to all users. An enterprise can set up trust through a single entity rather than for each of its hundreds or even thousands of users. Adobe Reader and Acrobat provide two ways to effortlessly establish trust without an additional software download or configuration: CDS and AATL.
Certified Document Services (CDS) is a signing solution that allows authors to create Adobe PDF files that automatically certify to the recipient that the author’s identity has been verified by an Adobe CDS provider and that the document has not been altered. CDS signatures ensure the highest level of document integrity because the user’s digital credentials must be stored on a cryptographic hardware device, and they must be issued by a WebTrust certified authority using strict verification guidelines.
The Adobe Approved Trust List (AATL) program allows signers to create digital signatures that are automatically on document open. Both Acrobat and Reader are designed to download a list of “trusted” root digital certificates every 90 days. Any digital signature created with a credential that chains to the high-assurance, trustworthy certificates in the AATL is trusted.
The following preferences allow you to configure how and when the AATL is updated.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
Other methods for setting up trusted workflows include:
If your company uses PKCS#11 devices such as smart card readers or tokens, distribute the drivers or modules at deployment time. Most configuration must occur manually.
© 2017 Adobe Systems, Inc. All rights reserved.cAdobe_P11CredentialProvider as described in .dkck201.dll with instructions where to locate it.Note
For Reader X (10.0), not all PKCS#11 devices may work with Protected Mode (PM) enabled. However, in most cases, they do. Installation of such devices usually involves disabling Protected Mode, installing the driver, restarting the application, and then re-enabling Protected Mode. Refer to the knowledge base article for details about PM compatibility with certain features.
Directory servers can be integrated with the product’s Trusted Identity feature so that users can access certificates company-wide in signature and certificate security workflows (see tAddressBook above). Server information is stored in a directories.acrodata file in a user directory; for example: C:\Users\(username)\AppData\Roaming\Adobe\Acrobat\11.0\Security\directories.acrodata.
%FDF-1.2
1 0 obj
<</DirectoryData<</Entries<</1<</authenticationType
0.0/dirStdEntryDirType/LDAP/dirStdEntryID/Example.PKMS.ADSI.dir0
/dirStdEntryName(VeriSign Internet DirectoryService)/dirStdEntryPrefDirHandlerID
/Example.PKMS.ADSI/dirStdEntryVersion 65536/maxNumEntries 100.0/port
1234.0/server(directory.verisign.com)/timeout 60.0>>
endobj
Many organizations use Lightweight Directory Access Protocol (LDAP) directory servers to enable LDAP-aware clients to retrieve email addresses, network services, software directories, and so on. Acrobat products can use LDAP servers as x.509 public key certificate repositories. End users leverage these certificates when they encrypt a document with the document recipient’s certificate (certificate security) and when validating a signature. While the product ships with the VeriSign Internet Directory Service as the default server (viewable in the Security Settings console), admins typically set an internal server as the default.
Search the Preference Reference for LDAP for a complete list of registry-level options.
For Acrobat to search for certificates on an LDAP server, the server must be able to respond to a specific LDAP scheme. In addition to returning standard, generic information, the server must be able to respond to the request userCertificate;binary as defined by RFC 4523, Section 2.1.
Note
While Acrobat is case insensitive, LDAP servers may not be. The LDAP server should be capable of handling the specific request that Acrobat sends. Verify your server uses the exact format of userCertificate;binary.
Administrators can configure directory servers in several ways:
directories.acrodata file to the tuned installer.acrobatsecuritysettings or FDF file and distribute it across the organization. Users can automatically import the settings by double clicking on the file. This method is useful for configuration of an existing client installation.To configure a directory server manually:
Open the Security Settings Console. The method varies across versions. For 11.0, choose Preferences > Security > Configure Server Settings > More.
Select Directory Servers in the left-hand list.
Choose New.
Configure the LDAP server settings in the Edit Directory Server dialog:
- Directory Name: An arbitrary directory name.
- Access Type: LDAP is the only type supported.
- Server Name: The server name.
- Port: The server port.
- Search Base: A comma-separated list of name-value pairs used in the search. For example,
c=us,cn=Brown Trout,ou=Engineeringfor country, common name, organizational unit.- This server requires me to log on: Check if the server requires a username and password.
- User name: Leave blank.
- Password: Leave blank.
- Timeout: The number of seconds to keep trying to connect.
- Maximum Number of Records to Receive: The number of records to return up to 10.
Optional: Make the server the default one to search by highlighting the directory server in the right-hand panel and choosing Set Default.
Choose OK if a confirmation dialog appears. A star appears next to the default server.
Administrators can configure preferences to control the signing workflow, when and how a signature is created, the conditions for successful signature creation, and so on. For example, these preferences tell the application where to look for Windows certificates, control signature appearances, and provide control over message digest algorithms.
Replace the default signature format.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
Replace the default hash algorithm.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
Require a message digest match.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
Require the use of Preview Mode.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
These settings pertain specifically to certified signatures in certified documents. See also bTrustCertifiedDocuments.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
Without certain information added to the PDF, a signature can be validated for only a limited time. This limitation occurs because certificates related to the signature eventually expire or are revoked. Once a certificate expires, the issuing authority is no longer responsible for providing revocation status on that certificate. Without conforming revocation status, the signature cannot be validated.
Long-term signature validation (LTV) allows you to check the validity of a signature long after the document was signed. LTV requires embedding signature validation in the signed PDF. Embedding these elements can occur when the document is signed, or after signature creation.
The required elements for establishing the validity of a signature include the signing certificate chain, certificate revocation status, and possibly a timestamp. If the required elements are available and embedded during signing, the signature can be validated requiring external resources for validation. Acrobat and Reader can embed the required elements, if the elements are available. The PDF creator must enable usage rights for Reader users (File > Save As > Reader extended Document).
Note
When a timestamp server is used, the signature validation time must be set to Secure Time. CDS certificates can add verification information, such as revocation and timestamp into the document without requiring any configuration from the signer. However, the signer must be online to fetch the appropriate information.
Information and methods used to include this long term validation (LTV) information in the PDF comply with Part 4 of the ETSI 102 778 PDF Advanced Electronic Signatures (PAdES) standard. For more information, see blogs.adobe.com/security/2009/09/eliminating_the_penone_step_at.html.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
Require a revocation check for the signer’s certificate.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
Timestamping a signature tells you that a document and signature existed prior to the indicated time. All signatures are associated with the signer machine’s local time, but they may also include a timestamp time provided by a timestamp server if one is configured. Because a user can set that time forward or back, a local time is less reliable than a timestamp time. Local times are labeled as such in the Date/Time and Summary tabs of the Signature Property dialog. Timestamps are usually provided by third-party timestamp authorities. Because timestamp authorities may charge for their services, Acrobat does not automatically set a default timestamp server if multiple servers are listed.
Certificate-level timestamp configuration can also be set by specifying the server URL in an X-509 certificate extension. For details, see X.509 Extension OIDs in See OIDs and Certificates.
By default, the signature appearance displays the signing time from the signer’s computer clock. To display the timestamp server time in a signature appearance:
HKLM\SOFTWARE\Policies\Adobe\(product)\(version)\FeatureLockDown\cSecurity\cPubSec\.bUseTSAsSigningTime and set it to 1.HKCU\Software\Adobe\(product)\(version)\Security\cASPKI\cASPKI\cSign.bReqSigPropRetrieval to 1. Create the preference if it does not exist.HKCU\Software\Adobe\(product)\(version)\Security\cPubSec\iMaxClockSkew. The default is 65 minutes. iMaxClockSkew allows admins to account for a network delay, time synchronization issues, and so on without invalidation signatures.iMaxClockSkew allows admins to account for a network delay, time synchronization issues, and so on without invalidation signatures.
Signature validation preferences specify conditions for trust, the display of status icons, logging, how validation occurs, and other requirements. The process requires that the signer’s certificate or some other certificate it chains up to must be trusted for signing (a trust anchor). In Acrobat products, this means a trusted certificate appears in the application’s trusted identity list in the Trusted Identity Manager and that it’s trust level is appropriately set. While end users trust certificates on-the-fly directly from a signature in a PDF, admins typically configure machines to eliminate any manual tasks.
Many of the following preferences interact with signing preferences and should be set accordingly.
The log file must already exist. When Protected Mode is enabled, the log file path must be one that Protected Mode permits such as the sandbox’s Temp directory or the product AppData directory. Alternatively, enable bUseWhitelistConfigFile and specify a custom location.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
Revocation checking can occur both during signature creation and signature validation, and product settings may be configured to control both the user’s ability to sign and to validate signatures. A check can occur for the signing certificate as well as for the certificates associated with any revocation check responses. OCSP and CRL checking are both supported, and MSCAPI checks will use one or the other, or both.
OCSP and CRL references interact as follows: If a signature has a chain such as Certificate Authority Root (CA) | Intermediate Certificate Authority (ICA) | End Entity Certificate (EE) and OCSP revocation checking preferences are specified for the CA but CRL preferences are not, then Adobe_OCSPRevChecker and Adobe_CRLChecker behave as follows:
cASPKI:cAdobe_CRLRevChecker are used instead.Specify revocation checking providers.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
Specify signature revocation checking constraints.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |
OCSP revocation checking can occur both during signature creation and signature validation on both the signing certificate as well as for the certificates associated with any revocation check responses.
OCSP responders: Determining if they are authorized to do rev checks
RFC2560 defines three methods of determining whether the OCSP responder is authorized to perform OCSP revocation checking. Two methods are strictly defined and the third one is called “local configuration” which Acrobat defines by specifying a set of certificates. If OCSP response is signed with one of these certificates then the responder is considered authorized.
The order in which verifying OCSP responders occurs is as follows:
Note
The structure and location of the new AuthorizedResponder entry is the same as for SendNonce entry. However, while SendNonce may be specified under ASPKI or a custom certificate preference, AuthorizedResponder may be specified only under custom certificate preferences.
Specifying the Time and Method of OCSP Checks
OCSP revocation checking preferences allow you to control when and how an OCSP check occurs. The following options are available:
thisUpdate and nextUpdate times to control its validity. See RFC 2560 for details.OCSP response embedding changes with 10.1
Prior to 10.1, OCSP responses without nextUpdate were never embedded in a signature. For 10.1 and later, OCSP responses are always embedded irrespective of the presence of nextUpdate; however, whether they are used for signature validation depends on certain conditions:
maxClockSkew (the default is 5 minutes). This test is always performed.nextUpdate is present and the validation time is less than the nextUpdate time plus the value of maxClockSkew.nextUpdate is not present and the validation time is less than the thisUpdate time or the producedAt time (whichever is greater) plus the value of iMaxClockSkew.If you need a relaxed security environment (for example, when the responder is caching OCSP responses), bIgnoreNextUpdate can be set to 1 to ignore the last test. In this case, embedded responses without nextUpdate are always used for signature validation provided that they pass first test.
Note
This behavior is designed to support Acrobat’s long term validation feature and allows validating a signature with embedded responses that were valid at signing time.
| Keyname | Default | Summary |
|---|---|---|
| {keyname} | {defaultvalue} | {summary} |