Majic Projects
Majic Ansible Roles
Go to the previous open issue
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
icon_project.png Majic Ansible Roles / Open Enhancement MAR-169 Use less ambigous file extensions for X.509 certificates and private keys
Go to the next issue (open or closed)
Go to the next open issue
Issue basics
  • Type of issue
    Enhancement
  • Category
    General
  • Targetted for
    Not determined
  • Status
    New
  • Progress
  • Priority
    Not determined
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (0)
There are no items
People involved
Times and dates
  • Posted at
  • Last updated
  • Estimated time
    8 hours
  • Time spent
    No time spent
    Click here to see time logged against this issue
Issue details
Attachments (0)
There is nothing attached to this issue
Duplicate issues (0)
This issue does not have any duplicates
Description

Currently Majic Ansible Roles primarily use file extensions .key and .pem when deploying files that contain OpenSSL-style base64-encoded private keys and X.509 certificates. The only exception to this are tests that generate the material using Gimmecert. The problem with using these extensions is:

  • .key does not convey what the format of the file is (is it OpenSSL-style base64-encoded private key, PKCS#1, PKCS#8, PKCS#12?).
  • .pem does not convey what the content of the file really is, since this is a common extension used for most of the OpenSSL-generated artefacts.

It would be useful to pick a bit more structured file extension naming schema instead, that would convey both what is stored within the file and in what format.

The following should be done:

  • Switch to using .key.pem extension for OpenSSL-style base64-encoded private key files.
  • Switch to using .cert.pem extension for OpenSSL-style base64-encoded X.509 certificate files.
  • Switch to using .dh.pem extension for OpenSSL-style base64-encoded Diffie-Hellman parameter files.
  • Update all relevant roles.
    • Deploy files to their destination using the new schema.
    • Drop files from destination servers that used the old schema.
    • Make sure configuration files are referencing the new paths.
  • Update all affected tests.
  • Update usage instructions.
  • Update role reference documentation.
  • Update test site configuration and instructions.
  • Update release notes.
Todos (0 / 0)
There are no comments