BD-J JAR files - signed certificate questions

[neil wilkes]

The very first question I have to ask is "Who do I write to so that a signed certificate actually gets accepted at replication"?
I tried the BDA, but they will not talk spec unless I get FLLA licensed at $24,000 plus for the 3 spec books required.

The trouble we are having is that when we include a properly signed JAR file certificate it gets knocked back at replication with an error that "signatory is unknown" and "Signature cannot therefore be trusted" and as a result "JAR file cannot be trusted".
The "fix" is to simply use an unsigned JAR file, which is then accepted for replication.
So the second question is "Why is a JAR file that could not be trusted when we signed it suddenly okay (and presumably can now be trusted for replication) now we have *not* signed it"?

Suspect the answer is to do with exactly what the JAR file is accessing or potentially capable of accessing (BD-Live?) so question 3 is therefore "What circumstances are mandatory for a signed JAR file"?

Thanks in advance to all - something that ought to be straightforward is a quagmire of insane red tape that nobody seems to want to talk about unless we fork out yet more enormous amounts of money

[neil wilkes]

Additional info - here is the fail report.
What does this mean, please?

Can't trust BD-J application
A BD-Java application can't be authenticated and, therefore, cannot be trusted.

Background
BD-Java applications and related files are stored in JAR files inside the JAR directory. The META-INF directory inside a JAR file includes the Manifest, Signature and Signature Block files. The Manifest file includes a hash for each file inside the JAR file. The Signature file has a similar structure as the Manifest file. However, the Signature file includes a hash for each file entry in the Manifest file. It also includes a hash for the whole Manifest file. The Signature file is signed and its signature is stored in a certificate inside the Signature Block file.
Since it is possible to have multiple signers, each signer will have a matching Signature/Signature Block file pair. To support multiple signers, the file naming convention is as follows:
Signature file: SIG-BDxx.SF
Signature Block File: SIG-BDxx.RSA
The xx is an identifier to distinguish one file from another, thus, allowing multiple Signature/Signature Block files. The xx portion of the files starts from '00' and increment sequentilly. A matching Signature/Signature Block file pair must have a matching xx identifier.
This error occurs when a Signature/Signature Block file pair is not found on the image. Therefore, a BD-J Application cannot be authenticated and, therefore, can't be trusted.

Additional Info
When this error occurs, the Additional Info column in the Analysis will display more details with the following message.
'' [AppID], '[JARFile]', ([SigFileID]) SF/SBF pairs
This message identifies the BD-J Object file being analyzed when this error occurred. The BD-J Object file contains a list of all BD-Java applications and the JAR file where they are stored. Each BD-Java Application is identified by a unique ID (AppID). Inside the JAR file, the Signature and Signature Block files contain hashes and digital signature for the BD-Java applications and related files. Since there could be multiple signers, the SigFileID identifies the Signature and Signature Block file pair that the EclipseSuite tools were analyzing. This error condition indicates that only one of the two files (Signature or Signature Block file) or neither was found.
[B]
Severity
If either the Signature, Signature Block, or both files are missing, then BD-Java applications cannot be authenticated and, therefore, cannot be trusted. This is considered an ERROR.

Cause
This problem typically occurs in authoring of the image.

[neil wilkes]

It seems to be saying that Sonic SafeGuard does not work, unless we are missing out a critical step somewhere along the line.
Any advice will be wonderful