One way is to exclude BC from war/ear and depend on BC provided by Wildfly's module:
The other option is to register BC in JDK (your JDK8 may already have it - I would check java.security):
See these issues/comments:
That's too bad. We've been able to avoid any JBoss specific deployment stuff up until now. We don't want to rely on Bouncy Castle being installed in the JRE. We want to be able to pick the version of Bouncy Castle our app uses.
At first I thought this was a bug in VirtualJarInputStream, but ZipInputStream behaves the same way. The bug is really in sun.net.www.protocol.jar.URLJarFile. It tries to read from a ZipInputStream like it was a normal InputStream. I guess maybe the problem is in the ambiguous meaning of the read() method.
If you need specific BC version you can deploy it as Wildfly module.
We're using Java 9, so it doesn't look like we can add BouncyCastle to the JRE. Java 9 gets rid of the lib/ext extension mechanism.