/xipki

Highly scalable and high-performance open source PKI (CA and OCSP responder). Minimal dependencies.

Primary LanguageJavaApache License 2.0Apache-2.0

GitHub release License Github forks Github stars SourceSpy Dashboard

XiPKI

XiPKI (eXtensible sImple Public Key Infrastructure) is a highly scalable and high-performance open source PKI (CA and OCSP responder).

License

  • The Apache Software License, Version 2.0

Support

Just create issue or new discussion.

For bug-report please upload the testdata and log files, describe the version of XiPKI, OS and JRE/JDK, and the steps to reproduce the bug.

Prerequisite

  • OS: Linux, Windows, MacOS
  • JRE / JDK 8 (build 162+), 11, 17
  • Database: DB2, MariaDB, MySQL, Oracle, PostgreSQL, H2, HSQLDB
  • Hardware: Any available hardware (tested on Raspberry Pi 2 Model B with 900MHz quad-core ARM CPU and 1 GB Memory)

Tested PKCS#11 Devices

Performance

Test Settings

  • OS: Ubuntu 20.04, X86_64
  • CPU: Intel Core i3-7100U CPU @ 2.40GHz, 4 Core
  • Disk: SanDisk SD8SN8U (SSD)
  • Memory: 8GB
  • Cryptograhic Token: PKCS#12 keystore
  • Database: PostgreSQL 9.5
  • Database, CA server, OCSP server and test clients on the same machine.
  • Server: Apache Tomcat/8.5.34
  • Server JDK: 11.0.11+9-Ubuntu-0ubuntu2.20.04
  • Test Client: XiPKI QA, tested with 5 threads for 60 seconds.

CA

  • PostgreSQL is tuned by setting shared_buffers = 2GB and commit_delay = 1000.
  • Certificate Enrollment
Key type Key size / Curve Certificates per second
RSA 2048 630
3072 300
4096 150
DSA 2048 580
3072 330
EC NIST P-256 880
NIST P-384 700
NIST P-521 530
Brainpool P256R1 560
Brainpool P384R1 350
Brainpool P512R1 210
SM2 SM2P256V1 800
EdDSA Ed25519 1,200
Ed448 900

OCSP

  • Default PostgreSQL configuration
  • OCSP Cache Disabled
Key type Key size / Curve Responses per second
RSA 2048 880
3072 350
4096 160
DSA 2048 2,000
3072 1,000
EC NIST P-256 3,600
NIST P-384 2,400
NIST P-521 1,400
Brainpool P256R1 1,500
Brainpool P384R1 850
Brainpool P512R1 500
SM2 SM2P256V1 4,000
EdDSA Ed25519 5,000
Ed448 3,300
  • OCSP Cache enabled
    • If the OCSP requests contain nonce: same as without cache (see above).
    • Otherwise, (much) better than without cache.

Get Started

JAVA_HOME

Set the environment variable JAVA_HOME to point to root directory of the to the JRE/JDK installation.

Binaries

Download the binaries xipki-ca-<version>.zip, xipki-ocsp-<version>.zip and xipki-cli-<version>.tar.gz (or xipki-cli-<version>-jdk8.tar.gz for JDK 8) from releases.

Only if you want to use the development version, build it from source code as follows.

  • Get a copy of project code

    git clone https://github.com/xipki/xipki

  • Build the project

    In folder xipki

    mvn clean install -DskipTests

    Then you will find the following binaries:

    • DB Tool: assemblies/xipki-dbtool/target/xipki-dbtool-<version>.zip
    • CA: assemblies/xipki-ca/target/xipki-ca-<version>.zip
    • OCSP: assemblies/xipki-ocsp/target/xipki-ocsp-<version>.zip
    • CLI (Command Line Interface): assemblies/xipki-cli/target/xipki-cli-<version>.tar.gz (or xipki-cli-<version>-jdk8.tar.gz for JDK 8)

Install DB Tool

  1. Unpack the binary xipki-dbtool-<version>.zip.
  2. If you use database other than PostgreSQL, MariaDB and MySQL, you need to get the JDBC driver and copy it to the directory lib/jdbc.

Install CA Server

  1. Unpack the binary xipki-ca-<version>.zip and install CA as described in the unpacked README file.

Install OCSP Responder

Note that CA and OCSP can be installed in the same servlet container.

  1. Unpack the binary xipki-ocsp-<version>.zip and install OCSP responder as described in the unpacked README file.

Install Command Line Interface

  1. Unpack the binary xipki-cli-<version>.tar.gz (or xipki-cli-<version>-jdk8.tar.gz for JDK 8)
  2. Adapt the CMP client configuration xipki/cmpclient/cmpclient.json
  3. If you get "java.lang.ClassNotFoundException: <jdbc class>", please copy the missing JDBC driver jar to the directory lib/ext.

Configure PKCS#11 device (optional)

This step is only required if the real PKCS#11 device instead of the emulator is used. Note that this step should be applied to both tomcat and xipki-cli.

  • Copy xipki/security/example/pkcs11-hsm.json to xipki/security/pkcs11.json, and adapt the PKCS#11 configuration.

Configure how to handle SSL client certificate (optional)

This step is only required if the CA is behind a reverse proxy apache httpd.

  • Add the java property org.xipki.reverseproxy.mode

    -Dorg.xipki.reverseproxy.mode=APACHE

  • configure the proxy to forward the headers via mod_proxy with the following configuration

# Require SSL Client verification
SSLVerifyClient		require

#initialize the special headers to a blank value to avoid http header forgeries 
RequestHeader set SSL_CLIENT_VERIFY  "" 
RequestHeader set SSL_CLIENT_CERT  "" 

<Location / >
 RequestHeader set SSL_CLIENT_VERIFY "%{SSL_CLIENT_VERIFY}s"
 RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
 ...
</Location>

For more details please refer to * Jetty/Howto/Configure mod proxy * Jetty: Tricks to do client certificate authentications behind a reverse proxy * Apache Module mod_ssl

Setup CA Server

  1. Start the servlet container
    HSM devices of Thales, e.g. nCipher, can use Thales preload to manage the PKCS#11 sessions. In this case, the servlet container should be started as follows
preload <start script>
  1. Setup CA in CLI

    • (If error like "Identity or Certificate with label=mylabel already exists" occurs, you need to comment the line which generate the key (e.g. dsa-p11 ec-p11, rsa-p11, sm2-p12) or delete the existing key using command delete-key-p11).

    • Start CLI.

      bin/karaf

      HSM devices of Thales, e.g. nCipher, can use Thales preload to manage the PKCS#11 sessions. In this case, the cli should be started as follows

      preload bin/karaf

    • Setup CA (choose p11 if the key is saved in PKCS#11 device, p12 in PKCS#12 device.

      • In case of using new keys and certificates, in CLI:
        source xipki/ca-setup/cacert-none/setup-*-*.script where * is place holder.

      • In case of using existing keys and certificates, in CLI:
        source xipki/ca-setup/cacert-present/setup-*-*.script where * is place holder.

      • If you wish to generate the siging key and certificate for the OCSP responder, in CLI:
        source xipki/ca-setup/setup-ocsp-*.script.

      • If you wish to add the SCEP support, in CLI:
        source xipki/ca-setup/setup-scep.script.

    • Verify the installation, execute the command in CLI:
      ca-info myca1

Enroll/Revoke Certificate and Get CRL via Shell (optional)

  • The following shell script demonstrates how to enroll and revoke certificates, and how to get the current CRL:
    <CLI_ROOT>/xipki/client-script/rest.sh (use argument 'help' to print the usage)

    Note that this script tells CA to generate real certificates. DO NOT use it in the production environment.

Enroll/Revoke Certificate

  • SCEP
    Using any SCEP client. XiPKI provides also a SCEP client.

    The binary xipki-cli-<version>.tar.gz (or xipki-cli-<version>-jdk8.tar.gz for JDK 8) contains an example script in the folder xipki/client-script. It can be executed in the CLI as follows:

    • source xipki/client-script/scep-client.script

  • XiPKI CLI XiPKI CLI provides commands to enroll and revoke certificates via CMP.

    The binary xipki-cli-<version>.tar.gz (or xipki-cli-<version>-jdk8.tar.gz for JDK 8) contains an example script in the folder xipki/client-script. It can be executed in the CLI as follows:

    • source xipki/client-script/cmp-client.script (use argument 'help' to print the usage)

  • REST API
    The shell script xipki/client-script/rest.sh of the xipki-cli demonstrates the use of REST API.

    The binary xipki-cli-<version>.tar.gz (or xipki-cli-<version>-jdk8.tar.gz for JDK 8) contains an example script in the folder xipki/client-script. It can be executed in the CLI as follows:

    • source xipki/client-script/rest-client.script (use argument 'help' to print the usage)

CLI Commands

Please refer to commands.md for more details.

Docker container

See discussion in discussion #205.

Features

  • CA (Certification Authority)

    • X.509 Certificate v3 (RFC 5280)
    • X.509 CRL v2 (RFC 5280)
    • EdDSA Certificates (RFC 8410, RFC 8032)
    • SHAKE Certificates (RFC 8692)
    • Diffie-Hellman Proof-of-Possession Algorithms (RFC 6955)
    • SCEP (draft-gutmann-scep-00, draft-nourse-scep-23)
    • EN 319 411 (eIDAS)
    • EN 319 412 (eIDAS)
    • Supported databases: DB2, MariaDB, MySQL, Oracle, PostgreSQL, H2, HSQLDB
    • Direct and indirect CRL
    • FullCRL and DeltaCRL
    • Customized extension to embed certificates in CRL
    • CMP (RFC 4210 and RFC 4211)
    • API to specify customized certificate profiles
    • Support of JSON-based certificate profile
    • API to specify customized publisher, e.g. for LDAP and OCSP responder
    • Support of publisher for OCSP responder
    • Public key types of certificates
      • RSA
      • EC
      • DSA
      • Ed25519, Ed448
      • SM2
      • X25519, X448
    • Signature algorithms of certificates
      • Ed25519, Ed448
      • SHAKE128withRSAPSS, SHAKE256withRSAPSS,
      • SHA3-*withRSA: where * is 224, 256, 384 and 512
      • SHA3-*withRSAandMGF1: where * is 224, 256, 384 and 512
      • SHA3-*withECDSA: where * is 224, 256, 384 and 512
      • SHA3-*withDSA: where * is 224, 256, 384 and 512
      • SHAKE128withECDSA, SHAKE256withECDSA,
      • SHA*withRSA: where * is 1, 224, 256, 384 and 512
      • SHA*withRSAandMGF1: where * is 1, 224, 256, 384 and 512
      • SHA*withECDSA: where * is 1, 224, 256, 384 and 512
      • SHA*withPlainECDSA: where * is 1, 224, 256, 384 and 512
      • SHA*withDSA: where * is 1, 224, 256, 384 and 512
      • SM3withSM2

  • Native support of X.509 extensions (other extensions can be supported by configuring it as blob)

    • AdditionalInformation (German national standard CommonPKI)
    • Admission (German national standard CommonPKI)
    • AuthorityInformationAccess (RFC 5280)
    • AuthorityKeyIdentifier (RFC 5280)
    • BasicConstraints (RFC 5280)
    • BiometricInfo (RFC 3739)
    • CertificatePolicies (RFC 5280)
    • CRLDistributionPoints (RFC 5280)
    • CT Precertificate SCTs (RFC 6962)
    • ExtendedKeyUsage (RFC 5280)
    • FreshestCRL (RFC 5280)
    • GM/T 0015 ICRegistrationNumber (企业工商注册号, Chinese Standard GM/T 0015-2012)
    • GM/T 0015 IdentityCode (个人身份标识码, Chinese Standard GM/T 0015-2012)
    • GM/T 0015 InsuranceNumber (个人社会保险号, Chinese Standard GM/T 0015-2012)
    • GM/T 0015 OrganizationCode (企业组织机构代码, Chinese Standard GM/T 0015-2012)
    • GM/T 0015 TaxationNumber (企业税号, Chinese Standard GM/T 0015-2012)
    • InhibitAnyPolicy (RFC 5280)
    • IssuerAltName (RFC 5280)
    • KeyUsage (RFC 5280)
    • NameConstraints (RFC 5280)
    • OcspNoCheck (RFC 6960)
    • PolicyConstrains (RFC 5280)
    • PolicyMappings (RFC 5280)
    • PrivateKeyUsagePeriod (RFC 5280)
    • QCStatements (RFC 3739, eIDAS standard EN 319 412)
    • Restriction (German national standard CommonPKI)
    • SMIMECapabilities (RFC 4262)
    • SubjectAltName (RFC 5280)
    • SubjectDirectoryAttributes (RFC 3739)
    • SubjectInfoAccess (RFC 5280)
    • SubjectKeyIdentifier (RFC 5280)
    • TLSFeature (RFC 7633)
    • ValidityModel (German national standard CommonPKI)

  • Management of multiple CAs in one software instance

  • Support of database cluster

  • Multiple software instances (all can be in active mode) for the same CA

  • Native support of management of CA via embedded OSGi commands

  • API to manage CA. This allows one to implement proprietary CLI, e.g. Website, to manage CA.

  • Database tool (export and import CA database) simplifies the switch of databases, upgrade of XiPKi and switch from other CA system to XiPKI CA

  • All configuration of CA except those of databases is saved in database

  • OCSP Responder

    • OCSP Responder (RFC 2560 and RFC 6960)
    • Support of Common PKI 2.0
    • Management of multiple certificate status sources
    • Support of certificate status source based on the database of XiPKI CA
    • Support of certificate status source based on the OCSP database published by XiPKI CA
    • Support of certificate status source CRL and DeltaCRL
    • Support of certificate status source published by EJBCA
    • API to support proprietary certificate sources
    • Support of both unsigned and signed OCSP requests
    • Multiple software instances (all can be in active mode) for the same OCSP signer and certificate status sources.
    • Supported databases: DB2, MariaDB, MySQL, Oracle, PostgreSQL, H2, HSQLDB
    • Database tool (export and import OCSP database) simplifies the switch of databases, upgrade of XiPKi and switch from other OCSP system to XiPKI OCSP.
    • High performance
    • Support of health check

  • SCEP

    • Supported SCEP versions
      • draft-gutmann-scep-00
      • draft-nourse-scep-23

  • CLI

    • Configurating CA
    • Client to enroll, revoke, unrevoke and remove certificates, to generate and download CRLs
    • Client to send OCSP request
    • Generating keypairs of RSA, EC and DSA in token
    • Deleting keypairs and certificates from token
    • Updating certificates in token
    • Generating CSR (PKCS#10 request)
    • Exporting certificate from token
    • High performance
    • Support of health check

  • For CA, OCSP Responder, and CLI

    • Support of PKCS#12 and JCEKS keystore
    • Support of PKCS#11 devices, e.g. HSM
    • API to use customized key types, e.g. smartcard
    • API to resolve password
    • Support of PBE (password based encryption) password resolver
      • All passwords can be encrypted by the master password
    • Support of OBF (as in jetty) password resolver

Use OCSP with customized Certificate Status Source (OcspStore)

  • See the example modules
    • ocsp-store-example: implementation of a customized OcspStore.
    • ocsp-store-example-assembly: assembly the binaries.