cCustomCertPrefs directory provides the means to use certificate-specific settings to modify application behavior when it encounters a particular certificate. As the application builds a certificate chain, it compares the information it finds in the certificate with that in the registry to see if there is a match. If there is a match, the custom settings are used to override the application’s default behavior. Certificates that chain up to a CA that match those configured here or that contain recognized extensions will use the preferences set in this directory.
You can use any of the preferences available in
cASPKI in your customized preference under
\cASPKI\cASPKI\cCustomCertPrefs. Custom certificate preferences are specified differently than when they are used globally under
\ASPKI. For example, The naming and path convention is always
c<key>:c<index>:<type>Value, where the global preference would be
sSignCertOID and the custom preference would be
cSignCertOID (the data type is associated with the
Value subkey rather than the key.
Certificates are identified by creating a hash of a unique identifier and appending it to c such as c312E322E3834302E3131343032312E310000. When the application finds in a certificate chain a hash that matches the hash in the registry, the custom preference is used. Locate custom preferences under one of the following methods:
You identify certificates with a hash of its public key. Adobe’s Certificate Viewer provides an easy way to get the public key hash. To do so:
This registry key is now ready to be populated with custom preferences.
On a Windows machine, certificate-specific preferences can be added by following the steps below:
HKEY_CURRENT_USER\Software\Adobe\(product name)\(version)\Security\cASPKI\cASPKI\cCustomCertPrefs\<your ID hash>.
cCustomCertPrefsare always a cab and the name is prepended with a “c.” For example, to set a timestamp server provider preferences, you would use the available timestamp preferences. While the key list shows
sPasswordas a valid name, when it is used under
CustomCertPrefs, the entry should be renamed to
Requirements will vary based on your specific need:
|You can associate a custom certificate with a chain scope. iStart and iEnd can be used to specify for what parts of a certificate chain a custom certificate preference will apply. They are always used at the container level of c0, c1, c2, and so on. For example, Acrobat could be configured to search for acceptable policy OIDS only in the certificates that are the first, second, and third levels below the root CA.|
|iStart||int||(v 7.0) Determines the start of the preference relevance depth relative to the certificate chain. By default, the preference starts at the current level.|
|iEnd||int||(v 7.0) Determines the end of the preference relevance depth relative to the certificate chain. By default the depth of the preference is MaxUns32|
To specify a scope within a chain:
<root>\cCustomCertPrefs\<certificate public key hash>\cAdobe_ChainBuilder\cAcceptablePolicyOIDs\c0.
Acrobat has two custom certificate preferences that enable Identrus compliance at
HKCU\Software\Adobe\Adobe Acrobat\Security\cASPKI\cASPKI\cCustomCertPrefs\<hash of Identrus OID>. You can use this as a template for a similar custom certificate preference:
Whenever a credential that chains up to an Identrus CA is used for signing or signature validation, the application follows the Identrus rule set rather than the default rule set. The custom certificate preferences enable Acrobat to recognize Identrus certificates and process them as required by Identrus.
When Acrobat starts for the first time, it checks whether
bCustomPrefsCreated is set. If not set to
true, Acrobat writes out the Identrus rule set that is hard coded within Acrobat. If it’s already set, then writing out the Identrus rules is skipped.
If the Identrus rules in Acrobat need to be changed without updating Acrobat, then create a custom installer (tuned with the wizard) that sets
bCustomPrefsCreated ``to ``true and writes out the new Identrus rules. Acrobat will then first check whether custom preferences have been created. If they are already created, then Acrobat won’t write out the Identrus rules within Acrobat, and those written out by the custom installer will be respected by ASPKI.
An Identrus CA is identified by the certificate policy OID 1.2.840.114021.1.1.1 present in the production Identrus root CA. However, the certificate policy OID present in their test root CA is different, and in order to be able to test Acrobat against the test Identrus environments, Acrobat also uses the same Identrus rules for CAs that have the certificate policy OID 1.2.840.114021.1. Identrus certificates must contain one of the OIDs supported by the
AcceptablePolicyOIDs preference. If the OID is not present, the certificate is deemed to be invalid and the signature will also be invalid.