Majic Projects
Gimmecert Timeline
November 29, 2018
task_tiny.png 17:54  Task GC-31 - Release version 0.2.0
branko (branko):
Issue closed
icon_milestone.png 17:54 0.2.0
A new milestone has been reached
November 28, 2018
task_tiny.png 22:13  Task GC-31 - Release version 0.2.0
branko (branko):
Issue created
Release new version of Gimmecert.

The following should be done:

- Follow the release procedure outlined in development documentation.
feature_request_tiny.png 22:10  Feature request GC-29 - Prevent installation on unsupported Python versions
branko (branko):
Issue closed
task_tiny.png 21:16  Task GC-27 - Update all requirements
branko (branko):
Issue closed
feature_request_tiny.png 19:20  Feature request GC-30 - Support for Python 3.7
branko (branko):
Issue closed
feature_request_tiny.png 18:32  Feature request GC-30 - Support for Python 3.7
branko (branko):
Issue created
Gimmecert currently claims support for Python 3.7, but this version is currently not part of the test matrix.

The following should be done:

- Add Python 3.7 to testing matrix (tox configuration).
- Make sure all tests are passing on Python 3.7. Make necessary fixes in code to make it work correctly.
feature_request_tiny.png 18:02  Feature request GC-29 - Prevent installation on unsupported Python versions
branko (branko):
Issue created
Gimmecert is supported on a number of different Python versions. This is guaranteed by running the relevant functional and unit tests.

However, at the moment it is still possible to install Gimmecert even on unsupported Python versions. The installation will work, but the tool will be completely unusable.

It would be better to fail early, and with clear message, instead of letting the users successfully install the tool.

The following should be done:

- Update the setup.py to include "protection" against installation on unsupported version of Python.
- Include the `python_requires` argument. While this will only work with pip 9.0.0+, it should still be good enough. It's not worth the hassle to cover every possible software combination out there.
bug_report_tiny.png 09:23  Bug report GC-26 - Wrong issuer DN for end entity certificates when CA hierarchy depth is 2 or more
branko (branko):
Issue closed
November 27, 2018
feature_request_tiny.png 22:49  Feature request GC-28 - Vagrant set-up for running tests against multiple Python versions
branko (branko):
Issue closed
November 26, 2018
feature_request_tiny.png 09:45  Feature request GC-28 - Vagrant set-up for running tests against multiple Python versions
branko (branko):
Issue created
The Gimmecert is supposed to be compatible with various versions of Python. At time of this writing this includes covers version 3.4, 3.5, 3.6, and 3.7.

Since having multiple Python versions available at the same time can be problematic (unless running something like [Gentoo](https://gentoo.org/)), it would be useful to set-up a Vagrant configuration that would make the process easier.

The following should be done:

- Add a Vagrantfile configuration file.
- Set-up provisioning of Vagrant machine as follows:
- Base the set-up on Debian Stretch (use the contrib image for proper Vagrant directory sharing).
- Set a decent hostname (like `gimmecert-testing`) for the VM.
- Install the necessary Python versions by building them from source.
- Create a dedicated virtualenv for running the necessary tests (including package installation), and automatically activate it for the `vagrant` user on login.
- Write development documentation for using the Vagrant machine:
- Document procedure for running the full set of tests from within VM through tox.

**Sidenote:** When installing build dependencies for Python, make sure to not install OpenSSL 1.1.0 development headers, since those will not work with Python 3.4.
November 25, 2018
task_tiny.png 18:47  Task GC-27 - Update all requirements
branko (branko):
Issue created
A number of packages that Gimmecert uses might have received updates. All dependencies of Gimmecert should be brought up to date in the package metadata configuration.

In particular, the [cryptography](https://cryptography.io/en/latest/) library has seen at least one critical security-related issue fixed in versions `>= 2.3` (current version used by Gimmecert is 2.1.x).

The following should be done:

- Check all requirements listed in the `setup.py` script.
- Update all requirements to latest available version.
- Fix any errors or deprecation warnings resulting from the upgrade.
bug_report_tiny.png 18:40  Bug report GC-26 - Wrong issuer DN for end entity certificates when CA hierarchy depth is 2 or more
branko (branko):
Issue created
When issuing end entity certificates (client/server) after the CA hierarchy has been initialised with depth of 2 or more, the resulting issuer DN encoded in the end entity certificate is wrong. The value should be the subject DN of issuing CA, but instead of that the encoded value is set to the issuing CA's own issuer.

For example, if we have `Level 1 CA`, `Level 2 CA`, and server certificate `server1`, the issuer for `server1` will be set to subject DN of `Level 1 CA`.

For all other purposes, however, the certificate has been correctly issued (e.g. the correct private key got used for signing).
May 16, 2018
icon_build.png 22:54 0.1.0
New version released
task_tiny.png 22:02  Task GC-25 - Release version 0.1.0
branko (branko):
Issue closed
icon_milestone.png 22:02 0.1.0
A new milestone has been reached
task_tiny.png 20:40  Task GC-25 - Release version 0.1.0
branko (branko):
Issue created
Release new version of Gimmecert.

The following should be done:

- Follow the release procedure outlined in development documentation.
May 15, 2018
enhancement_tiny.png 21:52  Enhancement GC-23 - Move the update DNS names functionality from server command to renew command
branko (branko):
Issue closed
feature_request_tiny.png 21:52  Feature request GC-24 - Release procedure with script
branko (branko):
Issue closed
May 13, 2018
developer_report_tiny.png 12:13  User story GC-9 - As a system integrator, I want to renew server or client certificate in order to change the additional naming or renew expiration date
branko (branko):
Issue closed
May 02, 2018
feature_request_tiny.png 20:45  Feature request GC-24 - Release procedure with script
branko (branko):
Issue created
At the moment there are no release procedures that can be followed for releasing Gimmecert. In order to make the maintenance easy in the future, it would be a good idea to have the foundation for this worked-out in the early stages. Preferably this process should be semi-automated.

As part of creating a release procedure, it would be good to also add some documentation around development on how the versioning works, etc.

The following should be done:

- Create initial release notes based on the existing issues. Release notes should consist of:
- Abstract overview of what has been implemented. This can be a more human-friendly description.
- Listing of all issues that have been fixed/implemented during this release. Separate issues per type.
- Document release notes update procedure. Release notes should be updated along the way, together with fixed bugs/implemented features/enhancements.
- Document the versioning schema used for Gimmecert. Use the semantic versioning for this purpose.
- Write helper script for making releasing easier. The script should:
- Ensure the OpenPGP signing card is available for making sure all commits/tags are signed.
- Verify there are no uncommitted changes.
- Try to perform all commits/tagging early in order to prompt user at beginning of process.
- Roll-back tags in case of failed tests.
- Take care of filling-in correct version in release notes based on the current branch and already released versions. Might be useful to have a replaceable string for working release notes.
- Take care of starting new release notes (more as a placeholder).
- Take care of tagging releases.
- Prepare release in a dedicated branch in case something goes wrong. Once release is fully functional and has been tested, tag/merge that.
- Create maintenance branches where appropriate.
- Take care of running a clean test in all Python environment prior to proceeding.
- Take care of pushing the changes upstream, including tags.
- Take care of building and uploading the release to PyPI.
- Document the release procedure.
May 01, 2018
enhancement_tiny.png 12:07  Enhancement GC-23 - Move the update DNS names functionality from server command to renew command
branko (branko):
Issue created
Currently the server command comes with functionality to update the DNS names used in the certificate, without affecting the private key/CSR used initially. This is done via the `--update-dns-names` option.

For all the practical purposes, this is in effect a certificate renewal operation, and it does not make much sense to make it part of the server command (since this command is normally used for creating completely new certificates).

It would be better to fold this option into the `renew` command instead.

The following should be done:

- Move the --update-dns-names option into the `renew` command.
- The option should be implemented/updated as follows:
- Option should accept a comma-separated list of DNS names to use.
- If an empty string is passed-in, the option should only include the base entity name as DNS subject alternative name.
- Option should be applicable only for the server certificates.
- Move/update functional tests related to updating server names.
- Ensure all unit tests are still fully functional.
- Update the CLI examples if necessary.
- Update the documentation about renewals and server certificate issuance.
April 27, 2018
developer_report_tiny.png 22:26  User story GC-21 - As a system integrator, I want to be able to issue certificates using a CSR so I can generate my own private key
branko (branko):
Issue closed
feature_request_tiny.png 22:25  Feature request GC-22 - Ability to provide CSR for issuing and renewing certificates
branko (branko):
Issue closed
April 07, 2018
developer_report_tiny.png 13:38  User story GC-10 - As a system integrator, I want to be able to see tool's help in CLI so I can remind myself what commands are available
branko (branko):
Issue closed
developer_report_tiny.png 11:30  User story GC-10 - As a system integrator, I want to be able to see tool's help in CLI so I can remind myself what commands are available
branko (branko):
Issue closed
feature_request_tiny.png 11:27  Feature request GC-22 - Ability to provide CSR for issuing and renewing certificates
branko (branko):
Issue created
In some cases it might be useful to be able to reuse existing private keys generated server-side, and simply issue a certificate for them by providing a certificate signing request.

The following should be done:

- Add option for passing-in a CSR to the `server`, `client`, and `renew` commands.
- Option should be implemented as follows:
- Option should accept a single argument, path to the CSR.
- If specified path is equal to `-`, prompt user for pasting-in a CSR.
- CSR should be stored alongside the generated certificate.
- Use only the public key in resulting certificate.
- When using the option for the renew command, remove private key (if any) and/or replace the existing CSR with a new one.
- Update the `status` command:
- For entities where CSR is available but not the private key, make sure to show the correct artefact information (path to CSR).
- Update CLI help for affected commands.
- Update CLI examples.
- Update documentation for affected commands, adding description for the new option.
developer_report_tiny.png 11:02  User story GC-21 - As a system integrator, I want to be able to issue certificates using a CSR so I can generate my own private key
branko (branko):
Issue created
As a system integrator, sometimes I generate private keys server-side, and I want to issue corresponding certificates using Gimmecert.

In order to do this, I need to pass-in a certificate signing request generated using my own private key.

I would like to be able to:

- Get prompted to paste in a CSR.
- Provide CSR by specifying path to a file that contains it.
- Have this ability available for all commands used for issuing certificates - `client`, `server`, and `renew`.
developer_report_tiny.png 10:17  User story GC-8 - As a system integrator, I want to get status of current CA hierarchy and issued certificates so I could determine if I need to take an action
branko (branko):
Issue closed
feature_request_tiny.png 10:16  Feature request GC-20 - Ability to display status
branko (branko):
Issue closed
March 30, 2018
developer_report_tiny.png 11:28  User story GC-4 - As a system integrator, I want to easily issue server and client certificates so that I can quickly test software that requires them
branko (branko):
Issue closed
developer_report_tiny.png 11:27  User story GC-9 - As a system integrator, I want to renew server or client certificate in order to change the additional naming or renew expiration date
branko (branko):
Issue closed
March 25, 2018
feature_request_tiny.png 14:29  Feature request GC-18 - Ability to renew existing certificates
branko (branko):
Issue closed
March 21, 2018
feature_request_tiny.png 21:12  Feature request GC-19 - Ability to update server certificate DNS subject alternative names
branko (branko):
Issue closed
March 20, 2018
feature_request_tiny.png 20:09  Feature request GC-20 - Ability to display status
branko (branko):
Issue created
After a number of certificates have been issued using the tool, it should be possible to show status of currently issued artefacts.

The following should be done:

- Implement status command.
- Status command should:
- Display information about CA hierarchy as follows:
- Make sure the section is clearly indicating that it describes the CA hierarchy.
- List CAs in order of their seniority (self-signed at top, leaf CA at bottom).
- Show subject DN of each CA certificate
- Show CA certificate validity.
- CA certificates with wrong validity should be clearly indicated as such (not valid yet, expired).
- Display paths to certificates.
- Mark the issuing (leaf) CA in some way for users to be aware that it is the one used for issuance of certificates.
- Display information about all issued server certificates as follows:
- Make sure information resides within its own section on screen, clearly indicating it is showing information about server certificates.
- Show subject DN of each server certificate.
- Show DNS subject alternative names.
- Show validity.
- Server certificates with wrong validity should be clearly indicated as such (not valid yet, expired).
- Display information about all issued client certificates as follows:
- Make sure information resides within its own section on screen, clearly indicating it is showing information about client certificates.
- Show subject DN of each client certificate.
- Show validity.
- Client certificates with wrong validity should be clearly indicated as such (not valid yet, expired).
- Status command should not accept any positional or optional arguments.
- Status command should be implemented with the following constraints in mind:
- Validity time should be shown in UTC.
- Example usage in CLI help should be updated to cover the new command.

Documentation should cover:

- Command usage.
- What timezone is used for displaying validities.
- Example output.
feature_request_tiny.png 19:56  Feature request GC-19 - Ability to update server certificate DNS subject alternative names
branko (branko):
Issue created
From time to time it might be necessary to replace an issued server certificate with a new one where the DNS subject alternative name has been updated.

This might be necessary in cases where:

- Initial DNS subject alternative name provided is wrong.
- Additional DNS subject alternative names have been provided by mistake.
- A new DNS subject alternative names need to be added.

The following should be done:

- Add option to server command for renewing existing server certificate with updated naming provided.
- The new option should:
- Preserve the server private key during generation if it exists.
- If the private key does not exist, it should be generated, and command should proceed as usual.
- Issue a new certificate using the passed-in naming information.
- If the private key and certificate have previously existed, overwrite the existing certificate.
- If the certificate has previously existed and was overwritten, signal to user that only the certificate has been replaced.
- New functionality should be implemented with the following constraints in mind:
- Make sure the existing private key is preserved.
- Certificate should be otherwise generated in same manner as when generating a completely new one. The only thing that changes is whether private key gets generated or not.
- Examples in CLI help should be updated.

Documentation should cover:

- New option usage, with examples on how to both add more DNS subject alternative names or to remove them altogether.
feature_request_tiny.png 19:34  Feature request GC-18 - Ability to renew existing certificates
branko (branko):
Issue created
As client and server certificates are getting issued, it can happen that their validity has expired, or perhaps the user wants to replace the private key.

At the moment this can be done by removing the artefacts, and issuing the certificate again. However, the problem with this is that:

- It is not possible to preserve the private key and just get a new certificate.
- It is required to provide the very same information provided the last time, which is tedious.

It would be good if there was a built-in convenient way to do this instead.

The following should be done:

- Implement a renew certificate command.
- Renew command should:
- Optionally generate a new private key.
- Use the same naming as in the original certificate.
- Replace the existing certificate with a new one.
- Provide user with information on what has been done.
- Renew command should accept the following positional arguments:
- Type of entity (server/client).
- Name of entity.
- Renew command should accept the following optional arguments:
- Flag denoting that the private key should be regenerated.
- Renew command should be implemented with the following constraints in mind:
- Command should not run in case the entity is not known. Instead an informative error message should be shown.
- Existing artefacts should be replaced with new ones. It should be possible to do this as late as possible, once both private key and certificate are known, in order to avoid partial writes.
- In case of any additional naming (like DNS subject alternative names), information should be pulled-out of the existing certificate.
- New certificate should contain same set of extensions as the original one (basic constraints, KU, EKU, subject alternative name).
- Certificate should be issued by the leaf CA (furthest away from the root/level 1 CA).
- Certificate validity should not exceed the CA validity.
- Validity should start at time of issuance minus 15 minutes.
- Both server and client certificate renewal should be supported.
- Example usage in help should be updated for the new command.

Documentation should cover:

- Command usage for both server and client.
- Command usage should cover cases where private key is kept and where private key is regenerated as well.
- Information about subject DN and subject alternative names being take from existing certificate.
March 18, 2018
developer_report_tiny.png 10:50  User story GC-7 - As a system integrator, I want to issue client certificates so I can deploy them for use with client applications I use
branko (branko):
Issue closed
developer_report_tiny.png 10:49  User story GC-6 - As a system integrator, I want to issue server certificates so I can deploy them for use with server applications I use
branko (branko):
Issue closed
feature_request_tiny.png 10:48  Feature request GC-16 - Ability to issue client certificates
branko (branko):
Issue closed
March 09, 2018
task_tiny.png 22:02  Task GC-17 - Refactor CLI command handling and relevant tests
branko (branko):
Issue closed
March 04, 2018
task_tiny.png 20:00  Task GC-17 - Refactor CLI command handling and relevant tests
branko (branko):
Issue created
At the moment there are just two commands available in the tool, but there are already some drawbacks from the initial design around commands. Mainly:

- There is no decent way to unit test the output being printed to `stdout`/`stderr`.
- The `init` command handles the output within the wrapper function, while the `server` command will produce message and status for wrapper consumer. This is a bit inconsistent.
- Both `init` and `server` commands have its own logic behind returning status and error messages.
- Testing exit codes is from different commands is cumbersome and lacks consistency.

The following should be done:

- All command implementations (from the `commands` module) should accept the standard output and error streams as function parameters. This would help in two ways:
- Commands can take care of all output, especially since commands "have better idea" of what the output means.
- It will be easier to unit-test the command output - since it would be as simple as providing an instance of `io.StringIO`.
- In turn, all output handling should be removed from the `cli` module, and the wrappers and `main` would only take care of passing-in the `sys.stdout` and `sys.stderr`.
- All commands should return an exit code. This would make it simpler to unit-test exit codes.
- Tests which are manipulating the `sys.argv` should be restructured/rewritten to adjust for the new layout. This would probably mean moving a lot of tests into `test_commands.py`.
- Tests should be updated to ensure that they do not accidentally use non-temporary dedicated directory when generating artifacts. There might be a couple of those that are misbehaving.