7.9 PKIX support
-
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 initca <locationROOT> (<locationCA>|<keygen/.pub>) <subject> <yyyyMMdd> <yyyyMMdd> <OcspDomainOfRoot>
Use ROOTCA certificate to sign a CA certificate, for example:
java -jar limax.jar pkix initca "file:ca@/work/pkix/root" "pkcs12:/work/pkix/ca/ca0.p12#ec/256" "dc=ca,dc=limax-project,dc=org" "20150101" "20200101" "root.limax-project.org"
Use the above signed ROOTCA certificate to sign the CA certificate with "dc=ca,dc=limax-project,dc=org" as subject.
Here the locationCA uses ec/256 algorithm. The default algorithm parameters are allowed, and the algorithm parameters of ROOTCA are directly inherited in default case. When using ROOTCA, such description "file:ca@/work/pkix/root#rsa/1024/512" can be used. Because the certificate has been signed, the rsa/1024 has no meaning and is ignored. Here 512 specify the length of the signature, which override the 256 length used when the CA certificate is signed.
"root.limax-project.org" specifies the domain name of OcspServer corresponding to ROOTCA. The certificate signing method uses the OCSP service information derived from this domain and CRL distribution point information to fill the certificate. The PKIX application system needs to access this URL to obtain the certificate status.
-
java -jar limax.jar pkix initocsp <location> <locationOcsp> <subject> <yyyyMMdd> <yyyyMMdd>
Sign an OCSP service dedicated certificate, usually the location here is locationROOT. The ROOTCA is planned as offline access, and a running associated OcspServer is needed, to provide subordinate CA status. This certificate is provided to the OcspServer used to sign the response.
-
java -jar limax.jar pkix gencrl <location> <crlfile> <nextUpdate(yyyyMMdd)> [[-](CertDir|CertFile)]
Sign the CRL, usually the location here is locationROOT. The ROOTCA is planned as offline access, and the related CRL of subordinate CA of the ROOTCA must be generated offline and then provides the download accordingly.
nextUpdate, indicates the expected time for next CRL update.
CertDir|CertFile, when the parameter is absent, if the crlfile does not exist, generate a crlfile containing the blank list; if exists, update the nextUpdate information of the crlfile.
CertFile, can be the X509 certificate format, also can be the PKCS7 format. All the certificates signed by CA assigned by the location are extracted and revoked.
CertDir, the only one level directory is scanned, and all the internal CertFile are scanned and recovered., the only one layer directory is scanned, and all the internal CertFile are scanned and revoked.
If CertFile or CertDir is prefixed with "-", the recall operation is indicated to execute, and the corresponding certificate is removed from the CRL list.
-
java -jar limax.jar pkix ca [path to caserver.xml]
Run the CA server according to the configuration of the caserver.xml. Please refer the following for the details.
-
java -jar limax.jar pkix ocsp [path to ocspserver.xml]
Independently run the OcspServer according to the configuration of the ocspserver.xml, which usually is provided to the ROOTCA to use. Please refer the following for the details.
-
-
7.9.5 CAServer
Refer the caserver.xml for the details.
-
CAServer top level element
<CAServer archive="/work/pkix/ca/certs" authCode="123456" domain="ca.limax-project.org"> ...... </CAServer>
3 attributes:
domain：specify the server domain name run by this CAServer. The OCSP service information of all the certificated issued by this CAServer, and CRL distribution point information are all derived from this domain.
archive：the archive directory for all the certificated issued by this CAServer, including the certificates issued in the Renew process. The files in the directory are named with "certSerialNumer".cer way, and the certSerialNumber is the certificate serial number and the file format is DER.
authCode：authorization code seed, in actual operation, this attribute should not be written and should be entered during the server launching. This seed is used to generate the TOTP authorization code program. When signing the certificate, the authorization code generated by this program is used through filling in the authorization code field in the certificate service page.
When CAServer runs, the authcode.jar will be generated in the current directory. If it needs to fill the authorization code, this program can be executed by java –jar authcode.jar.
In this window, enter the authorization code seed provided by CAServer which is running this time, and then press Enter to switch to the below page.
Click the authCode button in this window, the generated TOTP key will be generated to the system clipboard, directly paste to the corresponding page.
Note: each time, when launching the CAServer, the new authcode.jar is generated, and the previous one is invalid, even if the same authorization code seed is used.
-
CAService element
<CAService location="pkcs12:/work/pkix/ca/ca0.p12" passphrase="123456"/>
2 attributes:
location：the location of the private key and certificate chain issued by the ROOTCA for CA.
passphrase：the password to enable the private key of the location. In actual operation, this attribute should not be used and should be entered when server launches.
Multiple CAService elements are allowed. All the CA certificated pointed to by location must have the same Subject with different validity period. When the overall elements will expire (which is determined by the expiration time of the last expired CA certificate minus the maximum validity period of certificate issud by this CAServer), the application should request new CA from ROOTCA and add the configuration. The expired CA can be deleted from the configuration.
-
CertServer element
<CertServer port="8080" publicKeyAlgorithmForGeneratePKCS12="rsa/1024"> ...... </CertServer>
2 attributes:
port：the HTTP service of the CertServer running on the port 8080. The CertServer service is bound on the localhost interface.
publicKeyAlgorithmForGeneratePKCS12：CAServer supports CertServer to generate the private key, and package into the PKCS12 file to send to the applicant. This attributes configus the private key pair generation algorithm.
CertServer internal element, corresponding to the configuration options of the page elements, can be adjusted according to the detailed requirement.
In particular, the subject input must be the legal X500 Distinguished Name. If there is a further convention, the pattern related properties of the Subject element can be configured, using the pattern supported by java.util.regex.Pattern, and verifying the legality of the Subject. The template property provides initialization template of the subject field, and simplify the page input.
The NotAfter parameter is the period serial attributes and the unit is day.
The mandatory attribute within the other elements specifies whether the corresponding page element is disabled.
The illegal input is prompted in the corresponding position with a red box.
Access http://localhost:8080/ and enter the below web page:
This page uses the public key provided by the applicant (the .pub file generated by java –jar limax.jar genkey) to generate the .p7b certificate chain file.
Click the publicKey and the page is switched to:
Generate the private key by CAServer, and export the .p12 file. Here the specified PKCS12Passphrase (at least 6 characeters) must choose the independent channel available to the applicant.
This page is used to revoke the certificate, and the input content can be the independent certificate file, or the previous signed .p7b file.
This page is used to undo the revoke, and the input content is same as the above.
-