The process is described in the document, "How to Implement a Provider."

It involves emailing Sun Oracle some information (including the CSR you generated for your signing key), then faxing a confirmation document. Getting your signed certificate back can take a week or more, so plan ahead.

You only need to sign your provider if it provides services that are restricted by some (repressive) governments. For example, a Cipher implementation is a restricted "service," while MessageDigest is an unrestricted service. I assume with the message you re getting, that you are trying to provide a restricted services.

If you provide any of these services, there s no way around it: You need a code-signing certificate issued by Sun. (One from IBM might work too; if I recall correctly, their code-signing CA is supported, but I don t know anything about their issuing process.)

An alternative is to design your custom provider using OpenJDK. This is the open-source project sponsored by Sun/Oracle, and provides the code base for their official release. OpenJDK does not require providers to be signed. OpenJDK is available (by default, now) on several Linux distributions. Unfortunately, it does not seem to be readily available on Windows or Macintosh. If you re running Windows or Macintosh, I recommend installing Linux into a VM.

If you must develop on Windows or Mac, however, you can copy the jce.jar file from an OpenJDK install over jce.jar (in your Java lib directory) of an official install. This will effectively circumvent the Jar authentication process. Be sure to put the original jce.jar file back when you re done developing, though.

You have to sign the JAR with "JCE Code Signing CA". In all current Java distributions, only 2 CAs (Sun and IBM) are built-in (hard-coded) and there is no way to add your own. We tried to work with Sun to sign our provider and it s almost impossible. They wouldn t issue intermediate CA cert, which means you have to go through the trouble every time you make a change.

Why don t you just user your own library? You use standard API for interoperability between different JCEs. But that s not realistic for CryptoKi/SmartCard stuff right now, you almost always need to write some custom code to interact with vendor specific API. You can even make your code mimic JCE API to minimize code changes.

Only for extra info, i got this same exception when i build a JAR (Eclipse Juno) with the option "Extract required libraries into generated JAR" instead the correct "Package required libraries into generated JAR"

Well, after reading about the handshake with some Oracle authority, my solution is writing an independent Cipher class with own signature verification, which in case of other providers than "me" delegates to javax.crypto.Cipher.

This seems to be obligatory as there is nearly no algorithm available over all Java releases, also the limits of some algorithms strength is not satisfying and essentially, Oracle does not need to know about my encryption algorithms.