Staging certificates have the advantage that their retry limits are loose.
Therefore they can be obtained quickly when automatic retries are used.
Unfortunately they can not be used for deployments because their CA is not
accepted by clients. Production certificates do not have this limitation, but
their retry limits are strict. For production certificates, automatic retries
can only be performed a few times per hour. This makes automatic obtainment of
certificates tenacious.

With use_auto_staging=1, the advantages of the two certificate types are
combined. Uacme will first obtain a staging certificate. When the staging
certificate is successfully obtained, uacme will switch and obtain a production
certificate. Since the staging certificate has already been successfully
obtained, we can ensure that the production certificate is successfully
obtained in the first attempt. This means that "retries" are performed on the
staging certificate and the production certificate is obtained in the first
attempt.

In summary, this feature enables fast obtaining of production certificates when
automatic retries are used.

By default, this feature is set to use_auto_staging=0, which means that
uacme will behave as before by default.

Signed-off-by: Leonardo Mörlein <git@irrelefant.net>

With this commit, issue_cert() can be called multiple times alternating
between staging and production certificates within a script.

Before this commit, the production state dir was stored in $STATE_DIR.
But in the case of $use_staging=1, this variable was overwritten in
issue_cert() with $STAGING_STATE_DIR. This made it impossible to call
issue_cert() with $use_staging=0 afterwards. Now the production state
dir is stored in $PRODUCTION_STATE_DIR. This way it is not overridden
anymore and issue_cert() can be called multiple times alternating with
production and staging.

Signed-off-by: Leonardo Mörlein <git@irrelefant.net>

Prior to this commit, the acme service attempted to obtain certificates
once and then terminated, regardless of whether the certificate could be
obtained or not. This commit introduces a new uci option "retries" to
the "certificate" section. If this option is set to N, the acme service
will attempt to obtain the certificate up to N times before terminating.
There is a waiting pause between the retries to comply with the rate
limits of Let'sEncrypt.

The waiting pause is:
-  2 minutes for staging certificates
- 24 minutes for production certificates

The current "Failed Validation" rate limits of Let'sEncrypt are:
- staging:   60 per hour -> 1 failure every 1 minute in avg.
- production: 5 per hour -> 1 failure every 12 minutes in avg.

This means that we are within rate limits by a factor of two.

By default the option "retries" is set to "1", which means that acme
behaves as before by default. If the variable is set to "0", infinite
retries are performed.

This feature is helpful, when you already want to initiate the
certificate request, but you are still waiting for your dns server to be
configured, your network to appear or other conditions.

Signed-off-by: Leonardo Mörlein <git@irrelefant.net>

Before this commit, issue_cert always returned 1 no matter if uacme
returned 1, 2, 3, ... With this commit, the return code of the uacme
binary is propagated. Therefore the caller of issue_cert can
differentiate between "no renew necessary" and "an error occurred".

Signed-off-by: Leonardo Mörlein <me@irrelefant.net>

With this commit, the run-acme script can be included into other scripts
by setting INLCUDE_ONLY=1.

Signed-off-by: Leonardo Mörlein <me@irrelefant.net>

Signed-off-by: Peter Stadler <peter.stadler@student.uibk.ac.at>

Add possibility for user to provide setup and cleanup scripts for
additional flexibility. Setup-script takes precedence over the built-in
behavior of uacme.

This helps users with more complex use-cases to utilize uacme to update
certificates without adding complexity to the provided run.sh script.

Signed-off-by: Antti Seppälä <a.seppala@gmail.com>

lightweight client for the RFC8555 ACMEv2 protocol, written in plain C code
with minimal dependencies (libcurl and one of GnuTLS, OpenSSL or mbedTLS).

Signed-off-by: Lucian Cristian <lucian.cristian@gmail.com>