Do-It-Yourself Certificate Authority on a Raspberry Pi

On github, I created a Do-It-Yourself Certificate Authority project (https://github.com/texadactyl/diyca), suitable for unit testing (developer testing) just prior to entering integration system testing with a wider audience: more developers, testing organization, end-users, and/or auditors.  A web server approach is used in obtaining an X.509 certificate signed by the unit testing Certificate Authority ("Calvin"), based on a Certificate Signing Request (CSR) provided by the user, employing a web browser (Firefox, Safari, etc.).

The inspiration of this project is my own personal technical history and the myriad of Internet of Things (IoT) projects.  My 0bservation of undesirable patterns:

• No data security at all: (1) no authentication of the endpoints, (2) no message integrity checking, and (3) data is transmitted over the network in clear-text.
• Partners are using weak cryptography (E.g. RC4 or Single-DES) and there is no secure methodology of installing or managing the secret keys.  E.g. coding the secret keys as program constants.
• Partners are using strong secret key cryptography but there is no secure methodology of installing or managing the secret keys.  E.g. The secret keys are never changed.

Even when developers agree to securely use public key infrastructure and strong cryptography, I have seen cases where they stub this aspect out of their project during unit testing.  This just puts off the inevitable and may cause project delays when the stubs are later replaced with operational code.  Better to design and develop a project from the very beginning as it is intended to be in production.

To install, just follow the instructions in https://github.com/texadactyl/diyca/blob/master/docs/preparation_notes.txt.  I use diyca on a Raspberry Pi 2 (1GB RAM) and Raspberry Pi Zero W but I believe that it will operate just as well on earlier models with 512MB.  Ditto for Beagle Bone Black or a Pine A64(+).  So, if you have an "old guy" gathering dust somewhere, it might be worth installing this project on it.  Of course, this project could share space on an existing server system on your LAN that understands Bash scripts and Python.

Note that the preparation notes assumes that one is performing a ground up installation.  Of course, one could add this project to an existing installation.

Once the `git clone` step from the preparation notes is executed, the diyca tree will look like this:

The "example.users" folders contain 2 SSL applications: alice (client) and bob (server).  A 3rd application (datagen.py in the alice folder) has been supplied to generate data that alice transmits to bob (who echoes it back verbatim).

Once the diyca web server is running, it will respond to HTTPS requests at the IP address of the machine where it is running and at the configured port ("8080" is the default).  The initial screen (User Login):

You need to register as a user before signing forms so click on the register link to obtain the register form:

Once registered, you are automatically logged in.  The main menu appears:

depicted

The pull down function list gives you 3 choices:

• Certificate Signing Request (CSR)
• Change Password
• Logout

The CSR function is what alice and bob need to be able to run:

The alice.csr file has already been browsed from the example.users/certs folder on my machine.  Clicking on the submit button causes alice.csr to be uploaded to the web server, signed, and then alice.crt is downloaded.  After that, I had to move the alice.crt from $HOME/Downloads to the example.users/certs folder for the purpose of using it in executing alice.  Ditto for bob.  See README.txt in the example.users folder regarding the alice-bob duo of applications.

Feel free to contact me for inquiries and issues, especially if you find any bugs.  Suggestions for improving the Python code, HTML, CSS, Javascript, Bash scripts, configuration files, choice of web infrastructure (Flask), the examples, and whatever else are most welcome.