io7m | single-page | multi-page | Certusine User Manual
7.3. generate-keypair
Previous
7. Command-Line Interface
Up
7.5. show-certificate-outputs
Next

# 7.4. renew

- 7.4.1. Name
- 7.4.2. Description
- 7.4.3. Output Idempotence
- 7.4.4. Examples

## 7.4.1. Name

1
renew - Issue and renew certificates

## 7.4.2. Description

1
The renew command encapsulates the main functionality of the certusine package: It issues and/or renews certificates in a perpetual loop, and sends those certificates to a set of configured outputs.

### 7.4.2.2. Parameters

Parameter | Type | Required | Description
--- | --- | --- | ---
--file | Path | true | The configuration file
--only-once | boolean | false | Renew certificates once and then exit.
--schedule | Duration | false | Renew certificates repeatedly, waiting this duration between attempts.
--verbose | CLPLogLevel | false | Set the minimum logging verbosity level.

3
The renew command will validate the configuration file specified with --file, and then loop forever attempting to issue and/or renew all certificates for all domains specified in the domains section of the configuration file. The command will pause for the duration specified by --schedule between attempts to renew certificates, and only certificates that have less than the amount of time specified by the CertificateExpirationThreshold parameter before expiration will be passed through the full ACME renewal process. If the --only-once option is specified, the client will execute one iteration of the renewal loop and then exit.

## 7.4.3. Output Idempotence

1
The renew command will aggressively write and re-write existing certificates to all the configured certificate outputs, redundantly. Thus, it is necessary that all certificate output implementations be idempotent with regards to the write operation. There are multiple reasons for this redundancy. Firstly, the certusine client cannot know the status of all the external systems to which it supplies certificates; external systems can be destroyed and recreated at any given time, and an external system should not be forced to wait until the next certificate renewal to receive certificates just because it wasn't present at the exact time the original issue/renewal occurred. Secondly, the very nature of systems being external means that the act of sending certificates to those systems can fail. Whilst the certusine client does retry I/O operations on failure, sometimes a system can be inaccessible long enough for all of the retry attempts to fail. If the certusine client did not redundantly write certificates, the external system would be stuck without any certificates until the next full renewal attempt.

## 7.4.4. Examples

### 7.4.4.1. Example

    $ certusine renew --file config.xml --schedule PT1M
    info: [example.com] (attempt 1/10) checking if domain is authorized
    info: [example.com] (attempt 1/10) domain is already authorized
    info: [example.com] (attempt 1/10) checking if certificates require reissuing
    info: [example.com] (attempt 1/10) certificates do not require reissuing
    info: [example.com] (attempt 1/10) saving certificates to outputs
    info: [example.com] (attempt 1/10) saving certificate to output directory:main-output
    info: waiting until 2022-07-01T13:45:34Z for the next renewal attempt (PT1M)

7.3. generate-keypair
Previous
7. Command-Line Interface
Up
7.5. show-certificate-outputs
Next
io7m | single-page | multi-page | Certusine User Manual