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
|
# 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.
For example, the user can add arbitrary number of `Cert`'s into a `CA`
container, upon each successful sign.
## Author
Yuuta Liang <yuutaw@student.ubc.ca>
|
