kariustobias / acme-rs Goto Github PK

Our error type obviously represents an Error, so it would be nice to implement the trait and set an alias for Result<T> = Result<T, Error> in order to allow easy usage via Result<T>. The Display trait would just provides more specific error messages.

We currently don't map an error that's send from the server directly to our error type (enum Error in file error.rs). Looking at the RFC, ACME generally provides precise error information in the form urn:ietf:params:acme:error:<error-type> within a JSON object in the body of any http response. The specific response changes it's Content-Typeheader field to application/error+json. It would be nice to parse the error type from the http response.

Currently we're opening a webserver ourselves, but if the server is currently running an instance of apache or nginx, we need to create a file relative to the Webserver root (usually /var/www/..) and write the token into it (this involves parsing another parameter. If mentoring is wanted, just ask.

Currently, we don't actually allow requesting a certificate with a running web server (e.g. apache2). However this would be a nice feature. There are 2 benifits that need to be implemented:

1. The webserver should be able to request an apache server without actually having to shut the current web server down.

2. The apache2 configuration file should automatically be configured. This should require adding the parameter SSLCertificateFile, SSLCertificateKeyFile and SSLCertificateChainFile.

3. (optional) If you want to, you can also configure some secury measures like HTTP Public Key Pinning and OCSP Stapling. This would really enhance the acme-rs client

The RFC explains that an Account could be deactivated via a HTTP POST request. This shouldn't be too hard to implement.

Currently a Certificate Signing Request (csr) gets created for every certificate. But we could also parse the car (PEM format) from a file specified by the user. This would also involve adding a flag to the cli.

An internal ACME server for testing purposes is very important for securing the functionality of amce-rs via automated tests in the future.
The idea is to set up a testing environment via docker. This should be possible with step-ca

In the future, we could therefore add a CI pipeline to automate testing.

This also involves writing the account that was created by us into a file. (probably json)

We currently only implement the HTTP Challenge, but the RFC specifies also a DNS challenge which involves writing a special token into a TXT entry of the servers DNS record.