7.9 PKIX support
In order to establish a trust relationship across servers, across projects and across organizations, the Limax integrates the PKIX module to provide the ability to create CA, sign and revoke the X509 certificates, and provide the basic support for the inter-system security interoperability. At the same time, the Limax provides the convenient management tool and maximum simplifies the CA system management burden on the basis of ensuring the security.
Cerficates and CRL related concepts can refer to RFC5280, http://www.ietf.org/rfc/rfc5280.txt
OCSP service related concepts can refer to RFC2560, http://www.ietf.org/rfc/rfc2560.txt
-
7.9.1 Design principles
-
The ROOTCA offline management, uses command line tool to operate to avoid the network security risks.
-
The CA service is implemented as netwok service, and integrates 3 servers.
1. Signing and recycling certificates uses the near-line mode and is implementes as the HTTP service, which is bound on the localhost:8080 interface of server. If the remote operation is required, the reverse proxy must be set up and all operations must provide the authorization code through the TOTP way to minimize unauthorized access.
2. Provide the Renew service through the HTTPS way, and allow signing the short-term certificates. When the certificate exceeds the 80% of life, the Renew request is issued to the server and the certificate is replaced. Using the short-term certificate can effectively reduce the length of the revoke list and reduce the burden of the revoke management. Once the certificate is no longer used, quick expiration decreases the risk of malversation and reduces the management burden.
3. Provide the OCSP service through the HTTP way, and automatically publish the CRL at the same time.
-
CA has the expiration problem, so the appropriate solution is provided to ensure that new certificate of Renew is signed by the new CA to avoid the re-application offline.
-
By re-interpreting the certificate policy, name the namespace with CPS, and provide the basic support for the interoperation between the multiple ROOTCA.
-
Allow using the smart card device which supports the PKCS11 to provide further protection for Key security.
-
Application-side module, automatically maintains the private key and certificate chain, executes the Renew operation, hides the complexity of implementation and provides the simple interface to simplify the development.
-
-
7.9.2 Location
Location corresponds to java.security.KeyStore.PrivateKeyEntry, which is the basis for using the specified private key and its certificate chain.
Location is described in opague URL way, scheme:[alias@]path[#algorithm].
-
scheme
The supported schemes are FILE, PKCS11, PKCS12, JKS and JCEKS. The storage location of private key and certificate chain is appointed.
-
alias
Alias has the same meanging as the alias defined by KeyStore. A container with private key and certificate chains allows storing multiple private keys and certificate chains, with the alias as the index. Except that FILE and PKCS11 do not allow the default alias, the other scheme can be default, and find the first alias through KeyStore.aliases() method in the default case as implicit alias.
Note: JDK has no clear norms on the alias management and the implement is very confusing. For example, PKCS12 can use empty string alias, but javax.net.ssl.KeyManagerFactory can not search this alias, so the behavior is inconsistent with JKS and JCEKS. Similarly, the KeyStore of PKCS11 can search this alias by KeyStore.aliases(), but fails by KeyStore.loadKey(). So, try to avoid the default alias.
-
path
Path is a file system path, and has different interpretation under different scheme.
1. The private key and certificate chain are separately stored as .key file and .p7b file in the FILE case. The path is a directory name. For example, "file:abc@/work", specifies the private file /work/abc.key and certificate chain file /work/abc.p7b.
-
2. The path specifies the pkcs11 configuration file in the PKCS11 case. For example, for epass2003 such a TOKEN supporting PKCS11, PKCS11 driver can be found and configuration file can be created.
/work/epass2003-pkcs11.cfg: name = epass2003 library = c:/work/eps2003csp11.dll
Then, "abc@/work/epass2003-pkcs11.cfg" such a location, indicates the private key and certificate chain corresponding to the abc alias in the pkcs11 container.
3. In the PKCS12, JKS and JCEKS cases, the path is the path corresponding to the KeyStore file. For example, "pkcs12:/work/client.p12" indicates using the private key and certificate chain corresponding to the first alias in the client.p12 file. In particular, because CA can issue the PKCS12 private key certificate package, such a certificate package only places a pair of private key and certificate chain. Such a certificate package default uses empty string alias, and only in this case, using default alias is reasonable.
-
algorithm
Certificate related algorithm, constructed as PublicKeyAlgorithm/PublicKeyLength[/SignatureLength].
PublicKeyAlgorithm, the preferred value is RSA, DSA and EC.
PublicKeyLength, corresponds to the relative algorithm.
SignatureLength, the preferred value is 256, 384 and 512.
Except for initializing ROOTCA and issuing CA certificate, the algorighm can almost all be absent, and the next command line operations will be detailed introduced.
-
-
7.9.3 Development tools
The limax.pkix package provides the Key management tools, certificate service development tools and certificate service client-side tools.
-
Key management tools
limax.pkix.KeyInfo
The basis of all the relevant tools, explains the Location, gets and saves the corresponding private key and certificate chain, while providing the update support to private key and certificate chain. The update process ensures transaction integrity. In the PKCS11 case, there is a little security reduction. The updated private key and certificate chain will first be temporarily stored to the local storage (the private key is encrypted by the password provided when activating), then execute a copy process, and finally delete the local temporary data. In other scheme cases, it must ensure that the position pointed to by Location is writable. In addition, it directly supports to create SSLContext on the basis of KeyInfo.
-
Certificate service development tools
limax.pkix.CAService
By implementing the X509*Parameter series interfaces, describes the ROOTCA certificate, CA certificate, EndEntity certificate, CRL request and Renew request, and performs the corresponding signing operation.
The CAService with the same Subject allows for a combination, and signs the new certificate with CA certificate with the latest expiration time; signs the CRL issued by the CA with revoked certificate. This way ensures the provision of sustainable services.
-
Certificate service client-side tools
limax.pkix.SSLContextAllocator
Uses the private key and certificate chain specified by Location, and assignes the corresponding SSLContext to application for further development. In the short connection application case, the obtained SSLContext can be directly used each time. In the long connection case, a Listener can be registered to obtain the renew message, and timely replace the new SSLContext.
-
-
7.9.4 Management command
The limax.pkix.tool package provides the implementation of the pkix related management tools. There are total 9 commands. The following commands, if it involves the private key access, will be prompted to enter the password of the private key. If it involves the private key creation, it will confirm the creation password of private key twice.
-
java -jar limax.jar pkix algo
Display the supported algorithm list.
-
java -jar limax.jar pkix keygen <algo> <PathPrefix>
There are two ways to request a certificate signature: the first is that the client generates the private key, submits the public key to CA, signs the certificate, and generates the certificate chain; the second is that the CA directly generates the public key and private key pair, signs the certificate, and packages the private key and certificate chain as PKCS12. For the first way, the private key does not be transmitted on the network, with higher security. This command provides the support for the first way.
For example, execute java –jar limax.jar pkix keygen "rsa/1024" "/work/client" to genereate the private key file /work/client.key, and public key file /work/client.pub. Submit the client.pub to CA to sign the certificate. In this case, the CA sends back a .p7b certificate chain file. This file can be named as client.p7b and placed in the /work directory and used through Location:"file:client@/work".
-
java -jar limax.jar pkix copy <locationSRC> <locationDST>
Location conversion tool, performes copy between scheme, and may cover the alias item in the container corresponding to locationDST.
For example, java –jar limax.jar pkix copy "file:client@/work" "pkcs12:client@/work/client.p12" command converts the private key and certificate chain described by file way to PKCS12 way.
Note: the PKCS11 can not be used as the source of the copy, because the PKCS11 specification requires that the private key can not be exported, such an operation must fail.
-
java -jar limax.jar pkix initroot <locationROOT> <subject> <yyyyMMdd> <yyyyMMdd>
Initiate ROOTCA, for example:
java -jar limax.jar pkix initroot "file:ca@/work/pkix/root#rsa/2048/256" "dc=limax-project,dc=org" "20100101" "20500101"
Sign the self-signed certificate from 2010-01-01 to 2050-01-01 with "dc=limax-project,dc=org" as subject, using the algorithm rsa/2048, 256 bits signature. Here the algorithm parameters can not be absent.
-