Git Product home page Git Product logo

le-godaddy-dns's Introduction

le-godaddy-dns

CI

le-godaddy-dns is a Let's encrypt module, designed to be used as a hook with dehydrated for DNS-based validation against Godaddy DNS.

Prerequisites

To use this module you will need the following:

Usage

Before anything else: Back up your zone-file.

You are letting a program meddle with your DNS. Bugs happen. Shit happens. Be prepared.

First you need to download all dependencies and configure letsencrypt.sh.

# get dependencies
sudo apt-get install python3 python3-pip curl

# setup a workplace
ROOTDIR=$HOME/letsencrypt
mkdir -p $ROOTDIR
cd $ROOTDIR

# get letsencrypt.sh
git clone https://github.com/lukas2511/dehydrated
# get le-godaddy-dns
git clone https://github.com/josteink/le-godaddy-dns
cd $ROOTDIR/le-godaddy-dns
python3 -m pip install -r requirements.txt --user

# configure dehydrated
cd $ROOTDIR/dehydrated
nano domains.txt

# the format for domains.txt is documented in letsencrypt.sh's repo.
# https://github.com/lukas2511/dehydrated/blob/master/docs/domains_txt.md
cat domains.txt
mydomain.com sub.mydomain.com
example.com
...

HOOK_CHAIN

This step is required for wildcard certificates and is otherwise recommended to reduced runtime if you have many domains (SAN Cert.). Dehydrated gives you the option to process multiple domains in wall call to the hook script, saving resource overhead and pauses for dns propagation with each call.

# open your config file for dehydrated
# Note: you can also edit the configuration elsewere if you want
# https://github.com/lukas2511/dehydrated/#config
nano $ROOTDIR/dehydrated/config

# Locate the line #HOOK_CHAIN="no"
# Uncomment the line and change the value to yes
HOOK_CHAIN="yes"

Configure Godaddy Auth API Keys as Environment Variables:

# configure your API keys
export GD_KEY=your_key_here
export GD_SECRET=your_secret_here

Other Options

GODADDY_DNS_SLEEP - override default TXT update wait time in seconds (default/min is 30s)

export GODADDY_DNS_SLEEP=60

Running The Script

Now you need to configure le-godaddy-dns and retrieve your certs.

cd $ROOTDIR/dehydrated

# run letsencrypt.sh in "cron" mode (-c) this creates CSRs, 
# keys and everything we need automatically.
./dehydrated --challenge dns-01 -k $ROOTDIR/le-godaddy-dns/godaddy.py -c

You should now have your certs, and the output should tell you where they are.

You can put the last section in a script and add as a cronjob to ensure your certificates gets auto-renewed.

You can optionally inspect that they look like they should

find . -name fullchain.pem -exec openssl x509 -in '{}' -text -noout \;
find . -name fullchain.pem -exec openssl x509 -in '{}' -subject -noout \;

You may also decide to customize the deploy_certificates hook in goddady.py if you want the certificates automatically copied to another destination than the one provided by letsencrypt.sh.

Disclaimer

This module is not affiliated with nor endorsed by Godaddy. The Godaddy API python-modules are not affiliated with nor endorsed by Godaddy.

This module is not affiliated with nor endorsed by Let's Encrypt.

This module is provided as is and comes with absolutely NO warranties and I take absolutely NO responsibility should an error resulting from using this script wipe out your DNS and get your Godaddy account terminated.

Bugs in dependant Python-modules have resulted in data-loss for the author, and while the currently published code only uses code proven to be safe at time of writing, I can make no guarantees about how things may or may not work in the future.

Testing the module on a test-domain where you can afford downtime is definitely recommended.

That said, it all works for me.

le-godaddy-dns's People

Contributors

archon52 avatar dalssaso avatar danielewood avatar dependabot[bot] avatar javascriptdude avatar josteink avatar karlwmacmillan avatar matteomattei avatar rasmuslindroth avatar renovate-bot avatar renovate[bot] avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

le-godaddy-dns's Issues

Cut down on supported python versions?

Right now le-godaddy-dns supports Python 3.5 and up. I have no deep issue with that, apart from dependencies like tld starting to drop support.

That leaves us the choice to either upgrade packages and limit python-support, or keep supporting older python-versions, but being prevented from upgrading dependencies.

Given that:

  • Python 3.4 is EOLed.
  • Debian stable (which from a developer point off view ships stone-age versions of software) is on Python 3.7.
  • And dependencies starting to require 3.6 minimum...

I'm inclined to drop support for Python 3.5, in favour of being able to use up-to-date packages.

Anyone have any good reason not to do so? Would it for instance cause issues with RHEL/CentOS deployments?

Script runs but no certs are created

I created a Bash script (shown below) that I crafted from the le-godaddy-dns readme. I added my GoDaddy API production keys (not shown of course and the real domain is not shown either) and ran the script. At the end of the script I got the prompt warning me to make sure I registered my account. I did that but that message still shows every time I run the script. However it never generates any certificates nor do I see any error or warning messages, aside from the previously mentioned "register" info message. How can I fix this?

NOTE: If I run the 'register' command it tells me that the account has already been created. In the accounts dir I see a large random looking string, which I assume is the account. Also, I did try hard coding the paths in the config file, including the certs directory, but the certs directory is always empty.

NOTE-2: When the command runs it returns immediately, so I'm wondering if it's actually doing anything? Is there a log file somewhere I can expect?

Here is my script:

# configure dehydrated
cd $ROOTDIR/dehydrated

echo "List the domains you want to setup with LetsEncrypt."
nano domains.txt

# Show the configured domains.
echo "Domains configured."
cat domains.txt

# configure your API keys
export GD_KEY=<not shown>
export GD_SECRET=<not shown>

# run letsencrypt.sh in "cron" mode (-c) this creates CSRs, keys and everything we need automatically for us.
./dehydrated -o $ROOTDIR/certs --challenge dns-01 -k $ROOTDIR/le-godaddy-dns/godaddy.py -c

echo "You should now have your certs, and the output should tell you where they are."
echo "Done."

Here is the script output with the actual domain name hidden:

Domains configured.
example.com www.example.com

#
# !! WARNING !! No main config file found, using default config!
#
y
To use dehydrated with this certificate authority you have to agree to their terms of service which you can find here: https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf

To accept these terms of service run `./dehydrated --register --accept-terms`.
You should now have your certs, and the output should tell you where they are.
Done.

Just Started Getting a 422 Error: 'message': 'is not a array'

This is what happens when I try and update certs. I was able to get this working a couple months ago but never got the automation setup. I've come back to finish setting this up as the keys will expire soon.

I pulled the latest commit from this repo and dehydrated. Running the script that previously worked, now gives the error below.

godaddypy.client.BadResponse: Response Data: {'message': "Request body doesn't fulfill schema, see details in `fields`", 'fields': [{'path': 'records', 'message': 'is not a array', 'code': 'UNEXPECTED_TYPE'}], 'code': 'INVALID_BODY'}

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

  • WARN: RepoCacheS3.read() - failure

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

github-actions
.github/workflows/ci.yml
  • actions/checkout v4
  • actions/setup-python v5
pip_requirements
requirements.txt
  • certifi ==2024.7.4
  • chardet ==5.2.0
  • GoDaddyPy ==2.4.1
  • idna ==3.7
  • requests ==2.32.3
  • urllib3 ==2.2.2
  • tld ==0.13

  • Check this box to trigger a request for Renovate to run again on this repository

Requirements Warning - requests / urllib3

Just tested and saw warnings from requests library. Currently it depends on having urllib3 to a maximum of 1.24.2.

Warning message:
.local/lib/python3.6/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.25.1) or chardet (3.0.4) doesn't match a supported version! RequestsDependencyWarning)

I tested and it worked ok for me but just in case, I will downgrade urllib3 to 1.24.2 requirements.txt for now so this does not throw off others.

Testing - Verify master

I have run tests of cert creation for some of my domains and it works fine with current master.

No module named

I am trying to get this hook working with dehydrated. I am running on Ubuntu 16.04 and am receiving the error:

"# INFO: Using main config file /etc/dehydrated/config
Traceback (most recent call last):
File "/etc/dehydrated/godaddy.py", line 6, in
from tld import get_tld
ImportError: No module named 'tld'"

Thank you in advanced.

DNS problem: NXDOMAIN looking up TXT for MX record

I have a prb while renewing cert. I even did sleep time in dehydated as 10 suggested in somewhere. However i'm unable to renew only one spesific subdomain : mail.mydomain.com
Rest seems to be renewed already due cron however today i realized my mail subdomain about to expire.

I don't have any issue with renewal of TXT records while my expiring MX record giving below error

#
# !! WARNING !! No main config file found, using default config!
#
 + Godaddy hook executing: startup_hook
Processing mydomain.com with alternative names: www.mydomain.com mail.mydomain.com sub.mydomain.com sub2.mydomain.com
 + Checking domain name(s) of existing cert... changed!
 + Domain name(s) are not matching!
 + Names in old certificate: sub3.mydomain.com sub4.mydomain.com sub.mydomain.com sub5.mydomain.com mail.mydomain.com www.mydomain.com sub2.mydomain.com mydomain.com
 + Configured names: sub.mydomain.com mail.mydomain.com www.mydomain.com sub2.mydomain.com mydomain.com
 + Forcing renew.
 + Checking expire date of existing cert...
 + Valid till Oct  8 20:31:00 2017 GMT Certificate will expire
(Less than 30 days). Renewing!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for mydomain.com...
 + Requesting challenge for www.mydomain.com...
 + Already validated!
 + Requesting challenge for mail.mydomain.com...
 + Already validated!
 + Requesting challenge for sub.mydomain.com...
 + Already validated!
 + Requesting challenge for sub2.mydomain.com...
 + Already validated!
 + Godaddy hook executing: deploy_challenge
 + Updating TXT record for _acme-challenge.mydomain.com to 'kvhgQZypkk_Hhgz1VW6w-xYrjbhg5liypevDGeJCOQac'.
 + Responding to challenge for mydomain.com...
 + Godaddy hook executing: clean_challenge
 + Updating TXT record for _acme-challenge.mydomain.com to 'null'.
 + Godaddy hook executing: invalid_challenge
 + invalid challenge for domain mydomain.com: {
  "type": "dns-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.mydomain.com",
    "status": 400
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/VghuhgJ9yu14do-g5hgrhawR5zUWqHPhgMSP26ZnaSsI/2153835867",
  "token": "...",
  "keyAuthorization": "..."
}
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "dns-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.mydomain.com",
    "status": 400
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/VghuhgJ9yu14do-g5hgrhawR5zUWqHPhgMSP26ZnaSsI/2153835867",
  "token": "...",
  "keyAuthorization": "..."
})

CVE-2024-35195 (Medium) detected in requests-2.31.0-py3-none-any.whl

CVE-2024-35195 - Medium Severity Vulnerability

Vulnerable Library - requests-2.31.0-py3-none-any.whl

Python HTTP for Humans.

Library home page: https://files.pythonhosted.org/packages/70/8e/0e2d847013cb52cd35b38c009bb167a1a26b2ce6cd6965bf26b47bc0bf44/requests-2.31.0-py3-none-any.whl

Path to dependency file: /requirements.txt

Path to vulnerable library: /requirements.txt

Dependency Hierarchy:

  • requests-2.31.0-py3-none-any.whl (Vulnerable Library)

Found in HEAD commit: 8dedc63fb01bbedc46b5d2dde66ce12860471791

Found in base branch: master

Vulnerability Details

Requests is a HTTP library. Prior to 2.32.2, when making requests through a Requests Session, if the first request is made with verify=False to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of verify. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.2.

Publish Date: 2024-05-20

URL: CVE-2024-35195

CVSS 3 Score Details (5.6)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Local
    • Attack Complexity: High
    • Privileges Required: High
    • User Interaction: Required
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: High
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-9wx4-h78v-vm56

Release Date: 2024-05-20

Fix Resolution: requests - 2.32.2


Step up your Open Source Security Game with Mend here

Script doesn't work but its giving me nowhere to look for

I'm running this script inside a brand new LXC container if that make any difference.
The cmds if done:
sudo apt-get install python3 python3-pip curl
git clone https://github.com/lukas2511/dehydrated
git clone https://github.com/josteink/le-godaddy-dns
cd $HOME/le-godaddy-dns
python3 -m pip install -r requirements.txt --user

Requirement already satisfied: certifi==2017.7.27.1 in /home/joeydc/.local/lib/python3.5/site-packages (from -r requirements.txt (line 1))
Requirement already satisfied: chardet==3.0.4 in /home/joeydc/.local/lib/python3.5/site-packages (from -r requirements.txt (line 2))
Requirement already satisfied: GoDaddyPy==2.2.5 in /home/joeydc/.local/lib/python3.5/site-packages (from -r requirements.txt (line 3))
Requirement already satisfied: idna==2.6 in /home/joeydc/.local/lib/python3.5/site-packages (from -r requirements.txt (line 4))
Requirement already satisfied: requests==2.18.4 in /home/joeydc/.local/lib/python3.5/site-packages (from -r requirements.txt (line 5))
Requirement already satisfied: urllib3==1.22 in /home/joeydc/.local/lib/python3.5/site-packages (from -r requirements.txt (line 6))
Requirement already satisfied: tld==0.7.9 in /home/joeydc/.local/lib/python3.5/site-packages (from -r requirements.txt (line 7))
Requirement already satisfied: six>=1.9 in /home/joeydc/.local/lib/python3.5/site-packages (from tld==0.7.9->-r requirements.txt (line 7))
$ cat $HOME/dehydrated/domains.txt
hass.joey.****.ca
$ cat $HOME/dehydrated/config
HOOK_CHAIN="yes"

export GD_KEY=*****
export GD_SECRET=*****

Here's all its giving me after running the script:

joeydc@letsencrypt:~/dehydrated$ ./dehydrated --challenge dns-01 -k $HOME/le-godaddy-dns/godaddy.py -c
# INFO: Using main config file /home/joeydc/dehydrated/config
 + Godaddy hook executing: ***********************
Traceback (most recent call last):
  File "/home/joeydc/le-godaddy-dns/godaddy.py", line 119, in <module>
    main(sys.argv[1:])
  File "/home/joeydc/le-godaddy-dns/godaddy.py", line 115, in main
    ops[argv[0]](argv[1:])
KeyError: '**********************'

Can you help me out with this please? Am i missing something here?

remove tld dependency

I just discovered by accident that tld fundamentally changed their API between current head version and 0.7.9. The new version of get_tld operates differently and causes an odd error downstream in call using godaddypy.

The issue with depending on an old version of this library is that we are polluting peoples libraries with an old version and if the same person has another library that requires a newer version, it will cause issues.

I suggest that we either align to the current version -or- remove the dependency and implement the code locally.

GoDaddy Propagation Delays

As this utility runs, it needs to set a TXT flag in the DNS infrastructure to allow LetsEncrypt to validate the certificate. Up until recently we had a 30 second wait time for this TXT flag to propagate and for the last several years, this had worked out well.

However, in a recent batch of certificates generated, I noticed errors from Dehydrated that the TXT key is invalid and was still showing the old (please delete me) value. It appears that some change(s) in GoDaddy's infrastructure causes some delays that were not seen before.

I will be posting a change to allow users to configure an override of this sleep time via an environment variable.

No hook for invalid challenge

There is no hook for invalid challenge.

 + Godaddy hook executing: invalid_challenge
Traceback (most recent call last):
  File "/home/rasmus/letsencrypt/le-godaddy-dns/godaddy.py", line 93, in <module>
    main(sys.argv[1:])
  File "/home/rasmus/letsencrypt/le-godaddy-dns/godaddy.py", line 89, in main
    ops[argv[0]](argv[1:])
KeyError: 'invalid_challenge'

See this issue for a solution.
kappataumu/letsencrypt-cloudflare-hook#26

Thank you for a great script :)

Setup Travis CI

Needs to setup .travis.yml file which pulls in required dependencies and runs "make all".

Should also add a Travis CI build-badge to readme.md, with SVG image-format.

Can not renew wildcard. Godaddy API error

When I try to renew my certificate I get:

+ add -or- update TXT '_acme-challenge.mydomain.com' to 'NlQfIx4jCfps4j2OWqGP7IciV_1_u95IKE1zWYD_RTQ'.
 + Add TXT record for _acme-challenge.mydomain.com | token = 'NlQfIx4jCfps4j2OWqGP7IciV_1_u95IKE1zWYD_RTQ' | zone = 'com' | godaddypy rec = '{'name': '_acme-challenge.mydomain', 'data': 'NlQfIx4jCfps4j2OWqGP7IciV_1_u95IKE1zWYD_RTQ', 'ttl': 600, 'type': 'TXT'}'
Error returned during add: Response Data: {'code': 'INVALID_BODY', 'fields': [{'code': 'MISMATCH_FORMAT', 'message': "does not conform to the 'domain' format, based on pattern: /^[^.]{1,63}(\\.[^.]{1,63})+$/", 'path': 'path.domain'}], 'message': "Request body doesn't fulfill schema, see details in `fields`"}.

Any idea where to look?

CVE-2019-9740 (Medium) detected in urllib3-1.24.2-py2.py3-none-any.whl

CVE-2019-9740 - Medium Severity Vulnerability

Vulnerable Library - urllib3-1.24.2-py2.py3-none-any.whl

HTTP library with thread-safe connection pooling, file post, and more.

Library home page: https://files.pythonhosted.org/packages/df/1c/59cca3abf96f991f2ec3131a4ffe72ae3d9ea1f5894abe8a9c5e3c77cfee/urllib3-1.24.2-py2.py3-none-any.whl

Path to dependency file: /tmp/ws-scm/le-godaddy-dns/requirements.txt

Path to vulnerable library: ource-ArchiveExtractor_5094bdf5-a1ad-418c-97a9-6d09b5827a54/20191002060038_65632/20191002060023_depth_0/urllib3-1.24.2-py2.py3-none-any/urllib3

Dependency Hierarchy:

  • requests-2.21.0-py2.py3-none-any.whl (Root Library)
    • urllib3-1.24.2-py2.py3-none-any.whl (Vulnerable Library)

Found in HEAD commit: b2e704abcb189749115cfece30f148d8b67412e0

Vulnerability Details

An issue was discovered in urllib2 in Python 2.x through 2.7.16 and urllib in Python 3.x through 3.7.3. CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the first argument to urllib.request.urlopen with \r\n (specifically in the query string after a ? character) followed by an HTTP header or a Redis command.

Publish Date: 2019-03-13

URL: CVE-2019-9740

CVSS 3 Score Details (6.1)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: Required
    • Scope: Changed
  • Impact Metrics:
    • Confidentiality Impact: Low
    • Integrity Impact: Low
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9740

Release Date: 2019-03-13

Fix Resolution: Python-3.7.4, Urllib3-1.24.3


Step up your Open Source Security Game with WhiteSource here

CVE-2019-11236 (Medium) detected in urllib3-1.24.2-py2.py3-none-any.whl

CVE-2019-11236 - Medium Severity Vulnerability

Vulnerable Library - urllib3-1.24.2-py2.py3-none-any.whl

HTTP library with thread-safe connection pooling, file post, and more.

Library home page: https://files.pythonhosted.org/packages/df/1c/59cca3abf96f991f2ec3131a4ffe72ae3d9ea1f5894abe8a9c5e3c77cfee/urllib3-1.24.2-py2.py3-none-any.whl

Path to dependency file: /le-godaddy-dns/requirements.txt

Path to vulnerable library: teSource-ArchiveExtractor_dbba7e30-8f23-4dcf-811c-bab5c055a393/20190616145138_66978/20190616145129_depth_0/urllib3-1.24.2-py2.py3-none-any/urllib3

Dependency Hierarchy:

  • urllib3-1.24.2-py2.py3-none-any.whl (Vulnerable Library)

Found in HEAD commit: 4cffab12612cbac2e711762a5f5cb4794c33e83f

Vulnerability Details

In the urllib3 library through 1.24.1 for Python, CRLF injection is possible if the attacker controls the request parameter.

Publish Date: 2019-04-15

URL: CVE-2019-11236

CVSS 3 Score Details (6.1)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: Required
    • Scope: Changed
  • Impact Metrics:
    • Confidentiality Impact: Low
    • Integrity Impact: Low
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11236

Release Date: 2019-04-15

Fix Resolution: 1.24.3


Step up your Open Source Security Game with WhiteSource here

CVE-2024-37891 (Medium) detected in urllib3-2.0.7-py3-none-any.whl

CVE-2024-37891 - Medium Severity Vulnerability

Vulnerable Library - urllib3-2.0.7-py3-none-any.whl

HTTP library with thread-safe connection pooling, file post, and more.

Library home page: https://files.pythonhosted.org/packages/d2/b2/b157855192a68541a91ba7b2bbcb91f1b4faa51f8bae38d8005c034be524/urllib3-2.0.7-py3-none-any.whl

Path to dependency file: /requirements.txt

Path to vulnerable library: /requirements.txt

Dependency Hierarchy:

  • urllib3-2.0.7-py3-none-any.whl (Vulnerable Library)

Found in HEAD commit: 3e6b3db57022befa03c6f875a544ae0aebf6e217

Found in base branch: master

Vulnerability Details

urllib3 is a user-friendly HTTP client library for Python. When using urllib3's proxy support with ProxyManager, the Proxy-Authorization header is only sent to the configured proxy, as expected. However, when sending HTTP requests without using urllib3's proxy support, it's possible to accidentally configure the Proxy-Authorization header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the Proxy-Authorization HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the Proxy-Authorization header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the Proxy-Authorization header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the Proxy-Authorization header without using urllib3's built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the Proxy-Authorization header with urllib3's ProxyManager, disable HTTP redirects using redirects=False when sending requests, or not user the Proxy-Authorization header as mitigations.

Publish Date: 2024-06-17

URL: CVE-2024-37891

CVSS 3 Score Details (4.4)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: High
    • Privileges Required: High
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: None
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-34jh-p97f-mpxf

Release Date: 2024-06-17

Fix Resolution: 2.2.2


Step up your Open Source Security Game with Mend here

Wildcard certificate issues

Just observed this:

Processing *.devops.blahblah.com with alternative names: devops.blahblah.com
 + Creating new directory /etc/dehydrated/certs/devops_blahblah_com ...
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for devops.blahblah.com
 + Handling authorization for devops.blahblah.com
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Godaddy hook executing: deploy_challenge
 + Updating TXT record for _acme-challenge.devops.blahblah.com to 'ngK9Tjbw7ZByLyiQNDUVRbQq2lLpDYlgVKtCvYp-EIE'.
 + Godaddy hook executing: deploy_challenge
 + Updating TXT record for _acme-challenge.blahblah.com to 'u2ikexgud3K1FwEdzIlFexJ6jCcWBBqBQ8bG4BNQBSw'.
 + Responding to challenge for devops.blahblah.com authorization...
 + Godaddy hook executing: invalid_challenge
 + invalid challenge for domain devops.blahblah.com: {
  "type": "dns-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:unauthorized",
    "detail": "Incorrect TXT record \"u2ikexgud3K1FwEdzIlFexJ6jCcWBBqBQ8bG4BNQBSw\" found at _acme-challenge.devops.blahblah.com",
    "status": 403
  },
  "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/v0mLhPO8IXvvI81cfghcbvYEjrhBr8VJAx-sqik5v_U/4750319446",
  "token": "IjysecxQRpN0NytBmhbkLglFJ7InGLUyoGZwWJOwPI0"
}
 + Cleaning challenge tokens...
 + Godaddy hook executing: clean_challenge
...
 + Challenge validation has failed :(

Pretty consistent while everything else works, but wildcard certs don't.

RequestsDependencyWarning: urllib3 (1.25.7) or chardet (3.0.4) doesn't match a supported version!

I'm getting the following warning when running ./dehydrated --challenge dns-01 -k $ROOTDIR/le-godaddy-dns/godaddy.py -c.

RequestsDependencyWarning: urllib3 (1.25.7) or chardet (3.0.4) doesn't match a supported version!

My certs are being generated like they should however I would like the get rid of this warning if possible.

I've updated urllib3. Running either pip show urllib3 or sudo pip show urllib3 is showing it's version as 1.25.7.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.