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.
57 Commits
12 Branches
27 Tags
2.2 MiB
Tree: 6067f52c7e
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '6067f52c7e'
${ noResults }
acmed/CHANGELOG.md

47 lines
2.4 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
6 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.
6 years ago
Add tacd to the CHANGELOG
6 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.
6 years ago
Change the hook and domains definitions The previous system was too limited when it comes to flexibility using hooks. This limitation came from the false idea that, for a given certificate, all challenges must be validated with the same method. In order to prove that false, domains in a certificate can now make use of any challenge type available. In order to be more flexible, hooks are now given a type and are defined in the same registry (instead of 6). Each one will be called when considered relevant based on its type.
6 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.
6 years ago
Add tls-alpn-01 challenge support Although the standardization is still a draft, this challenge is already supported by Let's Encrypt. https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/
6 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.
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
6 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.
6 years ago
Change the hook and domains definitions The previous system was too limited when it comes to flexibility using hooks. This limitation came from the false idea that, for a given certificate, all challenges must be validated with the same method. In order to prove that false, domains in a certificate can now make use of any challenge type available. In order to be more flexible, hooks are now given a type and are defined in the same registry (instead of 6). Each one will be called when considered relevant based on its type.
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
6 years ago
Change the hook and domains definitions The previous system was too limited when it comes to flexibility using hooks. This limitation came from the false idea that, for a given certificate, all challenges must be validated with the same method. In order to prove that false, domains in a certificate can now make use of any challenge type available. In order to be more flexible, hooks are now given a type and are defined in the same registry (instead of 6). Each one will be called when considered relevant based on its type.
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
6 years ago
​
​
​
Change the hook and domains definitions The previous system was too limited when it comes to flexibility using hooks. This limitation came from the false idea that, for a given certificate, all challenges must be validated with the same method. In order to prove that false, domains in a certificate can now make use of any challenge type available. In order to be more flexible, hooks are now given a type and are defined in the same registry (instead of 6). Each one will be called when considered relevant based on its type.
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
6 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. - tacd, the TLS-ALPN-01 validation daemon.
  12. - An account object has been added in the configuration.
  13. - In the configuration, hooks now have a mandatory `type` variable.
  14. - It is now possible to declare hooks to clean after the challenge validation hooks.
  15. - 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.
  16. - The TLS-ALPN-01 challenge is now supported. The proof is a string representation of the acmeIdentifier extension. The self-signed certificate itself has to be built by a hook.
  18. ### Changed
  19. - In the configuration, the `email` certificate field has been replaced by the `account` field which matches an account object.
  20. - The format of the `domain` configuration variable has changed and now includes the challenge type.
  21. - The `token` challenge hook variable has been renamed `file_name`.
  22. - The `challenge_hooks`, `post_operation_hooks`, `file_pre_create_hooks`, `file_post_create_hooks`, `file_pre_edit_hooks` and `file_post_edit_hooks` certificate variables has been replaced by `hooks`.
  23. - The logs has been purged from many useless debug and trace entries.
  25. ### Removed
  26. - The DER storage format has been removed.
  27. - The `challenge` certificate variables has been removed.
  30. ## [0.2.1] - 2019-03-30
  32. ### Changed
  33. - The bug that prevented from requesting more than two certificates has been fixed.
  36. ## [0.2.0] - 2019-03-27
  38. ### Added
  39. - The `kp_reuse` flag allow to reuse a key pair instead of creating a new one at each renewal.
  40. - It is now possible to define hook groups that can reference either hooks or other hook groups.
  41. - 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`).
  42. - It is now possible to send logs either to syslog or stderr using the `--to-syslog` and `--to-stderr` arguments.
  44. ### Changed
  45. - `post_operation_hook` has been renamed `post_operation_hooks`.
  46. - By default, logs are now sent to syslog instead of stderr.
  47. - The process is now daemonized by default. It is possible to still run it in the foreground using the `--foregroung` flag.