POST /ae/api/v1/0/system/ra-solutions/upload

[Michael A. Lowry]

The API documentation for POST /ae/api/v1/0/system/ra-solutions/upload does not describe the parameters:

• checksum
• algorithm
• ignore_signature

I was able to get it working by setting ignore_signature to true, but I imagine this is not a good idea. MD5 and SHA-256 appear to be accepted values for algorithm, but passing the corresponding checksum results in this response from the server:

400 Bad Request

{
    "code": 38204,
    "error": "The Signature of the given jar archive is not valid.",
    "details": "#38204"
}

What's the secret to getting the signature check working?

Two more points for @Gabi Oberreiter / @Gabi Oberreiter:

• It would probably be a good idea to document this.
• The REST API 24.2 documentation is missing.  Update 2024.11.13: The v24.2 documentation is now available.
  

[Michael A. Lowry]

I performed a few more tests to try to better understand what these parameters do. I learned a few things.

• Valid values of algorithm include MD5 and SHA-256.
• The checksum must be a hexadecimal string.
• The length of the checksum string must be appropriate for the algorithm specified. E.g.,
  
  • MD5: 32 hexadecimal digits
  • SHA-256: 64 hexadecimal digits
• The provided file must be a JAR file (ZIP compressed).

If any of these preliminary checks fails, the AE REST process responds immediately with:

400 Bad Request

{
    "code": 45106,
    "error": "The request is invalid and cannot be processed by the Automation Engine.",
    "details": "No detail information available."
}

If the preliminary checks pass, the AE REST process reads the provided JAR file, and performs the signature check. I'm not sure how this part works, and I have been unable to persuade the AE server to accept any file when ignore_signature is set to false.

I opened a support ticket with Broadcom; I will report what I learn here.

[Michael A. Lowry]

The signature check is separate from the the validation of the file checksum.

File checksum

Confirm that the uploaded file arrives intact at the AE server.

• If a checksum is provided, this checksum is compared with the checksum of the uploaded file.
• If algorithm is not specified, the default is MD5.
• If the checksums do not match, the AE REST process responds with HTTP response code 400 & AE error code 45106.

JAR signature

Confirm that the JAR file has not been modified since it was signed by the developer. See Signing JAR files (Oracle).

• If ignore_signature is set to false, the AE REST process performs this additional signature check.
• The signature check always fails. It's not clear what the reason is. If I verify the signature from the command line using jarsigner*, there are warnings. Perhaps the AE REST process considers these warnings sufficiently serious to mark the signature check unsuccessful.

* Here is what it the signature check looks like from the command line:

$ jarsigner -verify -verbose WebService_REST_solution_4.6.14.jar

s        483 Mon Oct 21 15:56:10 CEST 2024 META-INF/MANIFEST.MF
         616 Mon Oct 21 15:56:10 CEST 2024 META-INF/UC4JAVAS.SF
        3947 Mon Oct 21 15:56:10 CEST 2024 META-INF/UC4JAVAS.RSA
           0 Mon Oct 21 15:56:08 CEST 2024 META-INF/
sm    28606690 Mon Oct 21 15:56:06 CEST 2024 WebService_REST_Agent_deploy_file.jar
sm    751192 Mon Oct 21 15:55:54 CEST 2024 ecc-ae-sheet-ra-webservice-rest.jar
sm        27 Mon Oct 21 15:56:08 CEST 2024 version.txt
sm       349 Mon Oct 21 15:56:08 CEST 2024 components.xml

  s = signature was verified
  m = entry is listed in manifest
  k = at least one certificate was found in keystore

- Signed by "CN=Automic Software GmbH, OU=Secure Application Development, O=Automic Software GmbH, L=Vienna, ST=Vienna, C=AT"
    Digest algorithm: SHA-256
    Signature algorithm: SHA256withRSA, 2048-bit key

jar verified.

Warning:
This jar contains entries whose signer certificate has expired.
This jar contains entries whose certificate chain is invalid. Reason: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
This jar contains signatures that do not include a timestamp. Without a timestamp, users may not be able to validate this jar after any of the signer certificates expire (as early as 2019-06-09).

Re-run with the -verbose and -certs options for more details.