pkixops-pki

pkixops-pki provides practical PKI lifecycle building blocks: issuing certificate chains, renewing/re-issuing leaf certificates, tracking revocations, and publishing CRLs.

Designed for Java/Spring services that need consistent PKI operations.

Features

Certificate Issuance (Chain)

• Root CA (self-signed)
• Intermediate CA (signed by Root)
• Leaf certificates (signed by Intermediate)
• Extension support:
  • BasicConstraints, KeyUsage, ExtendedKeyUsage
  • Subject Key Identifier (SKI), Authority Key Identifier (AKI)
  • Subject Alternative Name (SAN)

Renewal vs Re-Issue

• Renewal: same identity & profile, typically updated validity period (key rollover recommended)
• Re-Issue: may allow changes (subject, SANs, EKU) and can optionally revoke the previous certificate with a reason

Revocation + Publishing

• Record revocations in a persistent store (example: ~/.pkixops/crls/revoked.json)
• Publish an Intermediate CRL (PEM/DER) using a CRL publisher

Installation (Maven)

<dependency>
      <groupId>com.pkixops</groupId>
      <artifactId>pkixops-pki</artifactId>
      <version>1.7.0</version>
    </dependency>

Issuing a Root / Intermediate / Leaf Chain

Key pairs

You can choose RSA or EC curves depending on your policy.

Root CA (self-signed)

• BasicConstraints: CA=true
• KeyUsage: keyCertSign | cRLSign
• SKI/AKI

Intermediate CA (signed by Root)

• BasicConstraints: CA=true (optionally pathLen)
• KeyUsage: keyCertSign | cRLSign
• AKI derived from Root public key

Leaf certificate (signed by Intermediate)

• BasicConstraints: CA=false
• KeyUsage: digitalSignature (and keyEncipherment for some TLS profiles)
• ExtendedKeyUsage: serverAuth, clientAuth, etc.
• Optional SANs

What is dnsSans?

dnsSans is typically a list of DNS names placed into the certificate’s Subject Alternative Name extension for TLS server certificates (e.g., example.com).

Can it be removed for personal/client certificates?

Yes. For non-server certificates, you often use:

• rfc822Name (email)
• otherName (custom identity)
• or no SAN at all (depending on policy)

If EKU is serverAuth, SAN is strongly recommended for modern TLS validation. For clientAuth/personal identity certificates, SAN may be optional or use different SAN types.

Renewal (Recommended: Key Rollover)

• Generate a new leaf keypair
• Issue a new leaf certificate with the same identity/profile
• Optionally revoke the old leaf certificate

Re-Issue (Allow Changes + Optional Revocation)

A re-issue workflow may allow changes within policy limits:

• Subject changes (CN/email)
• SAN changes (DNS/email)
• Profile changes (EKU/KeyUsage)
• Optional revocation of the previous certificate (reason + timestamp)

Revocation Store: revoked.json

Simple implementations store revocation events into:

• ~/.pkixops/crls/revoked.json

Each entry typically includes serial, revokedAt, reason, subject/issuer, validity, and SHA-256 fingerprint.

CRL Publishing

A CRL publisher reads revoked.json and emits:

• intermediate.crl.pem
• intermediate.crl.der

In production, CRL publication should be scheduled and distributed via HTTP/CDN, and CRL Distribution Points (CDP) should point to the published URL.

Spring Boot Integration Notes

pkixops:
      cert-store-dir: /var/lib/pkixops/certs
      crl-store-dir: /var/lib/pkixops/crls

Example: Issue Leaf Using Intermediate from Classpath PKCS#12

ClassPathResource p12Res = new ClassPathResource("cert/intermediate.p12");

      P12IO.KeyMaterial km;
      try (InputStream in = p12Res.getInputStream()) {
        km = P12IO.readFirstKeyEntry(in, INT_PASSWORD);
      }

      X509Certificate intCert = km.certificate;
      PrivateKey intKey = km.privateKey;

      KeyPair leafKp = LEAF256.genEcP256();
      X509Certificate leafCert = LEAF256.issueLeafServer(
        leafKp,
        leafDn,
        intCert,
        intKey,
        leafDays,
        new String[] {}
      );

      String leafPem = PemUtil.toPem(leafCert);

License

The Apache License, Version 2.0