The hack for this - for Java 8 and 11, in this case is to place the bouncycastle jar under crx-quickstart\launchpad\ext (you may have to create the directory),Add the folowing to the sling.properties: sling.bootdelegation.class.org.bouncycastle.jce.provider.BouncyCastleProvider=org.bouncycastle.*sli...

I found the actual issue. The issue is with the updated Felix Framework code. The BundleProtectionDomain has been updated since 6.4 and seems to be breaking in 6.5 because of the ProtectionDomain Code Source returning a different value. In 6.4 and below, it returns a jar input type in the CodeSource...

This is definitely a bug with 6.5. In 6.3 AND 6.4 you don't have to do anything but install the bouncy castle jar file in OSGI. I didn't even have to add the sling bootleg delegation entries.

my thought was to create a modular jar file from the jar and put it under jdk-11.0.4\jmods. But since I don't have the source it makes it pretty difficult.

Got it working with Java 8 because I can update the included JRE with the bc jar. Since Java 11 doesn't have this, and that's what we are actually using, I'm trying to figure out how to get it working in there.

We are migrating a site in AEM 6.3 to 6.5(6.5.5).  During authentication, there is the use of PKCS7PADDING which is not working in 6.5 but does work in 6.3 with both environments having bcprov-bcprov- 1.66 installed: final Cipher decrypterWithPad = Cipher.getInstance("AES/CBC/PKCS7PADDING",BouncyCas...

Seems once I restarted after the install, it has gone away. Odd because usually if a SP need a restart, it does it automatically.

This is the same issue we are facing: https://issues.apache.org/jira/browse/FELIX-6184

There was a code deployment. It failed activation when trying to register again.

This seems to be the same thing I'm experiencing: