# XiPKI is a compact Java PKI with post-quantum algorithms already wired in

> XiPKI is an open source certification authority, registration authority and OCSP responder in about 120,000 lines of Java, with a CA protocol gateway speaking EST, SCEP, CMP and ACME, ML-DSA and ML-KEM support, PKCS#11 hardware security module integration, and a thin distribution under 6 MB. The licence file in the repository is the document to read before you deploy it.

**xipki/xipki** — XiPKI: Compact open source PKI (CA, OCSP responder, certificate protocols ACME, CMP, EST, SCEP), with full support of PQC MLDSA (Dilithium) and MLKEM (Kyber).

- Repository: https://github.com/xipki/xipki
- Stars: 609 · Forks: 133
- Language: Java
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/xipki-xipki

## What the acronym stands for and what the project is

XiPKI expands to eXtensible sImple Public Key Infrastructure, and the README describes it as a high-performance open-source PKI covering CA, RA and OCSP, designed for critical infrastructure. The three roles in that phrase matter. A CA signs certificates, an RA handles the enrolment decisions around them, and an OCSP responder answers revocation status queries, and building the three together is where most of the operational headache in a certificate deployment comes from. The design bet is that a critical infrastructure operator wants all three in one process tree, with one database and one configuration story, rather than assembled from separate products. The code size is quoted at roughly 120,000 lines with minimal dependencies, and the claim is that Bouncy Castle can be switched between its LTS and FIPS variants to meet different compliance requirements, which matters when a regulator asks which cryptographic provider a signature came from. The author also contributes to IETF standardisation and co-authored the C509 specification for CBOR-encoded X.509 certificates along with its test vectors in the COSE Working Group, which is a reasonable signal that the design decisions are being argued in the right room.

## The gateway speaks four enrolment protocols on one port

The CA Protocol Gateway section is the part that makes the project different from a plain CA. It implements EST at RFC 7030, SCEP at RFC 8894, CMP across RFC 4210, 4211, 9045, 9480, 9810 and 9811, and ACME at RFC 8555 with RFC 8737, offering the dns-01, http-01 and tls-apln-01 challenge types, plus a RESTful API of its own. Four protocols is a lot, and it is the one place where a small project is trying to cover a genuinely fragmented set of protocols. A device that enrols over EST is not a device that enrols over SCEP, and neither is a browser talking ACME, so an operator with heterogeneous equipment ends up running a gateway that re-exports one protocol to many. The cost of that coverage is a wider attack surface and a larger test matrix, and the ACME implementation in particular is the piece a modern deployment is most likely to use, so it is worth reading the documentation for it before assuming the other three are equally finished. The custom RESTful API is what the management console and the integrations use, and it is the API you will write against.

## Post-quantum algorithms, and how they are exposed

The post-quantum support is the headline and the part with the most detail. Certificate public key types include the classical set of RSA, EC, Ed25519, Ed448, SM2, X25519 and X448, and then ML-DSA in its three standard parameter sets of ML-DSA-44, 65 and 87, ML-KEM in 512, 768 and 1024, plus composite MLDSA and composite MLKEM entries tied to the in-draft IETF LAMP working group specifications for composite signatures and composite key encapsulation. The signature algorithm list follows the same shape, with MLDSA and composite MLDSA alongside ECDSA over SHA-1, SHA-2, SHA-3 and SHAKE, Ed25519 and Ed448, RSA PKCS1v1.5 over SHA-1, SHA-2 and SHA-3, RSA PSS over SHA-1, SHA-2, SHA-3 and SHAKE, and SM3withSM2 for the Chinese national standards. The composite algorithms are the part to understand, since a composite signature is one that verifies under more than one scheme, which is how a deployment transitions to quantum resistance without a flag day. Two things to note. SM2 and SM3 support means the codebase is written with the Chinese national cryptographic standards in mind, which is not a casual requirement. And the algorithm names are given with their several aliases, ML-DSA and MLDSA and CRYSTALS-Dilithium, and likewise for ML-KEM and CRYSTALS-Kyber, so a configuration file may accept any of them.

## Getting the distribution, from a release or from source

The binary is a tar archive named xipki-setup-<version>.tar.gz, and there are three ways to get it. You can download it from the GitHub releases, you can pull it from the central Maven repository as an assembly artifact, or you can build it yourself. The Maven route is unusual enough to be worth showing, since it means the distribution is a dependency rather than a download.

```xml
    <dependency>
      <groupId>org.xipki.assembly</groupId>
      <artifactId>xipki-setup</artifactId>
      <type>tar.gz</type>
      <version>placeholder-version</version>
    </dependency>
```

For the source route you clone the repository and run the install script in the xipki folder.

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

```sh
        ./install.sh
```

The built binaries then appear in assemblies/xipki-setup/target/. The repository listing shows how the project is decomposed, with a ca-api, ca-mgmt, ca-sdk and ca-server group for the CA side, an ocsp-api and ocsp-server group, a gateway module, a certprofile module, a codec module, a pkcs11 module and a pkcs11test module, a pki-client, an xihsm module for the HSM integration, a servlets group for the web layer, a shells group for the command line tools, and util and util-extra for shared code. A multi-module layout like that in a 120,000 line project is a sign of deliberate separation, and the pkcs11test module in particular suggests the hardware integration is treated as something that has to be provably right rather than best effort.

## The demo runs a CA, an OCSP responder and a gateway on your machine

The Just Try The Demo section is the fastest way to see the whole system working, and it is a good deal more informative than a screenshot. You unpack the archive, then run demo.sh from the unpacked xipki-setup-<version> folder, which prepares the system and starts the XiPKI console. Once it is prepared, you start the console by running the xipki binary in xipki-mgmt-cli/bin/. Inside the console you source the demo script, and the README shows it taking arguments, for example source demo/demo-single.script DB PKCS12 RSA2048, which creates a database-backed CA with a PKCS#12 key and an RSA 2048 key. You can then point a browser at http://localhost:8282 for the H2 database console, with the credentials given in the README. The three JDBC URLs are worth noting because they show the storage model, a separate database for the CA configuration, one for the CA data and one for the OCSP data. The generated keys, certificate requests and certificates land in xipki-mgmt-cli/output, and the CA, OCSP and gateway instances run from the folders ca-tomcat, ocsp-tomcat and gateway-tomcat in the home directory. The Tomcat in those names is the servlet container, and the supported list is Tomcat 10 and 11, which matches the Jakarta EE requirement of the protocol gateway.

## What it will and will not run on

The supported platform list is short and worth reading line by line, because it tells you what the project has been tested against rather than what it might work on. The operating systems are Linux and macOS, which is worth noting on a project that is otherwise portable. The runtime is Java 11 or newer, and the project is built as a Maven project. The database list is long and includes both commercial and open source engines, DB2, MariaDB, MySQL, Oracle and PostgreSQL, plus H2 and HSQLDB for the demo and test setups. The servlet container is Tomcat 10 or 11. The hardware line says any available hardware, which is doing no work, but the HSM list is where the real constraint lives, because the private key is the thing that must be protected. Supported devices include AWS CloudHSM, the Nitrokey HSM 2 and the Smartcard HSM EA+, nCipher Connect and Solo, Sansec, SoftHSM v1 and v2, TASS, Thales LUNA and ProtectServer, and Utimaco. The README adds that it should also work with other HSMs that support PKCS#11, which is the right way to state a boundary, since PKCS#11 is an interface and the conformance varies between vendors. The storage side has one more constraint that is easy to miss: the thin distribution is under 6 MB only without bundled JDBC drivers and Bouncy Castle jars, so a deployment has to bring its own.

## The licence file is the first thing to read

There is a genuine ambiguity here that a careful reader has to resolve rather than assume away. The README badge and the License section both state the Apache Software License, Version 2.0, and the LICENSE file in the repository is presumably the Apache 2.0 text. The project page, on the other hand, shows the licence as a custom one that GitHub cannot classify, and points to the LICENSE file for the actual terms. Those two statements are not necessarily in conflict, since GitHub simply fails to recognise some licence texts, but the practical instruction is the same either way: read the LICENSE file in the repository rather than trusting the badge, and have your own review look at it. There is a further wrinkle in the wider ecosystem. The docker compose file of a comparable Java PKI project, to take one from the same space, carries an SPDX header of GPL-3.0-or-later and a note that additional terms under GPL version 3 section 7 live in a COPYRIGHT file, which shows how often a permissive licence in a component is accompanied by extra terms in a companion file. XiPKI's own COPYING-equivalent file in the repository root is the place to confirm. On maintenance, the project is not archived, the last push was on 2026-10-01, and the recent releases are v6.7.1 from 2026-09-07, v6.7.0 from 2026-03-28 and v6.6.0 from 2026-03-15, so a 6.x line is in active development and the author asks for issues with test data, log files, and the version, OS, JRE and reproduction steps.

## Conclusion

XiPKI suits an infrastructure team that has to run a certification authority for critical systems and wants post-quantum algorithms, a protocol gateway and hardware key protection in one small deployment rather than three products, since the whole thing is a Maven build with a distribution archive under 6 MB. It is the wrong tool for a web application that just needs to issue a certificate for a public website, because the ACME path is one of four gateway protocols rather than the point of the project, and it is the wrong tool if you need a supported product with a vendor behind it, since the project is maintained by its author and asks for issues on GitHub. Before you evaluate it, read the LICENSE file, because the project is listed with a custom licence that GitHub cannot classify, and check the feature list against the algorithms your clients will actually negotiate.

## FAQ

### What protocols does the XiPKI CA Protocol Gateway support?

EST at RFC 7030, SCEP at RFC 8894, CMP across RFC 4210, 4211, 9045, 9480, 9810 and 9811, and ACME at RFC 8555 with RFC 8737 using the dns-01, http-01 and tls-apln-01 challenge types, plus a RESTful API of its own.

### Which post-quantum algorithms does XiPKI support?

ML-DSA in the 44, 65 and 87 parameter sets, ML-KEM in 512, 768 and 1024, and composite versions of both tied to the in-draft IETF LAMP specifications for composite signatures and composite key encapsulation. The traditional RSA, EC, Ed25519, Ed448, SM2, X25519 and X448 key types are supported alongside them.

### What does XiPKI need to run?

Linux or macOS, Java 11 or newer, a database from the list of DB2, MariaDB, MySQL, Oracle, PostgreSQL, H2 and HSQLDB, and a servlet container, Tomcat 10 or 11. Private keys can be held in a PKCS#11 HSM, with listed support for AWS CloudHSM, Nitrokey, nCipher, SoftHSM and others.

## Sources

- [Issues](https://github.com/xipki/xipki/issues)
- [README](https://github.com/xipki/xipki/blob/master/README.md)
- [Releases](https://github.com/xipki/xipki/releases)
- [xipki/xipki on GitHub](https://github.com/xipki/xipki)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xipki-xipki