The Credential Selected For Signing Is Invalid Adobe

When you attempt to install Adobe After Effects CS4 on Windows Vista 64, the installation fails and displays the following dialog box:

Since then, I attempted to recreate my update list, and I get an 'invalid certificate signature' message when downloading the update in SCCM. I deleted the updates from their location on the server (windowsupdates folder I created to place them in), and deleted the update list, package, and previous advertisements in attempt to start over. Acrobat 6 and earlier: Sets the default signing credential when a P12 file contains more than one digital ID. Acrobat 6 and earlier: Sets the default encryption credential when a P12 file contains more than one digital ID. Set within the P12 file SecretBag along with the. The credential selected for signing is invalid. Installing Acrobat Reader 2020.009.20063 works with such certificate digital signature. But no Adobe Acrobat. I´m trying to sign digitally with my certificate (given by the Spanish Police Authority), and the message received is that the credential i´m trying to use is invalid. It´s valid because i´ve signes documents with that (web application Valide from spanish gobernment, and is valid until 29 january 2020). But i need to sign a pdf document.

'Invalid User Credentials. You do not have sufficient security credentials to install Adobe After Effects CS4.'

you are not prompted to authenticate with an administrator account, and using Run as Administrator gives the same results.

This error can occur when a standard (non-administrator) user attempts to install Adobe After Effects CS4 in Windows Vista 64 when User Account Control (UAC) is disabled.

Temporarily enable UAC and run the installer again.

To temporarily enable UAC, see the To enable User Access Control (UAC) section of 'Disable User Account Control (Windows Vista)' (TechNote kb404888)

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.

Recommendations¶

To leverage Acrobat’s rich digital signature capabilities, follow these best practices:

1. Familiarize yourself with this guide, the Preference Reference, and the Customization Wizard.

2. Learn about setting registry and plist preferences, including feature locking, paths, the relationship between the UI and the registry, and other topics.

3. When using the Preference Reference, pay attention to the supported versions, OS, and other details.

4. Install the application and configure it via the UI. Set the preferences in the Security and Signatures categories.

5. 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.

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

7. Deploy the application as described in the Administration Guide.

8. 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.

Deployment checklist¶

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

1. Establish PKI Trust via CDS, AATL, or local trust lists.

2. Set up Directory Server Connections.

3. Set up the Signing Environment requirements, workflow, and method. You may also want to create enterprise signature appearances as described in Custom Signature Appearances.

4. Configure the Timestamp Servers list, defaults, and usage.

5. Configure Signature Validation logging, revocation checking, service providers, and so on.

6. Tune Certificate Revocation Checks for OCSP, CRL, and the interaction of each.

7. Review the Preference Reference for additional other signature-related preferences you may need.

8. If required, enable FIPs compliance.

9. 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.

10. Test.

11. Deploy.

FIPS compliance¶

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:

• Acrobat 9.x and earlier: Crypto-C ME 2.1 encryption module with FIPS 140-2 validation certificate 608.
• Acrobat 10: Crypto-C ME 3.0.0.1 encryption module with FIPS 140-2 validation certificate 1092.
• Acrobat 11: Crypto-C ME 4.0.1.0 encryption module with FIPS 140-2 validation certificate 2056.

FIPS mode changes Acrobat’s default behavior as follows:

• FIPS-compliant algorithms are always used.
• Self-signed certificate creation is disabled. In FIPS mode, users cannot create self-signed certificates.
• Signing with non-FIPS supported algorithms results in an error message; that is, signing fails if the document hash algorithm (digest method) is set to MD5 or RIPEMD160.
• Password security is turned off. Users can apply certificate or Adobe LiveCycle Rights Management Server security using the AES encryption algorithm to a document, but password encryption is disabled.
• When applying certificate security, the RC4 encryption algorithm is not allowed.
• Documents protected with non-FIPS compliant algorithms cannot be saved.

PKI trust¶

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)¶

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.

Adobe Acrobat Trust List (AATL)¶

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.

Share trusted identity lists¶

Trust settings are often stored by the application in an acrodata file that stores a list of trusted identities. As described in Security Setting Import-Export, Acrobat simplifies the migration of existing security settings through version upgrades and across multiple machines. The .acrobatsecurity settings file supports the import and export of all settings including digital ID data, trust, server details, signing preferences, and so on. Only Acrobat can export settings, but all products can import them. These settings can be imported manually per client or placed on a central server for automatic download.

Other digital ID options¶

Other methods for setting up trusted workflows include:

• Custom Certificate Preferences.
• MSCAPI integration and the Windows Certificate Store. See the Windows preferences in the Preference Reference.
• Roaming ID Server Integration, see the Roaming ID preferences in the Preference Reference.
• OIDs and Certificates.

PKCS#11 token and smart card integration¶

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.

1. Set cAdobe_P11CredentialProvider as described in .
2. Distribute the module file, such as dkck201.dll with instructions where to locate it.
3. Instruct users to restart Acrobat.

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 server connections¶

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)AppDataRoamingAdobeAcrobat11.0Securitydirectories.acrodata.

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.

Server configuration¶

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.

The Credential Selected For Signing Is Invalid Adobe Flash Player

Product configuration¶

Administrators can configure directory servers in several ways:

• Pre-installation (Recommended): You can tune the client installer with the Adobe Customization Wizard prior to installing the application on various machines. The process involves configuring a directory server in your template application installation and using the wizard to copy the directories.acrodata file to the tuned installer.
• Post-installation setting distribution: You can export server configuration details in an 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.
• Post-installation instruction distribution: The administrator can tell users how to configure the server manually.

To configure a directory server manually:

1. Open the Security Settings Console. The method varies across versions. For 11.0, choose Preferences > Security > Configure Server Settings > More.

2. Select Directory Servers in the left-hand list.

3. Choose New.

4. 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=BrownTrout,ou=Engineering for 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.

5. Optional: Make the server the default one to search by highlighting the directory server in the right-hand panel and choosing Set Default.

6. Choose OK if a confirmation dialog appears. A star appears next to the default server.

Signing environment¶

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.

Signing format¶

Replace the default signature format.

Signing hash algorithm¶

Replace the default hash algorithm.

Signing digest comparison¶

Require a message digest match.

Signing Preview Mode¶

Require the use of Preview Mode.

Signing certification¶

These settings pertain specifically to certified signatures in certified documents. See also bTrustCertifiedDocuments.

Long term validation¶

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 SecureTime. 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.

Signing revocation checking¶

Require a revocation check for the signer’s certificate.

Signing reasons¶

Control signing reasons.

Signer details¶

Show a signer’s location and contact details.

Timestamp servers¶

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.

Setting a default timestamp server¶

The Credential Selected For Signing Is Invalid Adobe Flash

Configuring the timestamp server list¶

Configuring timestamp usage¶

Diplaying timestamp server time¶

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:

1. Go to HKLMSOFTWAREPoliciesAdobe(product)(version)FeatureLockDowncSecuritycPubSec.
2. Create the new DWORD bUseTSAsSigningTime and set it to 1.
3. Go to HKCUSoftwareAdobe(product)(version)SecuritycASPKIcASPKIcSign.
4. Set bReqSigPropRetrieval to 1. Create the preference if it does not exist.
5. Verify the computer time does not vary from the signature validation revocation check response time specified by HKCUSoftwareAdobe(product)(version)SecuritycPubSeciMaxClockSkew. 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¶

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.

Validation main settings¶

Certificate chain building¶

Specifying directory providers¶

Signature status icons¶

Validation logging¶

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.

Certificate revocation checks¶

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:

• While doing OCSP revocation checking for the ICA, the preferences specified for the CA are used. If the scope for the preferences is specified as infinite, then the CA preferences are also used for revocation checking the EE.
• While doing CRL revocation checking, if no preferences have been specified either for the CA or the ICA, then the preferences present at cASPKI:cAdobe_CRLRevChecker are used instead.

General settings¶

Specify revocation checking providers.

Specify signature revocation checking constraints.

OCSP revocation checking¶

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.

• Rule 1 (Acrobat 8.0): defined the local configuration rule as follows by authorizing OCSP responses that come from responders specified by sURL.
• Rule 2(Acrobat 9.0): If a custom certificate preference has a new “AuthorizedResponder” boolean entry with a value of true, and the certificate being checked for OCSP revocation as well as the OCSP response both chain up to the customer certificate, then the responder is authorized.

The order in which verifying OCSP responders occurs is as follows:

1. Local configuration rule #1 (A8 and A9).
2. Local configuration rule #2 (new in A9).
3. The two deterministic methods from RFC2560.

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:

• Specifying when to do revocation checking as well as the effect of a failed or bad response.
• Specifying when and where to go online to get a response.
• Specifying whether to include a nonce. Nonces are random generated numbers that are sent with a revocation check request and matched by a response. They improve security by assuring communication with an active, non-spoofed server.
• Using or ignoring a response’s thisUpdate and nextUpdate times to control its validity. See RFC 2560 for details.
• Setting a limit on the amount of time difference between the local time and response’s publish time.

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:

• Validation time is greater than thisUpdate minus the value of maxClockSkew (the default is 5 minutes). This test is always performed.
• When nextUpdate is present and the validation time is less than the nextUpdate time plus the value of maxClockSkew.
• When 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.

CRL Revocation Checking¶