acme-dns-tiny issueshttps://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues2022-08-11T17:35:03Zhttps://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/12Does the DNS Zone configuration can be automatically retrieved ?2022-08-11T17:35:03ZAdrien Dorsazadrien@adorsaz.chDoes the DNS Zone configuration can be automatically retrieved ?I suspect I can retrieve the DNS Zone value directly from the SOA record of the domain where we install the TXT DNS resources.
Indeed, that's possible, dnspython provides directly a [zone_for_name](https://www.dnspython.org/docs/1.16.0/...I suspect I can retrieve the DNS Zone value directly from the SOA record of the domain where we install the TXT DNS resources.
Indeed, that's possible, dnspython provides directly a [zone_for_name](https://www.dnspython.org/docs/1.16.0/dns.resolver-module.html#zone_for_name) method to do it automatically.https://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/13Add an option to prefer alternate certificate link2020-12-23T20:36:00ZAdrien Dorsazadrien@adorsaz.chAdd an option to prefer alternate certificate linkAs Let's Encrypt gives two different ways to sign the requested certificates, acme-dns-tiny needs to give an option to choose which one to use.
As [reported](https://community.letsencrypt.org/t/transition-to-isrgs-root-delayed-until-jan...As Let's Encrypt gives two different ways to sign the requested certificates, acme-dns-tiny needs to give an option to choose which one to use.
As [reported](https://community.letsencrypt.org/t/transition-to-isrgs-root-delayed-until-jan-11-2021/125516) by Let's Encrypt, in January 2021, they'll serves certificates signed by their new ISR root certificate. Due to the fail of Android updates, only ~66% of devices will be compatible with the ISRG root certificates (Android version less than 7.1 will not be compatible, except if the user uses Firefox to navigate on the web).
At this date, Let's encrypt will give an alternate link to continue to use certificates cross-signed by Iden Trust. To give users a little break up to September 2021, site owner can get certificate from this alternate link instead of the primary link.
So, acme-dns-tiny needs to give an option, [like cert-bot](https://github.com/certbot/certbot/blob/master/certbot/CHANGELOG.md#160---2020-07-07), to prefer an alternate link for certificates if available.2020-11-30https://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/11Compatibility with dnspython 2.02020-11-04T22:33:05ZAdrien Dorsazadrien@adorsaz.chCompatibility with dnspython 2.0I got a report this script won't work with dnspython 2.0 and so, with Debian Bullseye.
Some relevant parts of the logs received while trying with 2.0:
```
[...]
Configure DNS client tools.
acme_dns_tiny.py:112: DeprecationWarning: plea...I got a report this script won't work with dnspython 2.0 and so, with Debian Bullseye.
Some relevant parts of the logs received while trying with 2.0:
```
[...]
Configure DNS client tools.
acme_dns_tiny.py:112: DeprecationWarning: please use dns.resolver.resolve() instead
in dns.resolver.query(config["DNS"]["Host"], rdtype="A")]
acme_dns_tiny.py:114: DeprecationWarning: please use dns.resolver.resolve() instead
in dns.resolver.query(config["DNS"]["Host"], rdtype="AAAA")]
[...]
Install DNS TXT resource for domain: example.com
acme_dns_tiny.py:222: DeprecationWarning: please use dns.resolver.Resolver.resolve() instead
in resolver.query(dnsrr_domain, rdtype="CNAME")][0]
Traceback (most recent call last):
File "python3.8/site-packages/dns/inet.py", line 87, in af_for_address
dns.ipv4.inet_aton(text)
File "python3.8/site-packages/dns/ipv4.py", line 49, in inet_aton
raise dns.exception.SyntaxError
dns.exception.SyntaxError: Text input is malformed.
requests
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "python3.8/site-packages/dns/inet.py", line 91, in af_for_address
dns.ipv6.inet_aton(text, True)
File "python3.8/site-packages/dns/ipv6.py", line 165, in inet_aton
raise dns.exception.SyntaxError
dns.exception.SyntaxError: Text input is malformed.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "acme_dns_tiny.py", line 365, in <module>
main(sys.argv[1:])
File "acme_dns_tiny.py", line 360, in main
signed_crt = get_crt(config, LOGGER)
File "acme_dns_tiny.py", line 231, in get_crt
_update_dns(dnsrr_set, "add")
File "acme_dns_tiny.py", line 41, in _update_dns
response = dns.query.tcp(dns_update, config["DNS"]["Host"],
File "python3.8/site-packages/dns/query.py", line 752, in tcp
(af, destination, source) = _destination_and_source(where, port,
File "python3.8/site-packages/dns/query.py", line 226, in _destination_and_source
af = dns.inet.af_for_address(where)
File "python3.8/site-packages/dns/inet.py", line 94, in af_for_address
raise ValueError
ValueError
```https://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/10Fix public key parsing2020-06-12T22:15:28ZAdrien Dorsazadrien@adorsaz.chFix public key parsingSee https://github.com/diafygi/acme-tiny/commit/58752c527c9345d23a771d2a93f729aaa8fe7712See https://github.com/diafygi/acme-tiny/commit/58752c527c9345d23a771d2a93f729aaa8fe7712https://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/9Support critical SAN extension2020-06-12T22:15:28ZAdrien Dorsazadrien@adorsaz.chSupport critical SAN extensionSee reported issue on acme-tiny: https://github.com/diafygi/acme-tiny/issues/216
and the fix: https://github.com/diafygi/acme-tiny/pull/217/filesSee reported issue on acme-tiny: https://github.com/diafygi/acme-tiny/issues/216
and the fix: https://github.com/diafygi/acme-tiny/pull/217/fileshttps://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/8Look for a way to receive certificate and chain separated2018-12-09T21:25:29ZAdrien Dorsazadrien@adorsaz.chLook for a way to receive certificate and chain separatedAccording to draft 16, we can imagine to reliably find the certificate in the chain (it MUST be the first one).
Maybe we could add some optional paths in the config to redirect Certificate and Chain in 2 different files ?
Note with ACM...According to draft 16, we can imagine to reliably find the certificate in the chain (it MUST be the first one).
Maybe we could add some optional paths in the config to redirect Certificate and Chain in 2 different files ?
Note with ACME-draft-16, we have this:
> In order to provide easy interoperation with TLS, the first certificate MUST be an end-entity certificate. Each following certificate SHOULD directly certify the one preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that represents a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.v2.1Adrien Dorsazadrien@adorsaz.chAdrien Dorsazadrien@adorsaz.chhttps://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/6ACME v2 Order "ready" status2018-12-09T21:25:28ZAdrien Dorsazadrien@adorsaz.chACME v2 Order "ready" statushttps://community.letsencrypt.org/t/acmev2-order-ready-status/62866https://community.letsencrypt.org/t/acmev2-order-ready-status/62866v2.1Adrien Dorsazadrien@adorsaz.chAdrien Dorsazadrien@adorsaz.ch2018-06-19https://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/7v2.1 : Compatibility with current boulder and acme-draft-162018-12-09T21:25:26ZAdrien Dorsazadrien@adorsaz.chv2.1 : Compatibility with current boulder and acme-draft-16As time go one, new RFCs appeared...
Currently, we have to implement acme-draft-16 (boulder server is already updated, but keep in mind [its divergences](https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md)).
I'...As time go one, new RFCs appeared...
Currently, we have to implement acme-draft-16 (boulder server is already updated, but keep in mind [its divergences](https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md)).
I've noticed these differences:
- [x] HTTP requests:
- 6.3. GET and POST-as-GET Requests
- GET not authenticated: Nonce and Directory (possible for certificate but not mandatory !)
- POST-as-GET: GET authenticated with payload = ""
[x] Check that every GET is replaced by a POST with payload = "" (non-JSON !)
- [x] Request Verification:
- [x] requires now to send an empty body payload = "{}"
- [x] Account rollover:
- [x] Old / New key signatures has been inverted (since draft 13)
> To change the key associated with an account, the client sends a
constructs a key-change object describing the change that it would request to the server containing signatures by both the old and new
like the server to make: keys. The signature by the new key covers the account URL and the
old key, signifying a request by the new key holder to take over the
account from the old key holder. The signature by the old key covers
this request and its signature, and indicates the old key holder's
assent to the roll-over request.
- [x] must remove nonce in the inner jwk (at least from 16 and allowed already before)
- [ ] Certificate issuance:
- [ ] Check what appears in the CSR: CommonName and SubjectAltName normally (since draft 13)
-> in case of error, order status stay at "ready" state allowing user to rebuild a CSR in compliance with what has been requested by the CA
=> really needed to manage orders with status "ready" !
- [x] Check the Accept HTTP Header in request (application/pem-certificate-chain by default)
- [ ] Aside / nice to have
- [ ] would be cool to give caaIdentities to the user if available (so he could install CAA DNS resource) or even install it !v2.1Adrien Dorsazadrien@adorsaz.chAdrien Dorsazadrien@adorsaz.chhttps://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/2Implement acme draft release 0.9 (aka Let's Encrypt API v2)2018-05-02T20:32:58ZAdrien Dorsazadrien@adorsaz.chImplement acme draft release 0.9 (aka Let's Encrypt API v2)Since, Let's Encrypt has now staging server implementing [draft-ietf-acme-acme-09](https://tools.ietf.org/html/draft-ietf-acme-acme-09), we can now develop a new version of acme-dns-tiny script (v2).
Updates to apply:
* Renames API en...Since, Let's Encrypt has now staging server implementing [draft-ietf-acme-acme-09](https://tools.ietf.org/html/draft-ietf-acme-acme-09), we can now develop a new version of acme-dns-tiny script (v2).
Updates to apply:
* Renames API endpoints:
* [x] new-account to newAccount
* [x] new-authz to newAuthz
* [x] new-order to newOrder
* revoke-cert to revokeCert (not used by acme-dns-tiny)
* key-change to keyChange (not used by acme-dns-tiny)
* Inside the Directory:
* [x] terms-of-service to termsOfService
* website to webSite (not used by acme-dns-tiny)
* caa-identities to caaIdentities (not used by acme-dns-tiny)
* Check that HTTP requests follows these recommendations:
* [x] Be sure to use HTTPS as it is required (required)
* [x] For new registration use of new-account instead of new-reg (required)
* [x] Add a User Agent with client name and version (recommended)
* [ ] Set Accept-Language header to get localized error messages (recommended)
* JWS Objects updates:
* [x] Use of `url` in the protected header instead of `resource` inside the payload
* [x] Include `jwk` in the protected header only when using `newAccount` and `revokeCert` resources. For other requests, we have to include `kid` (the account URI given on registration)
* [x] Account key rollover [has been modified](https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.3.6) to include the `kid` instead of the old `jwk` in the request headers.
* [x] For acme_account_delete script, the draft allows to [deactivate the account](https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.3.7) and not more to delete it
* [Certification Appliance](https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.4)
* [x] Use `newOrder` resource wiht one list of all names to validate instead of one `new-auth` by name
* [x] The "identifiers" list contains list of DNS names paired to a type (`"identifiers": [{"type":"dns", "value": "example.com"}]`)
* [x] Read section 7.1.3 to see how to define wildcard request
* [x] Get all challenges sending GET request to all `authorizations` urls contained in the response. Select `dns-01` challenges. To get challenges [section 7.5](https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.4).
* [x] Then, install all DNS resources
* [x] Then, send POST to the `finalize` address included in newOrder response. This POST message MUST include the CSR.
* [x] If ok (see status in RFC), retrieve certificate from the `certificate` value of the received JSON
* [ ] Account registration
* [x] acme-dns-tiny will [receive a 200 status code](https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.3.1)) instead of conflict when the account already exists: so, we'll need to check contact informations on each run
* Instead of always creating account, acme-dns-tiny can [look for an account]((https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.3.1)) with the `onlyReturnExisting` field to true when requesting `new-reg`. It certainly could be used to simplify the code. Finally, we just uses this option for our tools to deactivate account and to rollover keys.
* [ ] If the server indicates terms of service to be agreed in its directory, acme-dns-tiny has to include `termsOfServiceAgreed` field with value `true` when creating new account. (Currently, we always set it to True)
* Check if the directory contains externalAccountRequired to true: in that case we should include externalAccountBinding to the request (provided inside the configuration). It will require some more developments and to complexify the code.
* [x] Account update will return a `200` (OK) status code instead of the current `202`.
* [ ] Agreement of terms of service should need human manual interaction with ACME server (if CA wants it): the server will [give an URL with a token to send](https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.3.4) to the user (acme-dns-tiny will raise an error with detailed informations as we won't add a library for email notification, administrator will have to configure their services to get mails/sms/whatever on error for this service). acme-dns-tiny can also retrieve directly new url of tos in the `Link` header with `rel="terms-of-service"`v2.0Adrien Dorsazadrien@adorsaz.chAdrien Dorsazadrien@adorsaz.chhttps://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/1Stop hard coding Term of Services URL2018-04-09T21:01:54ZAdrien Dorsazadrien@adorsaz.chStop hard coding Term of Services URLThe ACME protocol provides a way to automatically the Term of Services url to the latest version (by use of a `Link` header with `rel=term-of-services`).
We should not hard code this URL, because it depends on the ACME provider (which...The ACME protocol provides a way to automatically the Term of Services url to the latest version (by use of a `Link` header with `rel=term-of-services`).
We should not hard code this URL, because it depends on the ACME provider (which can already be configured in the .ini file) and we should point in documentation that acme-dns-tiny will automatically use latest ToS.v1.3Adrien Dorsazadrien@adorsaz.chAdrien Dorsazadrien@adorsaz.chhttps://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/5Enable use of ECDSA private account key2018-02-28T06:42:29ZAdrien Dorsazadrien@adorsaz.chEnable use of ECDSA private account keyAs boulder allow to use either RSA or ECDSA account key, we should be able to use both of them.
I think we can do this by two means:
* use openssl to read the key and find parameters inside it
* ask to add configuration inside the c...As boulder allow to use either RSA or ECDSA account key, we should be able to use both of them.
I think we can do this by two means:
* use openssl to read the key and find parameters inside it
* ask to add configuration inside the config file if user uses non-rsa key
To acheive this issue will have to:
1. [ ] Update the account key rollover to take into account every RSA-PSK and ECDSA possible algorithm
1. [ ] Update the acme-dns-tiny script wot take into account one of RSA-PSK algorithm and one of ECDSA algorithm
1. [ ] Update our documentation to warn users using ECDSA keys that they have to use our choice to create their key (or adapt themselves the script with example inside the account key rollover tool) and that they'll have more work when the choice will be updated to latest securty recommendations.Adrien Dorsazadrien@adorsaz.chAdrien Dorsazadrien@adorsaz.chhttps://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/3Create a script to implement account key rollover2017-05-29T19:28:03ZAdrien Dorsazadrien@adorsaz.chCreate a script to implement account key rolloverACME RFC allows users to [rollover their private account key](https://tools.ietf.org/html/draft-ietf-acme-acme-04#section-6.3.2).
It will be useful to have a little script to apply this modification to avoid using compromised account ...ACME RFC allows users to [rollover their private account key](https://tools.ietf.org/html/draft-ietf-acme-acme-04#section-6.3.2).
It will be useful to have a little script to apply this modification to avoid using compromised account private key or to allow to upgrade RSA keys to ECDSA for example (or even modifies number of bytes used in these keys).
I suggest to do a little script like we have done for account deletion (which will be deactivation in future).
I think this script won't need a configuration file, but just two arguments to indicate old account private key and new private key. That's better, because we won't need code to read configuration file and because this script should be a one shot script which certainly won't be used in a cron job.v1.4Adrien Dorsazadrien@adorsaz.chAdrien Dorsazadrien@adorsaz.chhttps://gitlab.adorsaz.ch/adrien/acme-dns-tiny/-/issues/4Use Nonce received on each ACME response2017-05-21T07:07:40ZAdrien Dorsazadrien@adorsaz.chUse Nonce received on each ACME responseCurrently, acme-dns-tiny ask a Nonce to the acme directory on each requests.
As ACME server [must give a new Nonce on each response](https://tools.ietf.org/html/draft-ietf-acme-acme-02#section-5.4), we should use this one instead.
The r...Currently, acme-dns-tiny ask a Nonce to the acme directory on each requests.
As ACME server [must give a new Nonce on each response](https://tools.ietf.org/html/draft-ietf-acme-acme-02#section-5.4), we should use this one instead.
The request on acme directory should be done only on first initialisation (as acme-dns-tiny don't memory parameters of latest run, it should ask one at every launch and then use the ones in HTTP headers).v1.4Adrien Dorsazadrien@adorsaz.chAdrien Dorsazadrien@adorsaz.ch