Creating X.509 certificates programmatically in Java

The artical comes from https://www.mayrhofer.eu.org/create-x509-certs-in-java

My probem statement was simple: create a X.509 certificate with only a few fields being configurable, sign it with an already existing CA private key/certificate combination, and write the new certificate in PKCS12 format. Then it became complicated: I needed to it with Java, on a PDA.

I spent about 2 days to get this seemingly simple task to work, so I thought it might be good to share my findings in the hope that they will serve others with similar problems.

Update: This page has seemingly found some interest, as I regularly get email asking about specific details. Please feel free to do so, even if I occasionally need quite some time to respond due to the overall volume of email I receive. This page has been translated e.g. by  Jennifer Indurayne.

Why to create certificates with Java?

There are many command-line tools available for creating X.509 certificates, like the keytool distributed with the Sun JDK or openssl, ported to many platforms. So why go through the hassle of doing it with a Java class? I seriously considered using the mature and proven openssl toolkit and simply calling it with Runtime.Exec, passing appropriate parameters and standard input. However, this brings forth serious problems with platforms not using J2SE, like J2ME JVMs on PDAs (often CDC) or even mobile phones (often CLDC). Executing system commands is sometimes supported with CDC, but practically never with CLDC. Additionally, openssl needs a config file that could

  • either be assumed to already exist on the device to use (read: difficult set-up instructions for the application that is actually written in Java, involving the installation of openssl and of an appropriately written config file)
  • or be managed (read: created, modified, and removed) from Java, causing extra complexity.

Thus, openssl is stable and would work on Desktop-like platforms (J2SE), it is challenging especially for more embedded platforms. I decided to bite the apple and try to implement the certificate creation directly in Java.


 

Java crypto API possibilities

The obvious choice for doing any crypto work with Java is the JCE/JSSE infrastructure included with the more recent versions of J2SE. JCE is, due to historical and now obsolete reasons of (very broken) US export laws, split into infrastructure and provider parts, where J2SE started shipping the default SunJCE provider with version 1.4. But, similar to the Runtime.Exec situation, JCE is hardly supported on JREs targetted for embedded use, so we can't assume it to be available on PDAs or mobile phones. To make matters worse, JCE is not replaceable by third-party libraries anymore, so it's hardly possible to ship JCE libraries with the application.

An alternative for crypto operations with Java is the excellent Bouncycastle library. It can act as a JCE provider, but it also provides a "lightweight" API to its crypto and utility routines that can be used independently from the JCE infrastructure. The classes from Bouncycastle are available under a very liberal license and can be added to any application, thus providing crypto support for platforms that don't have it in their JRE. I decided to implement the certificate generation with the Bouncycastle lightweight API (referred to as BC from now on).

Note: Unfortunately, the org.bouncycastle.x509.X509Util class is not marked public in the Bouncycastle JAR and can therefore not be used from ouside. For the following code to work, it needs to be made public, typically by modifying the source and re-creating the JAR. For the OpenUAT toolkit, I copied a subset of the Bouncycastle classes to the source tree (not changing the package, though) to be able to modify them sufficiently to work under J2ME and to minimize dependencies to save space. One option is therefore to get the latest OpenUAT source and use the Bouncycastle classes included with it. The other is to download the latest Bouncycastle source and do the required modifications.

Step 1: creating a public/private key pair for the new certificate

Creating a new key pair for the certificate is quite straight-forward with both JCE and BC:


 


            KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
            keyGen.initialize(1024, sr);
            KeyPair keypair = keyGen.generateKeyPair();
            privKey = keypair.getPrivate();
            pubKey = keypair.getPublic();


 


creates the key pair using JCE, while


 


            RSAKeyPairGenerator gen = new RSAKeyPairGenerator();
            gen.init(new RSAKeyGenerationParameters(BigInteger.valueOf(3), sr, 1024, 80));
            AsymmetricCipherKeyPair keypair = gen.generateKeyPair();
            RSAKeyParameters publicKey = (RSAKeyParameters) keypair.getPublic();
            RSAPrivateCrtKeyParameters privateKey = (RSAPrivateCrtKeyParameters) keypair.getPrivate();
            // used to get proper encoding for the certificate
            RSAPublicKeyStructure pkStruct = new RSAPublicKeyStructure(publicKey.getModulus(), publicKey.getExponent());
            // JCE format needed for the certificate - because getEncoded() is necessary...
            pubKey = KeyFactory.getInstance("RSA").generatePublic(
                    new RSAPublicKeySpec(publicKey.getModulus(), publicKey.getExponent()));
            // and this one for the KeyStore
            privKey = KeyFactory.getInstance("RSA").generatePrivate(
                    new RSAPrivateCrtKeySpec(publicKey.getModulus(), publicKey.getExponent(),
                            privateKey.getExponent(), privateKey.getP(), privateKey.getQ(),
                            privateKey.getDP(), privateKey.getDQ(), privateKey.getQInv()));


 


does with BC. Please note that, at the moment, additional code is there to convert the BC key representation to the JCE representation to create the certificate structure and for exporting into PKCS12. I hope to solve these two issues without the help of JCE soon and thus get rid of the conversion lines.

Step 2: creating the new certificate structure

Now, having available the new public key, it can be put into a new X.509 certificate structure. BC actually provides the X509v3CertificateGenerator utility class for this task, but it relies heavily on the JCE infrastructure. Therefore, I am duplicating some of its code, but using only the BC API wherever possible and thus removing dependencies on JCE classes.


 


        Calendar expiry = Calendar.getInstance();
        expiry.add(Calendar.DAY_OF_YEAR, validityDays);
 
        X509Name x509Name = new X509Name("CN=" + dn);

        V3TBSCertificateGenerator certGen = new V3TBSCertificateGenerator();
        certGen.setSerialNumber(new DERInteger(BigInteger.valueOf(System.currentTimeMillis())));
        certGen.setIssuer(PrincipalUtil.getSubjectX509Principal(caCert));
        certGen.setSubject(x509Name);
        DERObjectIdentifier sigOID = X509Util.getAlgorithmOID("SHA1WithRSAEncryption");
        AlgorithmIdentifier sigAlgId = new AlgorithmIdentifier(sigOID, new DERNull());
        certGen.setSignature(sigAlgId);
        certGen.setSubjectPublicKeyInfo(new SubjectPublicKeyInfo((ASN1Sequence)new ASN1InputStream(
                new ByteArrayInputStream(pubKey.getEncoded())).readObject()));
        certGen.setStartDate(new Time(new Date(System.currentTimeMillis())));
        certGen.setEndDate(new Time(expiry.getTime()));
        TBSCertificateStructure tbsCert = certGen.generateTBSCertificate();


 


There are a few rather tricky bits in this code snippet:

 

  • The issuer name is important to get right! If the string is not bit-for-bit correct, verification of the certificate chain will fail later on. I made an earlier error of setting the issuer to new X509Name(caCert.getSubjectDN().getName()), but this provided an incorrect value in the certificate. The PrincipalUtil class is able to produce the correct name.
  • The object identifier describing the type of the following signature is hard-coded here and needs to match the signing code below.
  • It is also quite hard to get the encoding of the public key within the certificate correct. At first, I tried with

        certGen.setSubjectPublicKeyInfo(new SubjectPublicKeyInfo(sigAlgId, pkStruct.toASN1Object()));

    but this was unreadable by openssl. I have yet to find out why only the getEncoded() method of the JCE version of the public key class produces the correct encoding, or, phrased differently, what the correct encoding is.
  • The subject name can be set to a complete X.509 name (e.g. "O=My organization, OE=My organizational unit, C=AT, CN=Rene Mayrhofer/EMAIL=my@nowhere.at"), but I chose to use only the common name (CN) part of it. Who is using the X.500 structure anyway? I am ok with identifying certificates only be a single name.

Step 3: loading the CA private key and certificate

We assume the complete CA, consisting of its self-signed certificate and the associated private key, to be contained in a PKCS12 file. It can be loaded using the JCE KeyStore class:


 


        KeyStore caKs = KeyStore.getInstance("PKCS12");
        caKs.load(new FileInputStream(new File(caFile)), caPassword.toCharArray());
       
        // load the key entry from the keystore
        Key key = caKs.getKey(caAlias, caPassword.toCharArray());
        if (key == null) {
            throw new RuntimeException("Got null key from keystore!");
        }
        RSAPrivateCrtKey privKey = (RSAPrivateCrtKey) key;
        caPrivateKey = new RSAPrivateCrtKeyParameters(privKey.getModulus(), privKey.getPublicExponent(), privKey.getPrivateExponent(),
                privKey.getPrimeP(), privKey.getPrimeQ(), privKey.getPrimeExponentP(), privKey.getPrimeExponentQ(), privKey.getCrtCoefficient());
        // and get the certificate
        caCert = (X509Certificate) caKs.getCertificate(caAlias);
        if (caCert == null) {
            throw new RuntimeException("Got null cert from keystore!");
        }
        caCert.verify(caCert.getPublicKey());


 


I have yet to find a way to do it without using JCE classes.


 

Step 4: signing the certificate

Signing the created certificate structure with the CA key also turned out to be surprisingly tricky due to the involved block encoding:


 


        SHA1Digest digester = new SHA1Digest();
        AsymmetricBlockCipher rsa = new PKCS1Encoding(new RSAEngine());
        ByteArrayOutputStream   bOut = new ByteArrayOutputStream();
        DEROutputStream         dOut = new DEROutputStream(bOut);
        dOut.writeObject(tbsCert);
        byte[] signature;
        byte[] certBlock = bOut.toByteArray();
        // first create digest
        digester.update(certBlock, 0, certBlock.length);
        byte[] hash = new byte[digester.getDigestSize()];
        digester.doFinal(hash, 0);
        // and sign that
        rsa.init(true, caPrivateKey);
        DigestInfo dInfo = new DigestInfo( new AlgorithmIdentifier(X509ObjectIdentifiers.id_SHA1, null), hash);
        byte[] digest = dInfo.getEncoded(ASN1Encodable.DER);
        signature = rsa.processBlock(digest, 0, digest.length);

        v.add(tbsCert);
        v.add(sigAlgId);
        v.add(new DERBitString(signature));


 


As can be seen, the use of SHA1 and RSA is hard-coded in this block to match the signature id defined in the certificate. The tricky parts here are to use PKCS1 encoding of the RSA signature and ASN1 DER encoding of the digest before signing it. Once reading the responsible code in the BC JCE provider implementation, it's easy, but without that....


 

Step 5: writing the certificate as PKCS12 file

In the last step, the in-memory Java objects need to be written to a file so that it can be imported on other machine or just into different software packages.


 


        X509CertificateObject clientCert = new X509CertificateObject(new X509CertificateStructure(new DERSequence(v)));
        clientCert.verify(caCert.getPublicKey());

        PKCS12BagAttributeCarrier bagCert = clientCert;
        bagCert.setBagAttribute(PKCSObjectIdentifiers.pkcs_9_at_friendlyName,
                new DERBMPString("My frindly name for the new certificate"));
        bagCert.setBagAttribute(
                PKCSObjectIdentifiers.pkcs_9_at_localKeyId,
                new SubjectKeyIdentifierStructure(pubKey));

        KeyStore store = KeyStore.getInstance("PKCS12");
        store.load(null, null);

        X509Certificate[] chain = new X509Certificate[2];
        // first the client, then the CA certificate
        chain[0] = clientCert;
        chain[1] = caCert;
       
        store.setKeyEntry("My friendly name for the new private key", privKey, exportPassword.toCharArray(), chain);

        FileOutputStream fOut = new FileOutputStream(exportFile);
        store.store(fOut, exportPassword.toCharArray());


 


This code snippet again heavily relies on JCE code in its current implementation, and I need to find a way to replace that. It does not seem to tricky, the only catch is to set the localKeyId attribute so that the importing code can associate the certificate and the private key with each other.

If anybody knows how to read and write PKCS12 files without using JCE code and how to properly encode the public key in the certificate with BC, then please drop me a line.


 

Complete code

The complete Java class implementing the creating of X.509 certificates can be found here. It implements both the JCE and the BC methods, because JCE providers are often faster than BC due to the use of native code. All usual rules of the GPL apply, and I would certainly appreciate it if you let me know of any extensions, improvements or bug fixes so that I can update my implementation when somebody works with it.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值