Troubleshooting ACS in 2025: Certificate Issues and Software Compatibility

In recent months, a few changes have been made to ACS on Adobe's end, largely without notification to Datalogics. These changes have led to some issues with newly-generated certificates in 2025. Here's what we know for certain:

Adobe updated their SSL cipher for ACS Certificates from SHA-1 to SHA-256. As a result, Java 1.7 (and some earlier versions of Java 1.8) are no longer compatible with ACS after installing a new certificate.

The nature of the other changes made by Adobe are unknown to Datalogics, but many users have noted issues with installing new p12 certificates, such as:

• E_LIC_LICENSE_SIGN_ERROR
• E_LSGN_NO_CERTIFICATE
• HTTP 500 on fulfillment /statuscheck page

As always, when you encounter these issues, it's a good first step to check all of the usual culprits--see ACS Errors and Troubleshooting. But, if you have carefully reviewed and still see these errors, we now recommend a solution that ACS users have reported success with:

This solution involves executing commands directly on the p12 file. First, execute the following:

openssl pkcs12 -in operator.p12 -clcerts -nokeys -out cert-from-p12.pem

openssl pkcs12 -in operator.p12 -nocerts -nodes -out key-from-p12.pem

These commands will "deconstruct" the p12 certificate, producing separate certificate and key files. The first extracts the certificate--see detailed explanation of the arguments below:

• openssl pkcs12: Tells OpenSSL to work with PKCS#12 files.

• -in operator.p12: Specifies the input file, operator.p12.

• -clcerts: Extract only the client (ACS) certificate, not CA certificates.

• -nokeys: Do not extract the private key.

• -out cert-from-p12.pem: Output the certificate to cert-from-p12.pem.

The second command extracts the private key--see detailed explanation of the arguments below:

• -nocerts: Do not extract certificates.

• -nodes: Do not encrypt the private key (it will be in plain text). WARNING: This argument will cause an unencrypted key to be produced--handle with care.

• -out key-from-p12.pem: Output the private key to key-from-p12.pem.

Next, you'll execute the following (detailed explanation of arguments follows):

openssl pkcs12 -export \
  -in cert-from-p12.pem \
  -inkey key-from-p12.pem \
  -name "operator" \
  -out operator-fixed.p12

• -export: Tells OpenSSL to create a new PKCS#12 file.

• -in cert-from-p12.pem: Specifies the certificate to include in the new .p12 file (cert-from-p12.pem).

• -inkey key-from-p12.pem: Specifies the private key associated with the certificate (key-from-p12.pem).

• -name "operator": Sets the friendly name for the certificate inside the .p12 file to "operator".

• -out operator-fixed.p12: Specifies the output file, which will be the newly created PKCS#12 file (note that "operator-fixed.p12" is just a name used for this example and not required)

Additionally, some customers have found that p12 certificates (which now make use of SHA-256) need to be re-encrypted using SHA-1 in order to work with their system. As this is a security downgrade, it is not officially recommended by Datalogics, but an option to consider at your own risk.

Such a command could look like this (details follow):

openssl pkcs12 -in oldcert.p12 -nodes \
  | openssl pkcs12 -export \
  -name "operator" \
  -keypbe PBE-SHA1-3DES \
  -certpbe PBE-SHA1-3DES \
  -macalg sha1 \
  -out newcert-sha1.p12

• openssl pkcs12 -in oldcert.p12 -nodes: Decrypts the old PKCS#12 and outputs the key+cert in plaintext PEM.
• The output is piped to a new openssl pkcs12 -export command.
• -keypbe PBE-SHA1-3DES and -certpbe PBE-SHA1-3DES: These specify SHA‑1–based encryption for key and cert.
• -macalg sha1: Ensures the MAC integrity check uses SHA‑1 instead of the default SHA‑256. NOTE: one customer had some trouble with this argument and used the "-nomac" argument instead. This reduces file integrity and is not recommended, but may help get the file encrypted, if needed.

Why does this help? The working theory is that the unknown changes made by Adobe can cause the new p12 certificates to be generated with some corruption or formatting issue(s). Executing the above commands will recombine the separate parts into a new p12 file, reportedly "fixing" the p12 file and/or making it compatible with more versions of Java/Tomcat/etc.

Software recommended for ACS in 2025:

NOTE: the following stack is representative of the ACS that we have running in-house, and thus it is proven. Component versions outside of the following may or may not work, with noted exceptions.

• Java: 1.8 (builds from 2021 to present) minimum; or the newest version that your Tomcat version supports. Java 1.7 does not work.
• Tomcat: Version 9 is the newest working version. Tomcat 10 does not work.
• MySQL: Version 9 is what we have running in-house, but more important than the MySQL version is the version of its JDBC connector driver. We use version 5 of this driver. Some strange and unpredictable behaviors have been observed with newer versions.