1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
|
# 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>
|
