fhofherr / acmeproxy Goto Github PK

While #2 enabled acmeproxy to perform HTTP01 challenges it currently does not have an endpoint to serve the challenge.

In order to retrieve certificates from Let's Encrypt acme-proxy needs to be able to perform an HTTP-01 challenge.

During development some todos were added. Those need to be resolved before version 0.1.0 can be released. Todos can be resolved by either fixing them or by creating issues for them.

Currently acmeproxy uses arbitrary data to create an ACME account for itself:

* A random UUID is used as the account ID
* The domain is hard-coded to `www.example.com`
* The empty string is used as email for the ACME account

In order to be useful, the behavior has to be changed to the following:

• Domain and Email have to be configurable. Either by using a configuration file / environment variables or by an admin interface.
• If acmeproxy did not create an ACME account yet, it may continue to use a random UUID to create a new account. As soon as it created the account it must reuse it and thus check if there is already an UUID.

Note: the UUID is used to identify the account within acmeproxy only. It is of no use for the ACME CA.

tbd

After acmeproxy is able to perform an HTTP-01 challenge (#2) it has to be possible to configure which clients are allowed to use acmeproxy.

acmeproxy will obtain the certificates for its clients and store them locally. Additionally it provides a way for the clients to download their certificates once acmeproxy has obtained them.

Code to manage certificates starts to creep all over acmeproxy's packages. Quite a few packages need to create private keys for testing purposes. Others will need to parse and inspect or validate certificates.

Create a package cryptoutil (or a better name) which consolidates all that code. Additionally it should contain test helpers which are able to create private keys and are able to write them to test data files as well as read them from such files.

GolangCI Lint constantly adds new linters. Neither are all necessary, nor do I agree with all of them. Enabling all linters is nice if one wants to see what is available, but gets tiring pretty soon. It is thus better to select a default set of linters and disable the others.

Naturally acmeproxy has to encrypt its own communication. Therefore we have to obtain a certificate for the public instance of acmeproxy using the acme-client operation mode.

Implementation note:

Upon startup acmeproxy checks if it already has a certificate for itself. If not it uses the self-test endpoint (#7) to check if the DNS server already has been configured correctly. Then it tries to obtain a certificate for itself. If the self-test fails acmeproxy waits for an configurable amount of time and retries to obtain a certificate.

After the ACME certificate authority issued a certificate we need to store it on disk. While we are just thinking about the acme-client operation mode it is enough to store it unencrypted.

We do not want to rely on an external database or similar to store certificates. Therefore there are two possibilities:

1. Store certificates on disk
2. Use an embedded key-value store like bbolt.

Once acmeproxy is able to act as an acme-client users need to be able to use it as such. Therefore it is necessary to document how to deploy acmeproxy in such a way.

acmeproxy stores certificates along with client accounts and settings. This data needs to be backed up.

Certificates retrieved by performing an HTTP-01 challenge and stored locally (#2) have to be refreshed periodically.

acmeproxy server should start the server. Listenaddress an Port(s) have to be configurable by command line argument and environment variable.

Since we implemented our own errors package containing an custom error type using pkg/errors seems redundant.

Clients of acmeproxy may want to change the email address they used to register. This is also the email address used to register an ACME account on their behalf. If clients change their email address with acmeproxy we must make sure that this email address is also changed in the respective ACME account.

Currently most tests are "happy-path" tests. This needs to change!

After #4 is implemented and acmeproxy is capable of refreshing a certificate we need to search for certificates to refresh. The search for certificates to refresh should ideally be triggered by an external event.

The instance of acmeproxy tries to resolve its own hostname using DNS and checks if it can reach this endpoint. This is to ensure that we don't perform an ACME challenge before the user has actually configured the DNS server.