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
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
# 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).
**For the TA grading:**
* If your Idea prompts that it cannot find classes like `org.json`, try to re-add
each library in the `spec/` directory by clicking on "Add as library" again. Then
re-run the program. This happens when the project is just cloned, and I don't know
why. It may be an IntelliJ Idea issue.
* If your Idea prompts for "Gradle '...' build scripts found", click "Skip".
## 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.
## Phase 4: Task 2
```
Tue Nov 28 11:51:46 PST 2023 - yuuta: Generated CA private key.
Tue Nov 28 11:51:50 PST 2023 - yuuta: Signed CA csr
Tue Nov 28 11:52:12 PST 2023 - yuuta: CA certificate is installed.
Tue Nov 28 11:52:38 PST 2023 - yuuta: Added a new template: TLS Server
Tue Nov 28 11:52:43 PST 2023 - yuuta: Template TLS Server has been enabled
Tue Nov 28 11:52:50 PST 2023 - yuuta: Signed a cert with serial number 1
Tue Nov 28 11:53:01 PST 2023 - yuuta: Certificate 1 is revoked with reason KEY_COMPROMISE at 2023-11-28T19:52:57.124440191
Tue Nov 28 11:53:06 PST 2023 - yuuta: Signed CRL with 1 revoked certs.
```
## Phase 4: Task 3
[View complete UML diagram (may be too complex to read)](img/uml.all.pdf) |
[View type hierarchy only](img/uml.type.pdf) |
[View associations only](img/uml.assoc.pdf)
Refactoring ideas:
1. Refactor `CertificationAuthority` to better adhere to the single responsibility principle. Currently, `CertificationAuthority`
represents a complete certification authority, and it contains all required responsibilities such that keeping track of issued
and revoked certificates, managing templates, and keeping audit logs. It is better to decouple them into different modules and
models.
2. I can also decouple `MainUI` into different widgets. Currently, `MainUI` takes care of almost all of the UI data processing
work (that is, render data from `CertificationAuthority` and handle user input), except for a few dialogs like `RevokeDialog`,
`IssueDialog`, and `TemplateEditDialog`. I can create new widgets like custom `JPanel`s to handle specific tasks, and `MainUI`
would be a composition of all widgets only.
### A note on UML
The above UML diagrams are generated using a simple tool called UMLGen, and its source is located in the `umlgen/`
directory. I am the author of the tool. The tool uses JavaParser to parse Java syntax into AST, and it generates Graphviz
dot files using Apache Freemarker. The dot files are then rendered into the above PDFs using Graphviz. The whole process
is driven by Gradle.
To generate the files again, run the following command: (`dot(1)` and `gradle(1)` must present in PATH)
```shell
gradle uml
```
Please note that both codes in `umlgen/` and Gradle build scripts `*.gradle` are NOT part of the project submission.
They do not subject to project requirements as they are not part of the project at all, either tests or UI. They are only
local build tools. The project (both tests and UI) runs perfectly without any of these files. To run the project, clone it
in IntelliJ Idea and press the green triangle in `Main`.
Again, these codes and build files are ONLY included in the repository for referencing purposes. THEY ARE NOT PART OF THE
SUBMISSION.
SPECIFICALLY, the files that are NOT part of the submission are the follows (**DO NOT GRADE**):
* build.gradle (Gradle build file for my local testing of the project without IntelliJ Idea. This includes declerations for
testing and the project, with coverage. It also includes the task to generate UMLs.)
* settings.gradle (Multi-project Gradle build file.)
* umlgen/ (The source code of my tiny UML generator. Written in Kotlin.)
* tests/ (Used to generate external testing data for demonstration purposes. That is, this directory includes build scripts
that use OpenSSL to simulate a root CA and leaf certificate holder. Written in Makefile.)
**!!! PLEASE DO NOT GRADE ANY PART INCLUDED IN THE ABOVE LIST !!!**
The files that ARE part of the submission are the follows (**PLEASE GRADE**):
* checkstyle.xml (The original checkstyle configuration file, as provided with the starter.)
* data/ (Data used in testing. Also used to store the `ca.json` used in load / store functionalities.)
* src/ (Main and test Java source files, including PNG resources.)
* lib/ (JAR libraries, including both JUnit libraries provided with the starter and external libraries imported during development phases.)
* img/ (UML PDFs.)
## Author
Yuuta Liang <yuutaw@student.ubc.ca>
|
