Mirror
/
acmed
mirror of https://github.com/breard-r/acmed.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
41 Commits
12 Branches
27 Tags
2.2 MiB
Tree: 84d2c94bad
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '84d2c94bad'
${ noResults }
acmed/CHANGELOG.md

40 lines
1.7 KiB
Raw Normal View History

Allow to reuse a key pair instead of creating a new one at each renewal The default behavior of most ACME clients is to generate a new key pair at each renewal. While this choice is respectable and perfectly justified in most configuration, it is also quite incompatible with the use of HTTP Public Key Pinning (HPKP). Although HPKP is not wildly supported and sometimes deprecated, users wishing to use it should not be blocked. https://tools.ietf.org/html/rfc7469 https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
6 years ago
​
​
​
​
​
​
Remove the `acme-lib` dependency Although the `acme-lib` crate comes very handy when creating a simple ACME client, a more advanced one may not want to use it. First of all, `acme-lib` does not support all of the ACME specification, some very interesting one are not implemented. Also, it does not store the account public key, which does not allow to revoke certificates. In addition to those two critical points, I would also add `acme-lib` has some troubles with its own dependencies: it uses both `openssl` and `ring`, which is redundant and contribute to inflate the size of the binary. Some of the dependencies also makes an excessive use of logging: even if logging is very useful, in some cases it really is too much and debugging becomes a nightmare. ref #1
5 years ago
​
Use account objects instead of an email field Defining an account solely by an email address is not the best strategy since the ACME protocol does not require it and also allows for more contacts information. Although this commit does not change the "one email" policy, it sets the bases so it could evolve in the future.
5 years ago
​
Retry request rejected with a recoverable error Some errors, like the badNonce one, are recoverable. Hence, the client is expected to retry. ACMEd will now re-send the associated request until it succeed or the max retries number is reached. Each retry is preceded by a small waiting time in order to let the server recover in case it was faulty.
5 years ago
Use account objects instead of an email field Defining an account solely by an email address is not the best strategy since the ACME protocol does not require it and also allows for more contacts information. Although this commit does not change the "one email" policy, it sets the bases so it could evolve in the future.
5 years ago
Remove the `acme-lib` dependency Although the `acme-lib` crate comes very handy when creating a simple ACME client, a more advanced one may not want to use it. First of all, `acme-lib` does not support all of the ACME specification, some very interesting one are not implemented. Also, it does not store the account public key, which does not allow to revoke certificates. In addition to those two critical points, I would also add `acme-lib` has some troubles with its own dependencies: it uses both `openssl` and `ring`, which is redundant and contribute to inflate the size of the binary. Some of the dependencies also makes an excessive use of logging: even if logging is very useful, in some cases it really is too much and debugging becomes a nightmare. ref #1
5 years ago
Use account objects instead of an email field Defining an account solely by an email address is not the best strategy since the ACME protocol does not require it and also allows for more contacts information. Although this commit does not change the "one email" policy, it sets the bases so it could evolve in the future.
5 years ago
Remove the `acme-lib` dependency Although the `acme-lib` crate comes very handy when creating a simple ACME client, a more advanced one may not want to use it. First of all, `acme-lib` does not support all of the ACME specification, some very interesting one are not implemented. Also, it does not store the account public key, which does not allow to revoke certificates. In addition to those two critical points, I would also add `acme-lib` has some troubles with its own dependencies: it uses both `openssl` and `ring`, which is redundant and contribute to inflate the size of the binary. Some of the dependencies also makes an excessive use of logging: even if logging is very useful, in some cases it really is too much and debugging becomes a nightmare. ref #1
5 years ago
​
​
​
​
​
​
v0.2.1
6 years ago
​
​
​
​
​
​
Allow to reuse a key pair instead of creating a new one at each renewal The default behavior of most ACME clients is to generate a new key pair at each renewal. While this choice is respectable and perfectly justified in most configuration, it is also quite incompatible with the use of HTTP Public Key Pinning (HPKP). Although HPKP is not wildly supported and sometimes deprecated, users wishing to use it should not be blocked. https://tools.ietf.org/html/rfc7469 https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
6 years ago
​
​
Add hook groups Some configurations may require to run the same bunch of hooks for several domains. In order to limit repetition, it is now possible to create a group that will reference to hooks or hook groups.
6 years ago
Add hooks before and after a file is created or edited It is considered a good practice to archive old certificates and private keys instead of simply dropping them away. Because ACMEd should not impose a way of doing things to system administrators, hooks are the way to go.
6 years ago
Send logs to syslog
6 years ago
Rename post_operation_hook to post_operation_hooks
6 years ago
​
​
Send logs to syslog
6 years ago
Daemonize the process
6 years ago
  1. # Changelog
  2. All notable changes to this project will be documented in this file.
  4. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
  5. and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
  8. ## [Unreleased]
  10. ### Added
  11. - An account object has been added in the configuration.
  12. - Failure recovery: HTTPS requests rejected by the server that are recoverable, like the badNonce error, are now retried several times before being considered a hard failure.
  14. ### Changed
  15. - In the configuration, the `email` certificate field has been replaced by the `account` field which matches an account object.
  16. - The `token` challenge hook variable has been renamed `file_name`.
  17. - The logs has been purged from many useless debug and trace entries.
  19. ### Removed
  20. - The DER storage format has been removed.
  23. ## [0.2.1] - 2019-03-30
  25. ### Changed
  26. - The bug that prevented from requesting more than two certificates has been fixed.
  29. ## [0.2.0] - 2019-03-27
  31. ### Added
  32. - The `kp_reuse` flag allow to reuse a key pair instead of creating a new one at each renewal.
  33. - It is now possible to define hook groups that can reference either hooks or other hook groups.
  34. - Hooks can be defined when before and after a file is created or edited (`file_pre_create_hooks`, `file_post_create_hooks`, `file_pre_edit_hooks` and `file_post_edit_hooks`).
  35. - It is now possible to send logs either to syslog or stderr using the `--to-syslog` and `--to-stderr` arguments.
  37. ### Changed
  38. - `post_operation_hook` has been renamed `post_operation_hooks`.
  39. - By default, logs are now sent to syslog instead of stderr.
  40. - The process is now daemonized by default. It is possible to still run it in the foreground using the `--foregroung` flag.