Lab CA

This repository contains a simple CLI tool for managing a Certificate Authority (CA).

It has been designed to as easy to use as possible and provides a basic set of CA features:

• Create a CA and a self-signed CA certificate
• Create and sign a few most common types of certificates:
  • Server certificate
  • Client certificate
  • Code signing certificate
  • Email certificate
• Sign a CSR to create a certificate
• Revoke a certificate
• List issued certificates
• Create a CRL (Certificate Revocation List)

Usage

The tool is designed to be used from the command line. It has a simple command structure:

lab-ca <command> [options]

There are two commands available:

• initca - initialize a new CA - this command creates a new CA and a self-signed CA certificate.
• issue - issue a new certificate - this command creates a new certificate signed by the CA.

Run the command with -h or --help or without any arguments to see the usage information. Each command has its own set of options, arguments and a help message.

CA Initialization

Create a new CA configuration file:

ca "example_ca" {
  name = "Example CA"
  country = "PL"
  organization = "ACME Corp"
  key_size = 4096
  validity = "10y"

  paths {
    certificates = "certs"
    private_keys = "private"
  }
}

NOTE: lab-ca uses HCL (HashiCorp Configuration Language) for configuration files. You can find more information about HCL here.

ca block's label has not function, but may be used to identify the CA in the future.

The following attributes are available:

• name - the name of the CA
• country - the country of the CA
• organization - the organization of the CA
• organizational_unit - the organizational unit of the CA (optional)
• locality - the locality of the CA (optional)
• province - the province of the CA (optional)
• email - the email address of the CA (optional)
• key_size - the size of the CA key in bits (default: 4096)
• validity - the validity period of the CA certificate (default: 10 years)
• paths - paths to store certificates and private keys

The paths block defines where the command will store the generated certificates and private keys. On Linux and macOS the directory specified for private keys will be created with 0700 permissions. However, the command does not check if the directory has correct permissions, so you should ensure that the directory is not accessible by other users. On Windows, both directories will be created with default ACL for the current user. You have to secure the private keys directory yourself.

NOTE: The command does not encrypt private keys. It is not designed to be used in a production environment.

Certoficate Issuance

To issue a new certificate you can use the issue command and specify the certificate defintion in the command line or you can use batch mode and provide a file with certificate definitions.

The definition file also uses HCL syntax. Here is an example of a certificate definition:

defaults {
    subject = "{{ .Name }}.example.com"
    type = "server"
    validity = "1y"
    san = ["DNS:{{ .Name }}.example.com"]
}

certificate "grafana" {
    # from default: subject = "{{ .Name }}.example.com" # result: grafana.example.com
    # from default: type = "server"
    # from default: validity = "1y"
    # from default: san = ["DNS:{{ .Name }}.example.com"] # result: [ "DNS:grafana.example.com" ]
}

certificate "loki" {
    subject = "{{ .Name }}.example.net" # result: loki.example.net
    # from default: type = "server"
    # from default: validity = "1y"
    san = ["DNS:{{ .Name }}.example.net"] # result: [ "DNS:loki.example.net" ]
}

Values specified in the defaults block will be used for all certificates unless they are overridden in the individual certificate definitions. Go style template syntax is also supported, so you can use {{ .Name }} to refer to the certificate name.

You can use DNS or IP SANs for server certificates (server and server-only), and email SANs for email certificates (email). The command will check if the SAN is valid based on type of the certificate.