starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-09-02 17:37:12 +02:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

Forcing IPv6 does not work #160

New Issue
Closed
opened 2025-12-29 00:26:17 +01:00 by adam · 3 comments
adam commented 2025-12-29 00:26:17 +01:00
Owner
Copy Link
Copy Source

Originally created by @athei on GitHub (Nov 18, 2016).

My domain has a A and a AAAA record but the challenge MUST use the AAAA because i can't control port 80 on IPv4 only on IPv6 because of my dual stack light. I can't remove the A record from the domain either because I need it to reach my home server from IPv4 only hosts (through a different port then). I used the --ipv6 flag (in addition to setting is in the config file) but it still prefers the IPv6 address:

dehydrated -c --ipv6
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "Could not connect to theissen.io",
    "status": 400
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/_FUguK9WeyuwunmYAAihYXUwOF8Xr_2aMrxCX05e_Ng/350426455",
  "token": "",
  "keyAuthorization": "",
  "validationRecord": [
    {
      "url": "http://theissen.io/.well-known/acme-challenge/qdTdN0VnAd2_1QQjyGmNGzph5OPJx3s89IGonUj0n2U",
      "hostname": "theissen.io",
      "port": "80",
      "addressesResolved": [
        "109.232.227.133",
        "2a00:61e0:41f6:6a01:de:88ff:fe22:4e00"
      ],
      "addressUsed": "109.232.227.133"
    }
  ]
})

This is my config

# Resolve names to addresses of IP version only. (curl)
# supported values: 4, 6
# default: <unset>
IP_VERSION=6

# Path to certificate authority (default: https://acme-v01.api.letsencrypt.org/directory)
#CA="https://acme-v01.api.letsencrypt.org/directory"
#CA="https://acme-staging.api.letsencrypt.org/directory"

# Which challenge should be used? Currently http-01 and dns-01 are supported
CHALLENGETYPE="http-01"

# Base directory for account key, generated certificates and list of domains (default: $SCRIPTDIR -- uses config directory if undefined)
#BASEDIR=$SCRIPTDIR

# File containing the list of domains to request certificates for (default: $BASEDIR/domains.txt)
DOMAINS_TXT="${BASEDIR}/domains.txt"

# Output directory for generated certificates
CERTDIR="/usr/local/etc/ssl/dehydrated"

# Directory for account keys and registration information
ACCOUNTDIR="${BASEDIR}/accounts"

# Output directory for challenge-tokens to be served by webserver or deployed in HOOK (default: /usr/local/www/dehydrated)
WELLKNOWN="/var/www/letsencrypt"

# Default keysize for private keys (default: 4096)
KEYSIZE="4096"

# Path to openssl config file (default: <unset> - tries to figure out system default)
#OPENSSL_CNF=

# Program or function called in certain situations
#
# After generating the challenge-response, or after failed challenge (in this case altname is empty)
# Given arguments: clean_challenge|deploy_challenge altname token-filename token-content
#
# After successfully signing certificate
# Given arguments: deploy_cert domain path/to/privkey.pem path/to/cert.pem path/to/fullchain.pem
#
# BASEDIR and WELLKNOWN variables are exported and can be used in an external program
# default: <unset>
#HOOK=

# Chain clean_challenge|deploy_challenge arguments together into one hook call per certificate (default: no)
HOOK_CHAIN="no"

# Minimum days before expiration to automatically renew certificate (default: 30)
RENEW_DAYS="30"

# Regenerate private keys instead of just signing new certificates on renewal (default: yes)
PRIVATE_KEY_RENEW="yes"

# Which public key algorithm should be used? Supported: rsa, prime256v1 and secp384r1
KEY_ALGO=rsa

# E-mail to use during the registration (default: <unset>)
CONTACT_EMAIL=alex@theissen.io

# Lockfile location, to prevent concurrent access (default: $BASEDIR/lock)
LOCKFILE="${BASEDIR}/lock"

# Option to add CSR-flag indicating OCSP stapling to be mandatory (default: no)
OCSP_MUST_STAPLE="yes"
Originally created by @athei on GitHub (Nov 18, 2016). My domain has a A and a AAAA record but the challenge MUST use the AAAA because i can't control port 80 on IPv4 only on IPv6 because of my dual stack light. I can't remove the A record from the domain either because I need it to reach my home server from IPv4 only hosts (through a different port then). I used the --ipv6 flag (in addition to setting is in the config file) but it still prefers the IPv6 address: ``` dehydrated -c --ipv6 ERROR: Challenge is invalid! (returned: invalid) (result: { "type": "http-01", "status": "invalid", "error": { "type": "urn:acme:error:connection", "detail": "Could not connect to theissen.io", "status": 400 }, "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/_FUguK9WeyuwunmYAAihYXUwOF8Xr_2aMrxCX05e_Ng/350426455", "token": "", "keyAuthorization": "", "validationRecord": [ { "url": "http://theissen.io/.well-known/acme-challenge/qdTdN0VnAd2_1QQjyGmNGzph5OPJx3s89IGonUj0n2U", "hostname": "theissen.io", "port": "80", "addressesResolved": [ "109.232.227.133", "2a00:61e0:41f6:6a01:de:88ff:fe22:4e00" ], "addressUsed": "109.232.227.133" } ] }) ``` This is my config ``` # Resolve names to addresses of IP version only. (curl) # supported values: 4, 6 # default: <unset> IP_VERSION=6 # Path to certificate authority (default: https://acme-v01.api.letsencrypt.org/directory) #CA="https://acme-v01.api.letsencrypt.org/directory" #CA="https://acme-staging.api.letsencrypt.org/directory" # Which challenge should be used? Currently http-01 and dns-01 are supported CHALLENGETYPE="http-01" # Base directory for account key, generated certificates and list of domains (default: $SCRIPTDIR -- uses config directory if undefined) #BASEDIR=$SCRIPTDIR # File containing the list of domains to request certificates for (default: $BASEDIR/domains.txt) DOMAINS_TXT="${BASEDIR}/domains.txt" # Output directory for generated certificates CERTDIR="/usr/local/etc/ssl/dehydrated" # Directory for account keys and registration information ACCOUNTDIR="${BASEDIR}/accounts" # Output directory for challenge-tokens to be served by webserver or deployed in HOOK (default: /usr/local/www/dehydrated) WELLKNOWN="/var/www/letsencrypt" # Default keysize for private keys (default: 4096) KEYSIZE="4096" # Path to openssl config file (default: <unset> - tries to figure out system default) #OPENSSL_CNF= # Program or function called in certain situations # # After generating the challenge-response, or after failed challenge (in this case altname is empty) # Given arguments: clean_challenge|deploy_challenge altname token-filename token-content # # After successfully signing certificate # Given arguments: deploy_cert domain path/to/privkey.pem path/to/cert.pem path/to/fullchain.pem # # BASEDIR and WELLKNOWN variables are exported and can be used in an external program # default: <unset> #HOOK= # Chain clean_challenge|deploy_challenge arguments together into one hook call per certificate (default: no) HOOK_CHAIN="no" # Minimum days before expiration to automatically renew certificate (default: 30) RENEW_DAYS="30" # Regenerate private keys instead of just signing new certificates on renewal (default: yes) PRIVATE_KEY_RENEW="yes" # Which public key algorithm should be used? Supported: rsa, prime256v1 and secp384r1 KEY_ALGO=rsa # E-mail to use during the registration (default: <unset>) CONTACT_EMAIL=alex@theissen.io # Lockfile location, to prevent concurrent access (default: $BASEDIR/lock) LOCKFILE="${BASEDIR}/lock" # Option to add CSR-flag indicating OCSP stapling to be mandatory (default: no) OCSP_MUST_STAPLE="yes" ```
adam closed this issue 2025-12-29 00:26:17 +01:00
adam commented 2025-12-29 00:26:18 +01:00
Author
Owner
Copy Link
Copy Source

@germeier commented on GitHub (Nov 18, 2016):

The "--ipv6" parameter is for forcing how the dehydrated script is accessing the Let's Encrypt servers, not the other way around.

In the latest ACME draft (draft-ietf-acme-acme-04) I find only this:

As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA records, at its discretion.

So, I believe that there is no solution for this scenario at the moment.

@germeier commented on GitHub (Nov 18, 2016): The "--ipv6" parameter is for forcing how the dehydrated script is accessing the Let's Encrypt servers, not the other way around. In the latest ACME draft [(draft-ietf-acme-acme-04)](https://tools.ietf.org/html/draft-ietf-acme-acme-04) I find only this: > As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA records, at its discretion. So, I believe that there is no solution for this scenario at the moment.
adam commented 2025-12-29 00:26:18 +01:00
Author
Owner
Copy Link
Copy Source

@txr13 commented on GitHub (Nov 18, 2016):

That is correct. LE can choose any A or AAAA record at will; you cannot tell it to use only the AAAA record. If using the http-01 challenge method, you must (in effect) have the challenges reachable on every server process for which either an A or AAAA record exists.

For your use case, using the dns-01 challenge type might be a better solution. If you have a supported DNS provider, you might look into using lexicon; otherwise a semi-automatic solution like email-notify might at least get the job done.

@txr13 commented on GitHub (Nov 18, 2016): That is correct. LE can choose any A or AAAA record at will; you cannot tell it to use only the AAAA record. If using the http-01 challenge method, you must (in effect) have the challenges reachable on every server process for which either an A or AAAA record exists. For your use case, using the dns-01 challenge type might be a better solution. If you have a supported DNS provider, you might look into using lexicon; otherwise a semi-automatic solution like email-notify might at least get the job done.
adam commented 2025-12-29 00:26:18 +01:00
Author
Owner
Copy Link
Copy Source

@athei commented on GitHub (Nov 18, 2016):

Yea snap I guess we can close this. I was looking into DNS. Got other problems with this :( See #308 #309

@athei commented on GitHub (Nov 18, 2016): Yea snap I guess we can close this. I was looking into DNS. Got other problems with this :( See #308 #309
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Complicated
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 suggestions wanted
testing
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#160