JCAPI version 2.2.3 has been released today.

This is a minor update containing:

• JCAPI is now re-signed with a new JCE/JCA code signing certificate from Oracle. The new certificate is valid until 10th of September 2023.
• Bugfix: Hash algorithms failed to be created when using Java 9 in 64-bit environments. Due to wrong datatypes used in JNI.
• Bugfix: Signatures failed to be created when using Java 9 in 64-bit environments. Due to wrong datatypes used in JNI.
• Bugfix: PKCS#7 envelopes failed to be created when using Java 9 in 64-bit environments. Due to wrong datatypes used in JNI.

For a complete list of enhancements and bug fixes made, please read the version history.
Our customers can download the commercial (unrestricted) version from the customers download page.

JCAPI version 2.2.2 has been released today.

This is a minor update containing:

• JCAPI is now re-signed with a new code signing certificate from DigiCert. The new certificate is valid until 17th of January 2020.

For a complete list of enhancements and bug fixes made, please read the version history.
Our customers can download the commercial (unrestricted) version from the customers download page.

Hi again François,

I did read your post too quickly.
The reason why it doesn't work is quite obvious. JCAPI v2 only support DSA and RSA asymmetric keys and their respective crypto engines through MS CAPI. Support for ECDH is part of the coming JCAPI v3 which is to be released next year.

I am afraid that you have to choose another JCE provider meanwhile.

Regards,
Tommy

Hi François,

Sorry for the late reply. Many things in the pipe right now.
I'll take a look at it asap.
Thanks for attaching code to reproduce the problem.

Regards,
Tommy

JCAPI v1.x has now reached the end of its EOL maintenance period that started 3 years ago. This means that Pheox AB effectively from now does not provide or sell any support or maintenance of this version.

If you still need support and maintenance releases of JCAPI, we kindly recommend you to upgrade to JCAPI v2.x.

Thanks.

Hi Andrew,

You can choose what CAPI system stores to use when you work with certificates in JCAPI. The class you should work with is named JCAPIProperties.

Here is an example of how you can do:

KeyStore ks = KeyStore.getInstance("msks", "JCAPI");

ks.load(null, null);

JCAPIProperties.getInstance().setExclusiveMSCertStore(ks, "Root"); //This will tell JCAPI to only use the CAPI system store Root.



..Do your stuff here...



JCAPIProperties.getInstance().resetMSCertStoreNames(); //Use the usual CAPI system stores again.

Just let us know if it doesn't work out for you.

Regards,
Tommy

Hi oria,

That's ok. Just glad it works out for you at last.
Unfortunately we can't figure out the reason for this weird behavior.
We have not received a single issue from any customer yet (except for you) due to this upgrade, and some of them are using JCAPI on 24/7 VISA/Mastercard servers.

If you encounter any other strange issues when using JCAPI, then please tell us as soon as possible. Thanks.

Take care.

Regards,
Tommy

Hi again oria,

We have now tested v2.2.1 towards all supported platforms to find your reported problems. Unfortunately, we have not been able to reproduce them. I have attached two small isolated test programs which you can use to reproduce it yourself. They will cover both your eToken and Base Provider problems you had. If they can't be reproduced, then please modify them to trig the problems you have so we can fix them.

Thanks.

Regards,
Tommy

Hi oria,

Thank you for the input.
This is not acceptable. Version 1 and 2 must be identical when it comes to both enryption and signing. Apparently this is not the case. Sorry for that. We'll investigate it immediately.

First we need to reproduce the problems in our test lab. We'll start now, but it would help us a lot along the way if you could provide the following info:
1. Which version of JCAPI v1 are you using?
2. Have you only tried with JCAPI v2.2.1 or does it work with previous v2 releases?
3. What operating systems and machine architectures (32-, 64-bits) are working/failing?

Thanks.

Regards,
Tommy

Hi,

The reported problem has now been fixed in JCAPI version 1.2.8 and 2.2.1.

Regards,
Tommy

JCAPI version 2.2.1 has been released today.

This is a minor update containing:

• Added property Trusted-Library into the JCAPI manifest file to allow mixing privileged code and sandbox code.
• Added properties Permissions, Codebase and Application-Name into the JCAPI manifest file to avoid security warnings with Java 7u45 and higher.
• JCAPI is now re-signed with a new code signing certificate from DigiCert. The new certificate is valid until 13th of December 2016.
• JCAPI is now re-signed with a new JCA code signing certificate from Oracle. The new certificate is valid until 28th of October 2018.
• Bugfix: Private keys was stored in CERT_SYSTEM_STORE_CURRENT_USER location even though JCAPI was configured to store them in CERT_SYSTEM_STORE_LOCAL_MACHINE.
• Bugfix: The JCAPI DLL was extracted every time from the jcapi.jar file even though the exact same DLL had been extracted before.

For a complete list of enhancements and bug fixes made, please read the version history.
Our customers can download the commercial (unrestricted) version from the customers download page.

JCAPI version 1.2.8 has been released today.

This is a minor update containing:

• Added property Trusted-Library into the JCAPI manifest file to allow mixing privileged code and sandbox code.
• Added properties Permissions, Codebase and Application-Name into the JCAPI manifest file to avoid security warnings with Java 7u45 and higher.
• JCAPI is now re-signed with a new code signing certificate from DigiCert. The new certificate is valid until 13th of December 2016.
• JCAPI is now re-signed with a new JCA code signing certificate from Oracle. The new certificate is valid until 28th of October 2018.
• Bugfix: Private keys was stored in CERT_SYSTEM_STORE_CURRENT_USER location even though JCAPI was configured to store them in CERT_SYSTEM_STORE_LOCAL_MACHINE.
• Bugfix: The JCAPI DLL was extracted every time from the jcapi.jar file even though the exact same DLL had been extracted before.

For a complete list of enhancements and bug fixes made, please read the version history.
Our customers can download the commercial (unrestricted) version from the customers download page.

Hi Alfonso,

Thanks for the information.
We're about to release a new version of JCAPI containing one bug fix. It will also be re-signed with new code signing certificates from Oracle and DigiCert. We'll investigate this new Permissions feature/constraint and make sure that it will be part of the next release as well.

Regards,
Tommy

Hi,

We've now released a new re-signed version of JCAPI whose manifest file contain the new Trusted-Library property.

For more information, please see our release post.

Regards,
Tommy

JCAPI version 2.2.0 has been released today.

This is a minor update containing:

• Added property Trusted-Library into the JCAPI manifest file to allow mixing privileged code and sandbox code.

For a complete list of enhancements and bug fixes made, please read the version history.

Our customers can download the commercial (unrestricted) version from the customers download page. Others are welcome to download the evaluation version from our public download page.