Hi Igor,

The error code you encounter indicates that the private key handle is invalid when accessing the private key through Safenet's MS CAPI CSP. This is fortunately not that common these days since most companies are more careful (and observant when it comes to the non-mandatory parts of the API) when implementing a MS CAPI CSP.

You mentioned that you tried to add Safenet's PKCS#11 provider to JCAPI without any success. Did you actually try the following?
JCAPIUtil.addPKCS11CSP("Datakey RSA CSP", "dkck201.dll");

If it still doesn't work, then please respond with the output from this test.

Regards,
Tommy

Hi,

What happens is that the JCAPI DLL is calling the MS CAPI function CertGetCertificateContextProperty() with dwPropId set to CERT_KEY_PROV_INFO_PROP_ID
in order to get the name of the CSP from the returned CRYPT_KEY_PROV_INFO struct. Your error code indicates CRYPT_E_NOT_FOUND, which means The certificate does not have the specified property.

At a first glance, it doesn't seem that good for JCAPI to ask for the CRYPT_KEY_PROV_INFO struct since it holds the information about the private key associated with the certificate in question. That struct can not be returned for a certificate entry since it doesn't have a private key (only key entries have private keys and can thus return such a struct).

From your program's output, I assume that the alias My|8dsVZRHLJApzdktl+AJnmcBeIkE= trigger this problem. This certificate is stored in the MY system store which indicates that it should be a key entry, but it doesn't have to be since certificates without a private key can be stored there as well.

Is it possible for you to find out if the certificate with alias My|8dsVZRHLJApzdktl+AJnmcBeIkE= has a private key or not?
Meanwhile, I will setup a test case here to reproduce your problem.

Regards,
Tommy

Hi Chris,

The problem is not within JCAPI.
You cannot get the CRL list from a certificate since it doesn't contain one. However, most certificates have something called "CRL Distribution Points" which contains one or more URLs to be used for downloading CRLs. Consequently, you have to:
1. Get the CRL URL(s) from your certificate. Perhaps by using the getExtensionValue() method in X509Extension class, see link below.
2. Download the CRL(s). Perhaps by using the HttpURLConnection class with a URL class.
3. Decode the downloaded ASN.1/BER encoded CRLs into manageable Java X509CRL instances by using the method generateCRLs() in class CertificateFactory.

A good starting point would be:
http://www.javaworld.com/javaworld/jw-03-2001/jw-0316-howto.html
http://juliusdavies.ca/commons-ssl/src/java/org/apache/commons/ssl/Certificates.java

Regards,
Tommy

JCAPI version 1.2.4 has been released today.

This is a minor update containing:

• The JCAPI JAR file has been re-signed with a new code signing certificate since the former will expire at the 25th of May 2009. The new certificate is valid until 24th of May 2011. This will affect you if you're using JCAPI in a trusted applet.
• Bugfix: Wrong error code was caught when a signing operation failed in the PKCS#11 layer. Now the signing method throws an expected SignatureException when the operation fails.

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.

Hi Tom,

Hopefully, we'll have JCAPI v2.0 to be launched during Q3 this year.
The precise upgrade discount for existing customers is not yet decided, but it will be around 40%.

Regards,
Tommy

Hi Tom,

Yes, JCAPI is still maintained. The latest release is from December 2007, and it won't begin EOL (End Of Life) until JCAPI v2.0 has been released.

Current version of JCAP is compatible from Vista down to Win98.

Regards,
Tommy

Hi Smari,

This has nothing to do with the obfuscation applied onto the JCAPI.dll file. The DLL has not yet been dynamically linked into the JVM process when your exception occur.
Your problem comes from either of two reasons:
1. The file jcapi.jar have been tampered with.
2. In internal unknown error in JCAPI never discovered earlier has occurred.

Can you please supply us the following information:
1. The jcapi.jar file you are using (just attach it to this forum thread).
2. The output from executing method JCAPIUtil.getEnvironmentInfo() from within a Java app. For more info, see page 35 in the JCAPI User's Guide.
3. The version of your Tomcat installation.
4. A minimal WAR file which triggers this error.
5. Any other additional information which can help us to solve this problem, for example any special settings used for Tomcat or Java.

We will try to get as close as possible to emulate your environment in order to reproduce your problem.

Thanks.

Regards,
Tommy

Hi Bill,

JCAPI v2 should have been released this year, but have been temporarily postponed since focus have been put on other projects instead. Due to its nished nature, JCAPI is currently too small to carry its own full time development costs. Well, it's pure business in the end so to say.
But a a good guesstimate is around July-August 2009.

Of course, if time is of most importance, then your company is welcome to contact Pheox for consultancy service. I'm rather sure that some kind of satisfactory solution can be arranged to solve your specific problem within a reasonable time frame.

Regards,
Tommy

Hi Bill,

Aha, yes, I see your problem.
The problem from a JCAPI perspective is that SSL is managed outside JCAPI i.e. through JSSE which in turns relies on the fact that a private key is exportable. Unfortunately we can't provide a solution for that unless we either hack the JSSE implementation or provide our own SSL stack.
Support for this will be implemented in JCAPI v2.0 with Java 6. We have though currently no plans on fixing this for earlier Java versions unless there is a very good reason for doing so, since we must in that case make large changes into code/products which are outside the scope of the JCAPI product. There is currently no incentive for such a massive work so to say since the customer base is fairly small for niched products like JCAPI, even though it's a good product

I hope you do find another solution that suit your needs and solve your problems.

Regards,
Tommy

Hi Bill,

Yes, it seems to be exactly the same problem as reported earlier in this forum thread.
The possibility that our third party provided obfuscation solution causes this problem is quite large so to say
We have recently received an upgrade of this software, but not tested it yet. I will, tomorrow, create a new JCAPI DLL file using the most recent version of the obfuscation software for you to try with. I will also fix a non obfuscated dito. Meanwhile, could you please send your email address to support@pheox.com, please include a link to this thread. I will send you the new JCAPI JAR files asap. Please report your findings back to this thread.

Thanks.

Regards,
Tommy

Hi Alok,

You can use it for client authentication without problems if the private key associated with your IE certificate is exportable from the key store. It will not work when the private key is stored on a smartcard since such a key will not be exportable.

There are ways around this problem as well (for non-exportable private keys), but then you have to use Java 5 or higher and also provide a PKCS#11 driver for your smartcard.

There are several posts about this on this forum. A good start would be the following post:
http://pheox.com/posts/list/18.page

Let us know if you have further questions.

Regards,
Tommy

UPDATED INFORMATION!

We have now implemented a DigestInfo ASN.1/DER encoder into JCAPI's PKCS#11 layer. This encoder is now used together with the PKCS#11 providers to generate RSA PKCS#1 compliant signatures.

This fix has been incorporated into JCAPI v1.2.3.

For more info, please see:
http://pheox.com/posts/list/39.page

Regards,
Tommy

JCAPI version 1.2.3 has been released today.

This update contains the following bug fix:

• Signatures made by PKCS#11 providers through JCAPI's PKCS#11 layer was built upon a raw hash value instead of a ASN.1/DER encoded DigestInfo structure (containing the hash value and its associated algorithm identifier) as specified by the RSA PKCS#1 standard.

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.

Hi Francky,

That kind of operation is already supported by SUN's Java class X509Certificate i.e. it's not a JCAPI specific operation.

Here's an example of how to export the binary (ASN.1/DER) representation of an X.509 certificate:

import java.security.*;

import java.security.cert.*;

import java.io.*;

import java.util.*;



import com.pheox.jcapi.*;



public class ExportCert

{

    static public void main(String[] args)

    {

        try {

            export();

        } catch(Throwable t) {

            t.printStackTrace();

        }

    }



    static private void export()

        throws Exception

    {

        System.out.println("Export certificate to file cert.cer");



        Security.addProvider(new JCAPIProvider());

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

        ks.load(null, null);



        //Get first certificate found.

        Enumeration aliases = ks.aliases();

        String alias = (String)aliases.nextElement();

        if(alias == null)

            throw new Exception("No certificate found.");

        X509Certificate cert = (X509Certificate)ks.getCertificate(alias);



        //Export/write certificate to file (X.509 ASN.1/DER).

        FileOutputStream fos = new FileOutputStream("cert.cer");

        try {

            fos.write(cert.getEncoded());

        } finally {

            fos.close();

        }



        System.out.println("Done!");

    }

}

Regards,
Tommy

Hi,

I've looked further into this.
Unfortunately, our PKCS#11 implementation creates a raw signature based on the given hash i.e. the signature is created from hash value + PKCS#1 padding which is then encrypted using the private key stored on the token. The good part is that it is still a valid signature that is correctly verified by MS CAPI. However, the signature should be a valid PKCS#1 signature where the hash (digest) value should be put into a DigestInfo structure which is then padded to block limit and then encrypted (see the RSA PKCS#1 standard for further info).

We'll get a fix on this as soon as possible.

Regards,
Tommy