# JCAMgr (Java Certification Authority Manager)

A simple but powerful X.509 certification authority written in Java.
It manages a X.509 CA (certification authority) and allows administrators to
submit a PKCS#10 CSR (certification signing request), apply CA policies, and
get the signed X.509 certificate back, using a GUI. It also has a GUI that
allows administrators to list, view, and revoke issued certificates and
sign X.509 CRLs (certificate revocation list).

Almost all organizations today are maintaining internal PKIs that allow
organization members (either users or servers) to easily trust other users
or computers through digital signature and X.509 certification by trusting a
single internal root certification authority (Root CA). A common deployment
of internal PKI is to have an online server or a GUI to fully manage that CA
and allow administrators to easily sign certificates and manage them, often
automatically through some Internet protocols (e.g., RFC8894 SCEP). Although
existing solutions exist, many are proprietary (e.g., Microsoft Active
Directory Certification Services, ADCS), paid (e.g., the AWS managed private
CA service costs about $300 a month), implemented in alternative languages
(e.g., Step CA), or lack of a GUI (e.g., Step CA). This project is extremely
useful for organization system administrators who would like to graphically
manage their certification authorities with an open-source solution. I am
also very eager to build such a project because I am very familiar with PKI
technologies, and I am also running two internal PKIs at my home, using raw
OpenSSL command line (honestly, not very user friendly) and ADCS (absolutely
proprietary).

## User Stories

As a user, I want to be able to:

1. Generate a CA cryptography key-pair and its corresponding X.509 certificate
   into the program and view it. The private key must not be displayed or exported
   in any format under any circumstances for security purposes.
2. Input CSRs, edit the certificate properties (e.g., subject, not before,
   not after, serial, key usage, extended key usage, X.509v3 extensions, etc.),
   sign it using the CA private key, and get the signed certificate in DER or
   PEM-encoded-DER formats; then add that certificate to the signed-certs list.
3. List all the certificates this CA had signed, view their properties, and
   optionally revoke any of them with a corresponding PKCS#10 reason. The
   certificates must not be deleted from the list under any circumstances but
   only revoked because some future administrators or the legal team may need
   to audit it.
4. Publish base CRLs.
5. Add, enable, disable, or remove custom certificate templates (also called
   policies) that constraints what each type of certificates can and cannot have
   and their properties (e.g., TLS server certificates vs user logon certificates
   must be different in many ways), and the user will be able to choose which
   template they use after CSR input.
6. View audit logs like who did what at what time for legal audit uses. Audit
   log entries must never be deleted.
7. Choose to save the whole CA database into a JSON file. That is, save the
   private key, CA certificate, issued / revoked certificates, templates, and
   logs into a JSON file. Signing certs and CRLs and revoking certs will
   automatically save the database for audit purposes.
8. Load the CA database from JSON and restore the private key, CA cert, cert
   list, templates, and logs.

For example, the user can add arbitrary number of `Cert`'s into a `CA`
container, upon each successful sign.

## Instructions

1. Load / store to `./data/ca.json` by clicking on the Load / Store button on the top left. Signing certificates,
   revoking certificates, publishing CRLs will automatically save the database. The unsaved changes are visible at the
   bottom status line.
2. The main operations are at the upper panel, from the toolbar until the audit logs pane. The lower panel shows audit
   logs.
3. Start by generating a RSA2048 private key, by clicking on the "Generate" button. Then, sign a CSR to be sent to the
   upper level CA. Finally, get the signed certificate back and install it by clicking on the "Install" button.
4. Define a template. Navigate to the "Templates" tab and click on "New". Set template name, subject (optional), and
   validity period (in days). These settings will be applied when signing certificates. You can add arbitrary number of
   templates to the database, don't forget to save.
5. Before a template can be used, it must be enabled. Select a template and click on the "Enable" button on the top.
   Optionally, disable or delete the templates no longer needed.
6. Sign certificates. Navigate to the "Certs" tab and click on "Sign" button in the toolbar. Select the CSR. In the popup
   dialog, you can select the template and apply certificate properties. When you are ready, click on the "Issue" button.
   The CA will sign this certificate and add it to the database. The database will be automatically saved. You can view
   your certificate from the list and export it.
7. If a certificate has to be revoked ahead of validity period, select it from the list and click on the "Revoke" button
   in the toolbar. From the dialog, confirm certificate subject and serial number, and select an appropriate reason. You
   may also customize the revocation time, but it must be typed in ISO-8601 format with offset. After revocation, the list
   automatically updates, and you can see the certificate you just revoked now has a red cross icon. Note that the database
   automatically saves after revoking.
8. Periodically publish CRLs. On the "CA" tab, click on the "CRL" button on the top right, and select a path for the CRL.
   The database automatically saves after issuing a new CRL.

The CA public key will also be rendered as a QR code on the "CA" tab, for easier transfer between computers. The encoded
data is PEM-encoded PKCS#1 public key.

## Author

Yuuta Liang <yuutaw@student.ubc.ca>