From the ticket:
R&D: The issue is caused by the fact that a named security provider approach is used. This does not comply well with a multi-classloader environment (the Mendix Runtime code also uses BouncyCastle functionality). The fix is changing that approach to an explicit security provider approach.
In your case -->
Instead of:
import org.bouncycastle.jce.provider.BouncyCastleProvider;
Security.addProvider(new BouncyCastleProvider());
sig.init(new JcaPGPContentVerifierBuilderProvider().setProvider("BC"), publicKey);
Try this:
import org.bouncycastle.jce.provider.BouncyCastleProvider;
sig.init(new JcaPGPContentVerifierBuilderProvider().setProvider(new BouncyCastleProvider()), publicKey);
Due to the classloader structure of the Mendix Runtime it is better to not globally register security providers. So instead of doing:
Security.addProvider(new BouncyCastleProvider());
...
sig.init(new JcaPGPContentVerifierBuilderProvider().setProvider("BC"), publicKey);
Use the following approach:
sig.init(new JcaPGPContentVerifierBuilderProvider().setProvider(new BouncyCastleProvider()), publicKey);
This gives you the same functionality with the benefit of not having to register the provider globally.
The exception you got, is that the full exception or was there more? More details are needed to find out why exactly this failed.
Unfortunately I have run into this myself as well, in Mendix 7 the classloader seems to have changed and there seem to be a few cases where the platform mixes up the libraries that are being used.
If you startup through eclipse you can add -verbose class loader logging in the startup parameters and see which library is used for a specific function. For me I noticed that the platform was suddenly switching to a different library (from my program files folder), I was not able to find a way around this.
I would recommend to startup through eclipse and add the verbose class loading parameter to the startup, this allows you to confirm which library is being used. If you run into the same problem as I was you will see the same bouncy class package but 2 different folder locations. That isn't a valid/secure solution for BC.
If you see that same behavior unfortunately the only 2 recommendations I can give you is to submit a ticket, or use an implementation that doesn't require the 'Security.addProvider(new BouncyCastleProvider());' statement and can do explicit loading or execution.