Validated grammar in the README.md file.
This commit is contained in:
16
README.md
16
README.md
@@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
This repository contains a simple CLI tool for managing a Certificate Authority (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:
|
It has been designed to be as easy to use as possible and provides a basic set of CA features:
|
||||||
|
|
||||||
- Create a CA and a self-signed CA certificate
|
- Create a CA and a self-signed CA certificate
|
||||||
- Create and sign a few most common types of certificates:
|
- Create and sign a few most common types of certificates:
|
||||||
@@ -28,7 +28,7 @@ There are two commands available:
|
|||||||
- `initca` - initialize a new CA - this command creates a new CA and a self-signed CA certificate.
|
- `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.
|
- `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.
|
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
|
### CA Initialization
|
||||||
|
|
||||||
@@ -51,7 +51,7 @@ ca "example_ca" {
|
|||||||
|
|
||||||
> **NOTE:** `lab-ca` uses HCL (HashiCorp Configuration Language) for configuration files. You can find more information about HCL [here](https://github.com/hashicorp/hcl).
|
> **NOTE:** `lab-ca` uses HCL (HashiCorp Configuration Language) for configuration files. You can find more information about HCL [here](https://github.com/hashicorp/hcl).
|
||||||
|
|
||||||
`ca` block's label has not function, but may be used to identify the CA in the future.
|
The `ca` block's label has no function, but may be used to identify the CA in the future.
|
||||||
|
|
||||||
The following attributes are available:
|
The following attributes are available:
|
||||||
|
|
||||||
@@ -66,13 +66,13 @@ The following attributes are available:
|
|||||||
- `validity` - the validity period of the CA certificate (default: 10 years)
|
- `validity` - the validity period of the CA certificate (default: 10 years)
|
||||||
- `paths` - paths to store certificates and private keys
|
- `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.
|
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 the 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.
|
> **NOTE:** The command does not encrypt private keys. It is not designed to be used in a production environment.
|
||||||
|
|
||||||
## Certoficate Issuance
|
## Certificate 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.
|
To issue a new certificate, you can use the `issue` command and specify the certificate definition on the command line, or 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:
|
The definition file also uses HCL syntax. Here is an example of a certificate definition:
|
||||||
|
|
||||||
@@ -99,6 +99,6 @@ certificate "loki" {
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
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.
|
Values specified in the `defaults` block will be used for all certificates unless overridden in 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.
|
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 the type of certificate.
|
||||||
|
Reference in New Issue
Block a user