Weather Updates

I would like to propose the addition of a Weather Updates feature to your Station Guide website. This feature would include a weather widget that provides users with real-time information about the current weather conditions at the station.
Key Components:
Weather Widget: Integrate a user-friendly weather widget on the homepage and station pages, displaying essential information such as temperature, humidity, wind speed, and weather conditions (e.g., sunny, rainy, cloudy).
Location-Based Forecast: Utilize geolocation or allow users to enter their station location to display relevant weather forecasts for the specific area.
Extended Forecast: Offer a brief extended weather forecast for the upcoming days, helping users plan their journeys better and prepare for varying weather conditions.
Severe Weather Alerts: Include alerts for severe weather conditions that could affect train operations, such as storms or heavy snow, ensuring users are well-informed before they travel.
Benefits:
Improved Journey Planning: By providing real-time weather updates, users can make more informed decisions about their travel plans, ensuring they are prepared for the weather.
Enhanced User Experience: A weather feature adds valuable context to the travel experience, making the Station Guide website a more comprehensive resource for travellers.
Increased Engagement: Users are likely to return to the site for weather updates, fostering a habit of using our platform for all their travel-related needs.
By adding the Weather Updates feature, we can enhance the overall user experience on your Station Guide website, making it a more valuable tool for travellers.
Are you participating in GSSoC?

[ ✔] Yes
[ ] No

o noed of this for noe @snehas-05 find some diff issue


Error when deploying the app using zappa

Error botocore.errorfactory.NotFoundException: An error occurred (NotFoundException) when calling the GetRestApi operation: Invalid API identifier specified<PHONE_NUMBER>44:qiozpnwvc3
Context

I have no idea it started to crash at the final steps, earlier I had no issues related with deploying, now it started to crash. I think maybe it's because I aborted the deploying process while it was uploading due to my weak internet connection (because I'm in a different country at the moment)

I use venv and Python 3.9.
Expected Behavior

Deploy the app and give me the link to the API Gateway where I can do all the requests to my lambda function
Actual Behavior

It does deploy the function on AWS Lambda, but it doesn't work, it shows me this:
Traceback (most recent call last):
File "/Users/dumitrucucu/Desktop/clients/Adrian Nicolaev/app/fluency-py/venv/lib/python3.9/site-packages/zappa/cli.py", line 3033, in handle
sys.exit(cli.handle())
File "/Users/dumitrucucu/Desktop/clients/Adrian Nicolaev/app/fluency-py/venv/lib/python3.9/site-packages/zappa/cli.py", line 517, in handle
self.dispatch_command(self.command, stage)
File "/Users/dumitrucucu/Desktop/clients/Adrian Nicolaev/app/fluency-py/venv/lib/python3.9/site-packages/zappa/cli.py", line 559, in dispatch_command
self.deploy(self.vargs["zip"], self.vargs["docker_image_uri"])
File "/Users/dumitrucucu/Desktop/clients/Adrian Nicolaev/app/fluency-py/venv/lib/python3.9/site-packages/zappa/cli.py", line 877, in deploy
self.zappa.add_binary_support(api_id=api_id, cors=self.cors)
File "/Users/dumitrucucu/Desktop/clients/Adrian Nicolaev/app/fluency-py/venv/lib/python3.9/site-packages/zappa/core.py", line 1954, in add_binary_support
response = self.apigateway_client.get_rest_api(restApiId=api_id)
File "/Users/dumitrucucu/Desktop/clients/Adrian Nicolaev/app/fluency-py/venv/lib/python3.9/site-packages/botocore/client.py", line 508, in _api_call
return self._make_api_call(operation_name, kwargs)
File "/Users/dumitrucucu/Desktop/clients/Adrian Nicolaev/app/fluency-py/venv/lib/python3.9/site-packages/botocore/client.py", line 915, in _make_api_call
raise error_class(parsed_response, operation_name)
botocore.errorfactory.NotFoundException: An error occurred (NotFoundException) when calling the GetRestApi operation: Invalid API identifier specified<PHONE_NUMBER>44:qiozpnwvc3
Possible Fix

I have no idea how zappa works at a lower level, I suppose it uses some AWS Apis, and the error above demonstrates that there's some error when it tries to interact with the AWS Api on the final steps.
Steps to Reproduce

zappa update dev

Your Environment

Zappa version used:
0.55.0
Operating System and Python version:
Mac OS Monterey 12.2 (21D49) and Python 3.9
The output of pip freeze:
aes==1.0.0
aniso8601==9.0.1
argcomplete==2.0.0
atomicwrites==1.4.1
attrs==22.1.0
boto3==1.24.59
botocore==1.27.59
CacheControl==0.12.10
cachetools==5.0.0
certifi==2021.10.8
cffi==1.15.1
cfn-flip==1.3.0
charset-normalizer==2.0.12
click==8.1.2
crypto==1.4.1
cryptocode==0.1
cryptography==38.0.1
Deprecated==1.2.13
dnspython==2.2.1
durationpy==0.5
email-validator==1.1.3
firebase-admin==5.2.0
Flask==2.0.2
Flask-Cors==3.0.10
Flask-JWT-Extended==4.3.1
Flask-RESTful==0.3.9
google-api-core==2.7.2
google-api-python-client==2.44.0
google-auth==2.6.5
google-auth-httplib2==0.1.0
google-cloud-core==2.3.0
google-cloud-firestore==2.4.0
google-cloud-storage==2.3.0
google-crc32c==1.3.0
google-resumable-media==2.3.2
googleapis-common-protos==1.56.0
grpcio==1.44.0
grpcio-status==1.44.0
hjson==3.1.0
httplib2==0.20.4
idna==3.3
iniconfig==1.1.1
itsdangerous==2.1.2
Jinja2==3.1.1
jmespath==1.0.1
kappa==0.6.0
MarkupSafe==2.1.1
more-itertools==8.14.0
msgpack==1.0.3
Naked==0.1.31
names==0.3.0
packaging==21.3
password-validator==1.0
placebo==0.9.0
pluggy==0.13.1
proto-plus==1.20.3
protobuf==3.20.0
py==1.11.0
pyasn1==0.4.8
pyasn1-modules==0.2.8
pycparser==2.21
pycrypto==2.6.1
pycryptodomex==3.14.1
pydash==5.1.0
PyJWT==2.3.0
pyparsing==3.0.8
pytest==4.6.11
pytest-requests==0.3.0
python-dateutil==2.8.2
python-dotenv==0.20.0
python-i18n==0.3.9
python-random-name-generator==0.0.6
python-slugify==6.1.2
pytz==2022.1
PyYAML==6.0
requests==2.27.1
rsa==4.8
s3transfer==0.6.0
shellescape==3.8.1
six==1.16.0
text-unidecode==1.3
toml==0.10.2
tomli==2.0.1
tqdm==4.64.0
trafaret==2.1.1
troposphere==4.1.0
twilio==7.8.1
uritemplate==4.1.1
urllib3==1.26.9
vonage==3.0.0
wcwidth==0.2.5
Werkzeug==2.1.1
wrapt==1.14.1
wsgi-request-logger==0.4.6
zappa==0.55.0
Link to your project (optional):

(private source)

Your zappa_settings.json:
{
"dev": {
"app_function": "app.app",
"profile_name": "default",
"project_name": "fluency-py",
"runtime": "python3.9",
"s3_bucket": "zappa-qms1bxy5b",
"aws_region": "us-east-1"
}
}

Please any help will be highly appreciated! This task is time sensitive for me, and I already spent 2 days trying to figure out the problem, I've deleted everything from AWS Lambda, S3, API gateway, reinstalled zappa, and done an re init, maybe that's because I have some conflicting modules? Thanks

@dumitruPuggle  delete cloudformattion stack and deployed lambda function manually and try to redeploy the function.

Waiting for stack fluency-py-dev to create (this can take a bit)..
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████| 4/4 [00:17<00:00,  4.30s/res]
Deploying API Gateway..
Waiting for lambda function [fluency-py-dev] to be updated...
Error: Warning! Status check on the deployed lambda failed. A GET request to '/' yielded a 502 response code.

At least it didn't crash like it did before, but there is a new problem.

zappa tail:

Okay, I get it. There's a problem with a conflicting module. Probably the cryptocode module was trying to connect with native OS bindings and stuff like that and eventually the lambda doesn't support that. A similar situation with Node.js bcrypt library.

Okay, I get it. There's a problem with a conflicting module. Probably the cryptocode module was trying to connect with native OS bindings and stuff like that and eventually the lambda doesn't support that. A similar situation with Node.js bcrypt library.

I will try to find an different module that does the same thing

Looks like a problem with the libraries used in your application.
Is it ok to close this issue?

Here's one more strange thing. All these modules were working perfectly before with zappa. Suddenly, new bugs and errors started to appear. Right now, there's another conflicting module:
ImportError: Failed to import the Cloud Firestore library for Python. Make sure to install the "google-cloud-firestore" module.
Again, all these modules were working perfectly earlier, and I was able to deploy them.

Thanks for the help especially with Cloud Formation, I fixed my conflicting modules, now here's the result:

Guys, is there an way to test the zappa locally?

Thanks!


Support for Strato Let'e Encrypt DNS challenge

What provider would you like to see added to NPM?
Strato
Have you checked if a certbot plugin exists?
I found this here:
https://github.com/Buxdehuda/strato-certbot

Unfortunately the current version of NPM only supports DNS-challenge providers which have a certbot dns plugin. The link you posted is only a manual auth hook certbot integration, which is not supported. And it seems there currently is no actual certbot dns plugin.

For others with the same problem:
Not a certbot dns plugin, but I've got it managed to get a wildcart cert with the workaround mentioned here:

Setup proxy host in NPM (Nginx Proxy Manager) for both domain and wildcard subdomain

Setup SSL certificate for just the domain (wildcard input is currently not possible).

Up until here you should have SSL working for the domain, but not the subdomains.

In my case NginxProxyManager is a Docker-Container running on Unraid, so /config ist mounted to /mnt/user/appdata/NginxProxyManager

Copy auth-hook.py to /config/letsencrypt/renewal-hooks/deploy/

Make auth-hook.py executable:
chmod a+x /config/letsencrypt/renewal-hooks/deploy/auth-hook.py

Create strato-auth.json in /config/letsencrypt/renewal-hooks/deploy/
{
  "username": "<username>",
  "password": "<password>"
}

Replace with open("strato-auth.json") as file: in /config/letsencrypt/renewal-hooks/deploy/auth-hook.py with with open ("/config/letsencrypt/renewal-hooks/deploy/strato-auth.json") as file:

Change permissions:
chmod 0400 /config/letsencrypt/renewal-hooks/deploy/strato-auth.json

Modify /config/letsencrypt/renewal/npm-.conf and update the section [renewalparams]:
authenticator = manual
manual_public_ip_logging_ok = True
manual_auth_hook = /config/letsencrypt/renewal-hooks/deploy/auth-hook.py

Extend the certificate (replace <domain>):
certbot certonly --manual --cert-name npm-5 --expand -d <domain>,*.<domain> --manual-auth-hook=/config/letse ncrypt/renewal-hooks/deploy/auth-hook.py

Now the cert setup in step 2. contains an wildcard-alias an can be assigned to the wildcard subdomain from step 1.
I hope this help some.

Extend the certificate (replace <domain>):
certbot certonly --manual --cert-name npm-5 --expand -d <domain>,*.<domain> --manual-auth-hook=/config/letse ncrypt/renewal-hooks/deploy/auth-hook.py

Thanks for your how to.
Will this automaticly update the certificate every 90 days or have I do this manualy?
Or is there a way to execute the command mentioned unter 10 every n days?
Thanks a lot.

Will this automaticly update the certificate every 90 days or have I do this manualy?

When the SSL certificate is created in step 2, NPP automatically creates a job that regularly renews the certificate.

Hi, some things i have noticed.
(All files mentioned come from here: https://github.com/Buxdehuda/strato-certbot=

First of, it look's like the auth-hook.py hast changed, point 7. isn't requiered anymore, with open has been removed/replaced.
There is a new include, so you will need the file certbotstratoapi.py
you need to install the requirements listed under requirements.txt

Okay, after this, your workaround works, but i get this error message, even so the certificate generation works:
After issuing point 8. of the workaround i get this output.
[...]
Renewing an existing certificate for grenzzone.de and *.grenzzone.de
Hook 'deploy-hook' reported error code 1
Hook 'deploy-hook' ran with error output:
Traceback (most recent call last):
File "/etc/letsencrypt/renewal-hooks/deploy/auth-hook.py", line 42, in
main()
File "/etc/letsencrypt/renewal-hooks/deploy/auth-hook.py", line 25, in main
strato = CertbotStratoApi()
File "/etc/letsencrypt/renewal-hooks/deploy/certbotstratoapi.py", line 17, in init
self.txt_value = os.environ['CERTBOT_VALIDATION']
File "/usr/lib/python3.7/os.py", line 678, in getitem
raise KeyError(key) from None
KeyError: 'CERTBOT_VALIDATION'
Successfully received certificate.
[...]
Any ideas?

I modified the code from the aforementioned repository to provide a regular certbot dns authentication plugin, which can be directly integrated into NPM (see here).
If you would like to give it a try, follow these instructions.
The dns plugin configuration in globals/certbot-dns-plugins.js should be adjusted to include the service for Strato:
.
.
.
    //####################################################//
    strato: {
        display_name:        'Strato',
        package_name:        'certbot-dns-strato',
        version_requirement: '~=0.1.1',
        dependencies:        '',
        credentials:         `dns_strato_username = user
dns_strato_password = pass
# uncomment if domain name contains special characters
# insert domain display name as seen on your account page here
# dns_strato_domain_display_name = my-punicode-url.de`,
        full_plugin_name:    'dns-strato',
    },
.
.
.

I was successful using option 2 mentioned in the linked comment.
An exemplary docker-compose.yml could be:
version: '3'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: always
    ports:
      - '80:80'
      - '1080:81'
      - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
      # map custom code into the container to support strato dns
      - ./custom-npm/global/certbot-dns-plugins.js:/app/global/certbot-dns-plugins.js:ro
      - ./custom-npm/frontend/dist:/app/frontend:ro

networks:
  default:
    external: true
    name: nginx-proxy-manager

Note that the code is still in an experimental stage.

Nice work. :)
Where do i need to place the files from your repository?

Nice work. :)
Where do i need to place the files from your repository?

Thank you :-)
You don't need to touch my repository -- it is just a place for the plugin to live. The code is uploaded to PyPi so it is available from anywhere where there is python pip installed. Thus npm can grab it by itself. You just need to introduce this plugin to npm by inserting the given configuration snippet posted above and then building the npm frontend from this repository.
Once that's done, you can use the build directory and mount it into your docker container at the specific location where the prebuilt frontend was living (you basically shadow it with the new version).
Then you're good to go. In fact I have this setup up and running since my post without any issues :-)
So what you need to do:

clone this repository (nginx-proxy-manager, not my plugin)
edit globals/certbot-dns-plugins.js as shown above.
rebuild the npm frontend using the provided build script: sudo ./scripts/frontend-build
mount the new version into your container using the docker-compose.yml as shown above (make sure to adjust the paths to point your local custom build. In my case it's located in ./custom-npm/)

(-: Hope this helps

Thank you. :)
You Pull requests got answered: https://github.com/NginxProxyManager/nginx-proxy-manager/pull/2929#issuecomment-1553032491

Hi guys,
i postet this also in the Pull Request but dont know if anyone sees this there:
i read this and wanted to try it out but i think i dont get it...
how and what for things do i have to put in the challange textfield?
also my strato is locked with 2fa
is there an example file i can use?
sorry but i dont understand the things under user and pass...
and for the SSL Domain i need "*.DOMAIN.COM"? or without the * for wildcard?
this is the example:
dns_strato_username = user
dns_strato_password = pass
'# uncomment if domain name contains special characters
'# insert domain display name as seen on your account page here
'# dns_strato_domain_display_name = my-punicode-url.de
and now how to fill it?
the last two i dont understand...
do i have to remove the # and fill in something?
if i do i get an error....
i testet with:
'*.DOMAIN.com
dns_strato_username = NUMBERS
dns_strato_password = PASSWORD
dns_strato_totp_secret = BUNCH OF NUMBERS AND CARACTERS
dns_strato_totp_devicename = NAME OF TOTP
'# uncomment if domain name contains special characters <-- Leav this as it was
'# DOMAIN.COM
'# dns_strato_domain_display_name = *.DOMAIN.COM
pls help or point me a good example from someone who got it to work. it would be easier then the normal challenge then there are at time internal errors -,- (new request worked...)
thank you so much...
EDIT: have to put ' infront of # to avoid funky things...

sorry but i dont understand the things under user and pass... and for the SSL Domain i need "*.DOMAIN.COM"? or without the * for wildcard?

In the topmost field of the basic certificate settings it should say *.domain.com (the CN, the certificate is issued for).
In the custom configuration for strato dns you only need to add your domain name, if it has special characters in it (aka punycode). If that's the case you need to enter the name in the exact same spelling as it appears on your strato domain configuration overview page (on strato.de it's called "Paketübersicht"). In my case it shows without the asterisk. Otherwise, so if you do not provide the dns_strato_domain_display_name, it is inferred from your CN.
I guess you already tried both variants, rights? If that's the case, I might have spotted an error with TFA.
It might be a problem in the code of my python certbot plugin, where the credentials setup function does not include the totp keys.
Since I did not configure it yet (shame on me), this didn't come to light.
Your configuration looks correct:

dns_strato_totp_secret = BUNCH OF NUMBERS AND CARACTERS
dns_strato_totp_devicename = NAME OF TOTP

Please try as I explained, if you did not already do so and report back. Then I will proceed to making the adjustments in code.
Cheers

hi ho and thx for the answer,
ok then i think its easier to work with pictures...
i testet a lot, but i always get an Error so hier my config (as i understand from your text):

and this is the error i get:
Error: Command failed: certbot certonly --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name "npm-30" --agree-tos --email "jxxxxxxxxxx.com" --domains "*.hxxxxxxxxxx.com" --authenticator dns-strato --dns-strato-credentials "/etc/letsencrypt/credentials/credentials-30" Saving debug log to /tmp/letsencrypt-log/letsencrypt.log
`at ChildProcess.exithandler (node:child_process:402:12)
at ChildProcess.emit (node:events:513:28)
at maybeClose (node:internal/child_process:1100:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5)`

Do i have to put something in Strato first? i own the domain but is something to do for the wildcard *.hxxxxxxx.com SSL Cert?
Thank you for your help :)

I am sorry, I didn’t have time to do it as I am currently on vacation. I’ll be back in September.

I tried the same @Yoshi315161, but im getting the same error.
I tried both with a wildcard and a specific hostname, both gave the same childprocess error.
I disabled TOTP and tried, but same problem.
Maybe strato changed something.
Is there something i can look for in the debug log?

Hey all, sorry for the late reply. I did not know, that strato was serving their page in other countries than Germany. So this actually might be cause for troubles with some users.
In the recent commit I added the option to fully customise the API endpoint:

custom_api_scheme,
custom_api_host,
custom_api_port and
custom_api_path

You will probably only set the custom_api_host, but yeah, might be nice to have in the future...
I have just published a new version of the certbot strato dns challenge pypi package:
Please pip install this package and test whether your TXT records show up on Strato Management Site.
You can use this snippet for testing:
from certbot_dns_strato.dns_strato import _StratoApi

# change the placeholders and api host to match the one you are logging in to (e.g. '.nl' for the Netherlands).
strato = _StratoApi('your_domain_display_name', custom_api_host='www.strato.nl')
strato.login('my_username', 'my_password')

strato.set_domain_name('your_domain_name')
strato.get_package_id()
strato.get_txt_records()
strato.set_amce_record('hello', 'world')
strato.push_txt_records()

The result should look like this:

I hope the NPM auto-updates the package soon, so you'll be able to use the additional options from inside NPM.
Don't forget to add the mandatory prefix in your NPM wildcard certificate configuration dns_strato_. So custom_api_host needs to be set as dns_strato_custom_api_host = www.strato.nl(e.g. for the Netherlands).
Also please let me know, if this fixes the problem for you, @Yoshi315161.
And thank you @ThomasKuijper so much for investigating.
Cheers

Hey @FlixMa,
i hope you had a good vacation. My Strato is also in Germany.
I only updated the pip installation and now its working without changing anything..
AWESOME :)
now i have a wildcard with DNS Challange :D (and TOPT)
Thank you so much
my config is the same like the picture above the only difference is that i deletet the last three lines.

Hey @Yoshi315161, vacation was alright; thanks for asking. Glad to hear you got it working. Then the issue might actually have been that the 2FA detection was not only broken for other countries, but also for strato.de. That is actually very likely as it was based on user-facing string matching, which of course might change more frequently than an API. I did. change that behaviour to be based on whether you provide 2FA credentials or not, to make it compatible with other languages.
Do you mind sharing how you updated the pip package inside your NPM docker container? This way others can profit as well :)
Have a nice weekend!

Ofcourse I can.
I have portainer installed in my Docker server.
So I Bash into the NPM Container and just Copied the install Bash from your link and press Enter:
pip install certbot-dns-strato==0.2.0
After that I tested again in NPM and it worked.
You too :)

So what you need to do:
1. clone this repository (nginx-proxy-manager, not my plugin)

2. edit `globals/certbot-dns-plugins.js` as shown above.

3. rebuild the npm frontend using the provided build script: `sudo ./scripts/frontend-build`

4. mount the new version into your container using the `docker-compose.yml` as shown above (make sure to adjust the paths to point your local custom build. In my case it's located in `./custom-npm/`)

Hi, when I run:
sudo ./scripts/frontend-build
sudo: ./scripts/frontend-build: command not found
frontend-build file does not exist
Any suggestion

The script has been moved to a subfolder: scripts/ci/frontend-build
I am not sure if it will work, though. There might have been other breaking changes since spring 2023.
But may I ask, why you want to use those steps? The plugin should already show up without any additional changes since #2929 got merged. So you probably don’t need to build it for yourself :)

I have updated to the latest version 2.10.4 and I have already seen it
Now I will do tests
Thank you

When I try to create an SSL certificate it gives an error:
Error: Command failed: certbot certonly --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name "npm-1" --agree-tos --email<EMAIL_ADDRESS>--domains "xxxxxxxxx.es" --authenticator dns-strato --dns-strato-credentials "/etc/letsencrypt/credentials/credentials-1" Saving debug log to /tmp/letsencrypt-log/letsencrypt.log
    at ChildProcess.exithandler (node:child_process:402:12)     at ChildProcess.emit (node:events:513:28)     at maybeClose (node:internal/child_process:1100:16)     at Socket. (node:internal/child_process:458:11)     at Socket.emit (node:events:513:28)     at Pipe. (node:net:301:12)

Ofcourse I can. I have portainer installed in my Docker server. So I Bash into the NPM Container and just Copied the install Bash from your link and press Enter: pip install certbot-dns-strato==0.2.0
After that I tested again in NPM and it worked.
You too :)

I have also updated to version 0.2.0 from Portainer

Unfortunately I haven't seen this error before. You can try to have a look into the debug log. There might be useful information inside. If you are unsure if this has to do with the strato plugin itself, you might want to post a new issue.

It's already solved.
It is necessary to put in the Credentials File Content section:
dns_strato_custom_api_host = www.strato.es
In case it helps anyone :)

I added a more descriptive configuration template to simplify onboarding for new users. See pull request #3212 for more information.

looks as if this is broken again...
i think the get_package_id method is not able to find the package ID.
Maybe we could get completely rid of the method - or provide an override - and read an additional config field "dns_strato_package_id"?

Mine is still working...
Do you have updated your NPM Container?
If yes, you have to update the internal:
pip install certbot-dns-strato==0.2.0
again
its not importet yet...
sad because there were two container updates till now...

Now there was an update with your implementation BUT now it doesnt work anymore…
and i can also do not update with pip because there is an error with command not found…

Dear @FlixMa,
today I updated to Nginx Proxy Manager 2.11, which includes your fix as documented in the release notes.
Just got the same error as @Yoshi315161.
Thank you for any help.
Thomas

@Yoshi315161
Just to clarify. Is there anything special you have configure on the Strato side?

Hey all,
apparently Strato did change the way of accessing the individual packages.
In the past this was done through an absolute package id. Now this changed to incrementing numbers per account.
Hopefully the uploaded fix 0.2.1 will account for that. The tests on my end are looking fine.
Please try to update the pip package and let me know :-)
Felix

hey @FlixMa,
i tried to bash into console and do the pip install certbot-dns-strato==0.2.1 but i got the bash: pip: command not found
i think on the debian was something changed.. how to you got the update in your NPM container?
@thomas292
no i have nothing changed in strato

Hey,
to change the version of certbot plugin
the version has to be changes in the file global/certbot-dns-plugins.json.
This can either be done temporarily in the container
(exec into container, edit /app/global/certbot-dns-plugins.json, restart container)
or permanently by creating a custom image that inherits from the official image
(override /app/global/certbot-dns-plugins.json).
Search for this part and replace version with your desired version:
...
"strato": {
	"name": "Strato",
	"package_name": "certbot-dns-strato",
-->	"version": "~=0.1.1",
	"dependencies": "",
	"credentials": "dns_strato_username = user\ndns_strato_password = pass\n# uncomment if youre using two factor authentication:\n# dns_strato_totp_devicename = 2fa_device\n# dns_strato_totp_secret = 2fa_secret\n#\n# uncomment if domain name contains special characters\n# insert domain display name as seen on your account page here\n# dns_strato_domain_display_name = my-punicode-url.de\n#\n# if youre not using strato.de or another special endpoint you can customise it below\n# you will probably only need to adjust the host, but you can also change the complete endpoint url\n# dns_strato_custom_api_scheme = https\n# dns_strato_custom_api_host = www.strato.de\n# dns_strato_custom_api_port = 443\n# dns_strato_custom_api_path = \"/apps/CustomerService\"",
	"full_plugin_name": "dns-strato"
},
...

Disclaimer: I have not explicitly tested this fix

With Version 0.2.1 it is still not working.

Same here.
cat global/certbot-dns-plugins.json
"strato": {
                "name": "Strato",
                "package_name": "certbot-dns-strato",
                "version": "~=0.2.1",
                "dependencies": "",
                "credentials": "dns_strato_username = user\ndns_strato_password = pass\n# uncomment if youre using two factor authentication:\n# dns_strato_totp_devicename = 2fa_device\n# dns_strato_totp_secret = 2fa_secret\n#\n# uncomment if domain name contains special characters\n# insert domain display name as seen on your account page here\n# dns_strato_domain_display_name = my-punicode-url.de\n#\n# if youre not using strato.de or another special endpoint you can customise it below\n# you will probably only need to adjust the host, but you can also change the complete endpoint url\n# dns_strato_custom_api_scheme = https\n# dns_strato_custom_api_host = www.strato.de\n# dns_strato_custom_api_port = 443\n# dns_strato_custom_api_path = \"/apps/CustomerService\"",
                "full_plugin_name": "dns-strato"

also used
 pip install certbot-dns-strato==0.2.1
Requirement already satisfied: certbot-dns-strato==0.2.1 in /opt/certbot/lib/python3.11/site-packages (0.2.1)
Requirement already satisfied: setuptools in /opt/certbot/lib/python3.11/site-packages (from certbot-dns-strato==0.2.1) (66.1.1)
Requirement already satisfied: certbot>=2.0 in /opt/certbot/lib/python3.11/site-packages (from certbot-dns-strato==0.2.1) (2.8.0)
Requirement already satisfied: requests in /opt/certbot/lib/python3.11/site-packages (from certbot-dns-strato==0.2.1) (2.31.0)
Requirement already satisfied: pyotp in /opt/certbot/lib/python3.11/site-packages (from certbot-dns-strato==0.2.1) (2.9.0)
Requirement already satisfied: acme>=2.8.0 in /opt/certbot/lib/python3.11/site-packages (from certbot>=2.0->certbot-dns-strato==0.2.1) (2.8.0)
Requirement already satisfied: ConfigArgParse>=1.5.3 in /opt/certbot/lib/python3.11/site-packages (from certbot>=2.0->certbot-dns-strato==0.2.1) (1.7)
Requirement already satisfied: configobj>=5.0.6 in /opt/certbot/lib/python3.11/site-packages (from certbot>=2.0->certbot-dns-strato==0.2.1) (5.0.8)
Requirement already satisfied: cryptography>=3.2.1 in /opt/certbot/lib/python3.11/site-packages (from certbot>=2.0->certbot-dns-strato==0.2.1) (41.0.7)
Requirement already satisfied: distro>=1.0.1 in /opt/certbot/lib/python3.11/site-packages (from certbot>=2.0->certbot-dns-strato==0.2.1) (1.9.0)
Requirement already satisfied: josepy>=1.13.0 in /opt/certbot/lib/python3.11/site-packages (from certbot>=2.0->certbot-dns-strato==0.2.1) (1.14.0)
Requirement already satisfied: parsedatetime>=2.4 in /opt/certbot/lib/python3.11/site-packages (from certbot>=2.0->certbot-dns-strato==0.2.1) (2.6)
Requirement already satisfied: pyrfc3339 in /opt/certbot/lib/python3.11/site-packages (from certbot>=2.0->certbot-dns-strato==0.2.1) (1.1)
Requirement already satisfied: pytz>=2019.3 in /opt/certbot/lib/python3.11/site-packages (from certbot>=2.0->certbot-dns-strato==0.2.1) (2023.3.post1)
Requirement already satisfied: charset-normalizer<4,>=2 in /opt/certbot/lib/python3.11/site-packages (from requests->certbot-dns-strato==0.2.1) (3.3.2)
Requirement already satisfied: idna<4,>=2.5 in /opt/certbot/lib/python3.11/site-packages (from requests->certbot-dns-strato==0.2.1) (3.6)
Requirement already satisfied: urllib3<3,>=1.21.1 in /opt/certbot/lib/python3.11/site-packages (from requests->certbot-dns-strato==0.2.1) (2.1.0)
Requirement already satisfied: certifi>=2017.4.17 in /opt/certbot/lib/python3.11/site-packages (from requests->certbot-dns-strato==0.2.1) (2023.11.17)
Requirement already satisfied: PyOpenSSL!=23.1.0,>=17.5.0 in /opt/certbot/lib/python3.11/site-packages (from acme>=2.8.0->certbot>=2.0->certbot-dns-strato==0.2.1) (23.3.0)
Requirement already satisfied: six in /opt/certbot/lib/python3.11/site-packages (from configobj>=5.0.6->certbot>=2.0->certbot-dns-strato==0.2.1) (1.16.0)
Requirement already satisfied: cffi>=1.12 in /opt/certbot/lib/python3.11/site-packages (from cryptography>=3.2.1->certbot>=2.0->certbot-dns-strato==0.2.1) (1.16.0)
Requirement already satisfied: pycparser in /opt/certbot/lib/python3.11/site-packages (from cffi>=1.12->cryptography>=3.2.1->certbot>=2.0->certbot-dns-strato==0.2.1) (2.21)

Only get internal error

I got it working now with the latest NPM in Docker:

exec in to the container
apt update
apt install pip
apt install nano
pip install certbot-dns-strato==0.2.1
nano certbot-dns-plugins.json
change the version from Strato 0.1.1 to 0,2.1 and save it
restart the container
Request a new Wildcard within NPM

Hope that helps
Cheers
Tom

Update: It worked with one certificat. The next one seems to timed out and after that one instantly internal errors :/

This is very odd behaviour I haven’t seen so far.
Maybe you have to colliding renewals at the same time? If so try to only renew once the othe process did finish.

Hi, thank you for your plugin. When I first tried, i didn't work and I tried it manually with certbot the see how all this stuff actually works and it worked. There is a little issue with reading the password. Passwords beginning with '#' are not working. Guess it is interpreted as commentary. With updateing to version0.2.1 of your plugin it finally worked here for me, but the issue with passwords starting with # is still there.
kind regards,
robert

the issue with passwords starting with # is still there.

Please try using quotes around it like so dns_strato_password = "#mysupersecretpassword". Otherwise I guess the only option to get it working is to change the password to not include such problematic characters.

I got it working now with the latest NPM in Docker:

exec in to the container
apt update
apt install pip
apt install nano
pip install certbot-dns-strato==0.2.1
nano certbot-dns-plugins.json
change the version from Strato 0.1.1 to 0,2.1 and save it
restart the container
Request a new Wildcard within NPM

Hope that helps Cheers Tom

how do you get pip install cert...... to work? i only get this error...

Which username and password are used?
The one to login into my account or the one which is used to login into dyndns?

Hi, just use your credentials that you use to login on the strato service portal.
kind regards.

Update: It worked with one certificat. The next one seems to timed out and after that one instantly internal errors :/

Try setting the propagation time to 60 seconds or longer. When manually using Certbot with the DNS-01 challenge, you will see a message instructing you to wait for a specified amount of time after entering the provided key (challenge) into the CNAME field. Another possible issue could be the plugin itself. Since it employs web scraping techniques to log into your account and automate tasks, the webpage may not fully load. As a result, the plugin might not be able to locate the required HTML/CSS tags. Generally, most websites do not appreciate being scraped and have protections against it. This is why libraries such as Puppeteer (Node.js) offer proxy settings, as well as delay and wait mechanisms for web scraping.
kind regards.

I got it working now with the latest NPM in Docker:
Hope that helps Cheers Tom

Thank you so mutch! Its working again.

I got it working now with the latest NPM in Docker:
Hope that helps Cheers Tom

Thank you so mutch! Its working again.

Can you explain how?
I am stuck at the point with pip install… i always got an error…

I got it working now with the latest NPM in Docker:
Hope that helps Cheers Tom

Thank you so mutch! Its working again.

Can you explain how? I am stuck at the point with pip install… i always got an error…

I followed the instructions step by step, and it worked in the end. I had no error, sry.

Can you explain how? I am stuck at the point with pip install… i always got an error…

Hey @Yoshi315161, did you try the suggestion at the end of the error message?
the Strato package doesn’t need to much dependencies. Good chance, nothing will break. Just saying that it might be worth a try, just make sure to have a backup.

Ok got it to work now
Thx for the hint FlixMa :)
If someone have the same problems with the error:

exec in to the container
apt update
apt install pip
apt install nano
pip install certbot-dns-strato==0.2.1 --break-system-packages
cd global/
nano certbot-dns-plugins.json
change the version from Strato 0.1.1 to 0.2.1 and save it
restart the container
Request a new Wildcard within NPM

The cID is determined automatically by the domain name you specify in the configuration.
It is wrong to add it to the custom path. Is your cid 0 or 1 or something way higher like 6-digits? Strato did change this behaviour and broke it for my setup some weeks ago, but I thought I fixed that.

Joining here as the steps provided didnt fix the issue :(

Hey all, apparently Strato did change the way of accessing the individual packages. In the past this was done through an absolute package id. Now this changed to incrementing numbers per account.
Hopefully the uploaded fix 0.2.1 will account for that. The tests on my end are looking fine. Please try to update the pip package and let me know :-) Felix

Thanks a lot. Updated NPM to v2.11.1 and updated the certbot-dns-strato to fix 0.2.1. I instatly was able to renew my wildcard certificat.

I tried it once again but it didn't work
my Config is:
dns_strato_username = "myloginnumber" dns_strato_password = "mySecretPasswordWitha$asSpecialChar"
The log gives the following output
2024-02-20 14:29:12,215:DEBUG:acme.client:Storing nonce: 1pTQTQeXzVAON8O3Q591coWeQUvKkxzhPFA_m3dQMlrt4jo7VBI
2024-02-20 14:29:12,218:INFO:certbot._internal.auth_handler:Performing the following challenges:
2024-02-20 14:29:12,219:INFO:certbot._internal.auth_handler:dns-01 challenge for mydomain.de
2024-02-20 14:29:12,228:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): www.strato.de:443
2024-02-20 14:29:12,528:DEBUG:urllib3.connectionpool:https://www.strato.de:443 "GET /apps/CustomerService HTTP/1.1" 200 None
2024-02-20 14:29:13,011:DEBUG:urllib3.connectionpool:https://www.strato.de:443 "POST /apps/CustomerService HTTP/1.1" 302 0
2024-02-20 14:29:13,082:DEBUG:urllib3.connectionpool:https://www.strato.de:443 "GET /apps/CustomerService?sessionID=5dc882acc8846e453a5e95c7019079&node=kds_CustomerEntryPage&cID=0&swtssa=gerbksnst0000000000000000 HTTP/1.1" 200 None
2024-02-20 14:29:13,146:DEBUG:urllib3.connectionpool:https://www.strato.de:443 "GET /apps/CustomerService?sessionID=5dc882acc8846e453a5e95c7019079&cID=0&node=kds_CustomerEntryPage HTTP/1.1" 200 None

As you can see my cID above is 0 when I login into my account the cID is 1.
Maybe this is my problem.

Ok got it to work now Thx for the hint FlixMa :) If someone have the same problems with the error:
1. exec in to the container

2. apt update

3. apt install pip

4. apt install nano

5. pip install certbot-dns-strato==0.2.1 --break-system-packages

6. cd global/

7. nano certbot-dns-plugins.json

8. change the version from Strato 0.1.1 to 0.2.1 and save it

9. restart the container

10. Request a new Wildcard within NPM

This helped in my case, thanks for the steps!

Trying to setup a new LXC on proxmox but cannot get it to run. Requesting single domain certificates is working fine, but DNS challenge with strato isn't.
Already updated certbot-dns-strato, modified certbot-dns-plugins.json etc. but no success.
2FA is NOT activated & no '#' inside my password.
NPM: v2.11.1
Details

dns_strato_username = "XXXXX"
dns_strato_password = "XXXXXXXXXXXX"
#uncomment if youre using two factor authentication:
#dns_strato_totp_devicename = 2fa_device
#dns_strato_totp_secret = 2fa_secret
#
#uncomment if domain name contains special characters
#insert domain display name as seen on your account page here
#dns_strato_domain_display_name = my-punicode-url.de
#
#if youre not using strato.de or another special endpoint you can customise it below
#you will probably only need to adjust the host, but you can also change the complete endpoint url
#dns_strato_custom_api_scheme = https
#dns_strato_custom_api_host = www.strato.de
#dns_strato_custom_api_port = 443
#dns_strato_custom_api_path = "/apps/CustomerService"

Error in NPM

CommandError: Saving debug log to /tmp/letsencrypt-log/letsencrypt.log

    at /app/lib/utils.js:16:13
    at ChildProcess.exithandler (node:child_process:410:5)
    at ChildProcess.emit (node:events:513:28)
    at maybeClose (node:internal/child_process:1100:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5)

letsencrypt.log

2024-03-01 14:41:04,687:DEBUG:certbot._internal.main:certbot version: 2.1.0
2024-03-01 14:41:04,687:DEBUG:certbot._internal.main:Location of certbot entry point: /usr/bin/certbot
2024-03-01 14:41:04,687:DEBUG:certbot._internal.main:Arguments: ['--config', '/etc/letsencrypt.ini', '--work-dir', '/tmp/letsencrypt-lib', '--logs-dir', '/tmp/letsencrypt-log', '--cert-name', 'npm-3', '--agree-tos', '--email'<EMAIL_ADDRESS>'--domains', 'XXXXX.de', '--authenticator', 'dns-strato', '--dns-strato-credentials', '/etc/letsencrypt/credentials/credentials-3']
2024-03-01 14:41:04,687:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#dns-cloudflare,PluginEntryPoint#dns-duckdns,PluginEntryPoint#dns-porkbun,PluginEntryPoint#dns-strato,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2024-03-01 14:41:04,693:DEBUG:certbot._internal.log:Root logging level set at 30
2024-03-01 14:41:04,694:DEBUG:certbot._internal.plugins.selection:Requested authenticator dns-strato and installer None
2024-03-01 14:41:04,694:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * dns-strato
Description: Obtain certificates using a DNS TXT record (if you are using Strato for DNS).
Interfaces: Authenticator, Plugin
Entry point: dns-strato = certbot_dns_strato.dns_strato:Authenticator
Initialized: <certbot_dns_strato.dns_strato.Authenticator object at 0x798b0eb23f90>
Prep: True
2024-03-01 14:41:04,695:DEBUG:certbot._internal.plugins.selection:Selected authenticator <certbot_dns_strato.dns_strato.Authenticator object at 0x798b0eb23f90> and installer None
2024-03-01 14:41:04,695:INFO:certbot._internal.plugins.selection:Plugins selected: Authenticator dns-strato, Installer None
2024-03-01 14:41:04,727:DEBUG:certbot._internal.main:Picked account: <Account(RegistrationResource(body=Registration(key=None, contact=(), agreement=None, status=None, terms_of_service_agreed=None, only_return_existing=None, external_account_binding=None), uri='https://acme-v02.api.letsencrypt.org/acme/acct/1596796947', new_authzr_uri=None, terms_of_service=None), 6f0a8cb6b0a20a11d5dc2f93ddbfba38, Meta(creation_dt=datetime.datetime(2024, 3, 1, 13, 37, 36, tzinfo=<UTC>), creation_host='npm.localdomain', register_to_eff=None))>
2024-03-01 14:41:04,727:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2024-03-01 14:41:05,165:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Fri, 01 Mar 2024 13:41:05 GMT
Content-Type: application/json
Content-Length: 752
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "6_Pvodmp9nQ": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf",
    "website": "https://letsencrypt.org"
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-02/renewalInfo/",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}
2024-03-01 14:41:05,166:DEBUG:certbot._internal.display.obj:Notifying user: Requesting a certificate for XXXXX.de
2024-03-01 14:41:05,178:DEBUG:certbot.crypto_util:Generating ECDSA key (2048 bits): /etc/letsencrypt/keys/0002_key-certbot.pem
2024-03-01 14:41:05,188:DEBUG:certbot.crypto_util:Creating CSR: /etc/letsencrypt/csr/0002_csr-certbot.pem
2024-03-01 14:41:05,192:DEBUG:acme.client:Requesting fresh nonce
2024-03-01 14:41:05,192:DEBUG:acme.client:Sending HEAD request to https://acme-v02.api.letsencrypt.org/acme/new-nonce.
2024-03-01 14:41:05,333:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Fri, 01 Mar 2024 13:41:05 GMT
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: iCRP5AvKBZQQDNabOqaNZb8VQSj0sAOmXtGuOTI0WpwW76p--LY
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

2024-03-01 14:41:05,334:DEBUG:acme.client:Storing nonce: iCRP5AvKBZQQDNabOqaNZb8VQSj0sAOmXtGuOTI0WpwW76p--LY
2024-03-01 14:41:05,335:DEBUG:acme.client:JWS payload:
b'{\n  "identifiers": [\n    {\n      "type": "dns",\n      "value": "XXXXX.de"\n    }\n  ]\n}'
2024-03-01 14:41:05,343:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/new-order:
{
  "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTU5Njc5Njk0NyIsICJub25jZSI6ICJpQ1JQNUF2S0JaUVFETmFiT3FhTlpiOFZRU2owc0FPbVh0R3VPVEkwV3B3Vzc2cC0tTFkiLCAidXJsIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL25ldy1vcmRlciJ9",
  "signature": "ftcKQsGnUrRi7tg2DMXnzw3azVcCRJgvHldRbp_WLmI2ov_Z5ys5xcJF5gouD5vbNls1j7c_lklzTW4XqVTONZ1N9DQIfmsxjfN4G-s78GDLIr3xVu9TzaMtWjodZd1cb9jfQbORsBskeU27iVDZDmP91vvIPP4yVIUJC1T5rF6qIaZQVeqm99Kbk5SG_5P_USdvq--z9J72QLoWRXuHvA-kyonnWjECCL9vwhZIGl9ihQkjxTmzWrsBw5TZSac1TJE_bFYnHzbWtgnxfgwWisRatRTJgtqt8x9ByyN6O5TrP2TQ7UJD7xrsT4N8wWiMzjpxudIC56DtAMxS6oNoyQ",
  "payload": "ewogICJpZGVudGlmaWVycyI6IFsKICAgIHsKICAgICAgInR5cGUiOiAiZG5zIiwKICAgICAgInZhbHVlIjogIndvbGV3aWVuc2tpLmRlIgogICAgfQogIF0KfQ"
}
2024-03-01 14:41:05,736:DEBUG:acme.client:Received response:
HTTP 201
Server: nginx
Date: Fri, 01 Mar 2024 13:41:05 GMT
Content-Type: application/json
Content-Length: 340
Connection: keep-alive
Boulder-Requester:<PHONE_NUMBER>
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Location: https://acme-v02.api.letsencrypt.org/acme/order/1596796947/248728721787
Replay-Nonce: iCRP5AvKuHwnj8SJuFgqR7PK3u2C4C33ZccsWzxV0T5YEalgkpg
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "status": "pending",
  "expires": "2024-03-08T13:37:36Z",
  "identifiers": [
    {
      "type": "dns",
      "value": "XXXXX.de"
    }
  ],
  "authorizations": [
    "https://acme-v02.api.letsencrypt.org/acme/authz-v3/321228332677"
  ],
  "finalize": "https://acme-v02.api.letsencrypt.org/acme/finalize/1596796947/248728721787"
}
2024-03-01 14:41:05,737:DEBUG:acme.client:Storing nonce: iCRP5AvKuHwnj8SJuFgqR7PK3u2C4C33ZccsWzxV0T5YEalgkpg
2024-03-01 14:41:05,738:DEBUG:acme.client:JWS payload:
b''
2024-03-01 14:41:05,741:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/authz-v3/321228332677:
{
  "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTU5Njc5Njk0NyIsICJub25jZSI6ICJpQ1JQNUF2S3VId25qOFNKdUZncVI3UEszdTJDNEMzM1pjY3NXenhWMFQ1WUVhbGdrcGciLCAidXJsIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2F1dGh6LXYzLzMyMTIyODMzMjY3NyJ9",
  "signature": "HApgjJKW2K4bNfizVUGjacGbefTRQaWLGRMKN3pfH4IRsDbiHjI_mg48rUqv85Fh5A2O4vBdoDirSdZie7G3d6yEn0CtEaYvJQidtN7jq8Hs_w-mSJJKpx_lS-NzaRcReEVIHgeiYVrqGHIiPM5bnoEMs5YAKHJdayoZBRcmUNxmV3PgzsX0ywHDor5zdYIt5-XuYxERNrCnBlbc2bn0Cnuc9Zhmo_OHuZ1vR-FPuFv5h0iHiHrr4R4v6WgpooRdGM_FRa6Bj077z3_B-MgGKKFXxzFbqdED_15xRHXgjPzZHKnZy1ankVPSovvcZuWvcq1Xo8bKpKABxgb6oT0Mgw",
  "payload": ""
}
2024-03-01 14:41:05,893:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Fri, 01 Mar 2024 13:41:05 GMT
Content-Type: application/json
Content-Length: 798
Connection: keep-alive
Boulder-Requester:<PHONE_NUMBER>
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: iCRP5AvKDvj1FvscYFwwsTlUU1kHvR7yRVh3muiUBT0T4JBLoVQ
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "identifier": {
    "type": "dns",
    "value": "XXXXX.de"
  },
  "status": "pending",
  "expires": "2024-03-08T13:37:36Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/321228332677/H8KNtg",
      "token": "grWJn6XTE8BdkTUAselPoSFhquwisYXDt7PsU_XetV4"
    },
    {
      "type": "dns-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/321228332677/I5rWVg",
      "token": "grWJn6XTE8BdkTUAselPoSFhquwisYXDt7PsU_XetV4"
    },
    {
      "type": "tls-alpn-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/321228332677/Hl0VMg",
      "token": "grWJn6XTE8BdkTUAselPoSFhquwisYXDt7PsU_XetV4"
    }
  ]
}
2024-03-01 14:41:05,894:DEBUG:acme.client:Storing nonce: iCRP5AvKDvj1FvscYFwwsTlUU1kHvR7yRVh3muiUBT0T4JBLoVQ
2024-03-01 14:41:05,895:INFO:certbot._internal.auth_handler:Performing the following challenges:
2024-03-01 14:41:05,896:INFO:certbot._internal.auth_handler:dns-01 challenge for XXXXX.de

Had it running in docker on unraid successful but want to move the critical applications to my proxmox cluster.
I would really appreciate your help here.

Try to use your package password. You can login to your strato account with your domain name (e.g. example.com) and a specific package password. Then enter in nginx proxy manager for the user your domain and for the password the package password.

Ok got it to work now Thx for the hint FlixMa :) If someone have the same problems with the error:
1. exec in to the container

2. apt update

3. apt install pip

4. apt install nano

5. pip install certbot-dns-strato==0.2.1 --break-system-packages

6. cd global/

7. nano certbot-dns-plugins.json

8. change the version from Strato 0.1.1 to 0.2.1 and save it

9. restart the container

10. Request a new Wildcard within NPM

And I had assumed that it was just a bug in the older version. It was all the more annoying to discover that it doesn't work with the newer version either. It finally got it to work thanks to your instructions. Thanks a lot!

Try to use your package password and your domain.
 Then check, if you can login to your strato account with your domain name (e.g. example.com) as user and for your password use your package password.
If that works, enter those credentials into the Credential File:

dns_strato_username = "example.com"

dns_strato_password = "package password"

#uncomment if youre using two factor authentication:

#dns_strato_totp_devicename = 2fa_device

#dns_strato_totp_secret = 2fa_secret

#

#uncomment if domain name contains special characters

#insert domain display name as seen on your account page here

#dns_strato_domain_display_name = my-punicode-url.de

#

#if youre not using strato.de or another special endpoint you can customise it below

#you will probably only need to adjust the host, but you can also change the complete endpoint url

#dns_strato_custom_api_scheme = https

#dns_strato_custom_api_host = www.strato.de

#dns_strato_custom_api_port = 443

#dns_strato_custom_api_path = "/apps/CustomerService"

This finally worked for me! Thank you very much!!! 😁

Hey, again me. Looks like I was able to request a cert for my domain now. but it seems not to be a wildcard. There is no "*" in front of the domain, and we also receive the message from Firefox, that the domain name (subdomain) is missing in the cert.

Hey, again me. Looks like I was able to request a cert for my domain now. but it seems not to be a wildcard. There is no "*" in front of the domain, and we also receive the message from Firefox, that the domain name (subdomain) is missing in the cert.
EDIT: Also, whats interesting, now my default strato credentials are working again for this domain...

You added your domain to nginx like domain.com and also *.domain.com? Then you should receive a wildcard cert.

No, I´ve just added "domain.de" to the textbox, like I did in the past. When additionally adding "*.domain.de" I run into an issue.

I am just a noob myself in that area of expertise ;-). But I think, you have to add *.domain.de for receiving a second level subdomain wildcard certificate.

I think I never did this in the past, but it's possible, it got automatically added. Not sure to be honest.
But with adding it, it did not work, as the resolved address is not routed to my server (its checking for *.domain.de).

After updating to 0.2.1 I could renew the wildcard certificate for one of my two domains. For the other I still get the same error as before. Any hints how to solve this?

I can confirm that renewal after manually updating to 0.2.1 works. But why is that version not updated in the official docker container?

For me it still only works for the first of my domains.

Sadly, neither can I renew my wildcard cert nor can I request a new one with any combination of the settings from above. I tried with updating the python package as well. I still get an "internal error" without any indication to the error itself.

I could successfully create my wildcard certificate, but still can't reach the subdomains when I select it for the proxy host. Btw it says the domains have to already be created. Does that mean that the wildcard certificate will only be created for the subdomains already added in the Strato account?

I could successfully create my wildcard certificate, but still can't reach the subdomains when I select it for the proxy host. Btw it says the domains have to already be created. Does that mean that the wildcard certificate will only be created for the subdomains already added in the Strato account?

You need to register your subdomains manually at strato. NGINX can't register Subdomains for you.
You need to register your subdomains and set the ip where they should point to. Or you could set a CNAME to point to the same IP as your DYNDNS Domain.

@nevyen I would like it to use the same IP as the DynDNS domain. How do I do this with the CNAME? Shouldn't this be automatically set up? I have DynDNS deactivated for the subdomain and I realized that the IP differs from the main domain. I would assume they are the same.
I am still being greeted with the Strato landing page on the subdomain, so the proxy doesn't seem to work. The certificate for my main domain also is not trusted by Firefox today. Yesterday this still worked. Really hard to set this up. DuckDNS was so straight-forward.

@jclsn for each subdomain you must set the CNAME to the domain you registered in your routers dyndns.
Then the subdomain will automaticly get the ip from the "main" domain.
Referr to https://www.strato.de/faq/domains/wie-kann-ich-bei-strato-meine-dns-eintraege-verwalten/#cname

@jclsn Its not about your proxy not working, but rather a wrong configuration in your strato package. Each subdomain can point to a different server, thus strato allowing you to assign different IPs to each subdomain.
If you just need them to all point to the same server (e.g. your npm instance) than you can either set up your duckdns to supply dyndns for all your subdomains or just use CNAME records in your primary domain. CNAME stands for canonical name and are basically the DNS way of saying „this is an alias for that“.

The link you sent me is an A-record, where I should enter an IP, although I don't understand how this would work with DynDNS. Afaik the IP changes from time to time.
I looked at changing the CNAME, but it doesn't accept maindomain.de. Calling the Strato support now. I just wonder why the proxy for the main domain is not working anymore. This is probably a configuration issue with NPM. My DuckDNS proxies are still active and working though.
On Apr. 12 2024, at 8:47 am, Felix Maaß @.***> wrote:

@jclsn @./0?redirect=https%3A%2F%2Fgithub.com%2Fjclsn&recipient=cmVwbHkrQUVXNDdOMjJDR0UyREVWSEJWUU9aTzZFRVM1QjdFVkJOSEhETVlTQVg0QHJlcGx5LmdpdGh1Yi5jb20%3D) Its not about your proxy not working, but rather a wrong configuration in your strato package. Each subdomain can point to a different server, thus strato allowing you to assign different IPs to each subdomain.
If you just need them to all point to the same server (e.g. your npm instance) than you can either set up your duckdns to supply dyndns for all your subdomains or just use CNAME records in your primary domain. CNAME stands for canonical name and are basically the DNS way of saying „this is an alias for that“.
—
Reply to this email directly, view it on GitHub @./1?redirect=https%3A%2F%2Fgithub.com%2FNginxProxyManager%2Fnginx-proxy-manager%2Fissues%2F1154%23issuecomment-2051097884&recipient=cmVwbHkrQUVXNDdOMjJDR0UyREVWSEJWUU9aTzZFRVM1QjdFVkJOSEhETVlTQVg0QHJlcGx5LmdpdGh1Yi5jb20%3D), or unsubscribe @.***/2?redirect=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEW47N3KLSQB6CJJ6VSKLZTY457R7AVCNFSM46E5EUK2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVGEYDSNZYHA2A&recipient=cmVwbHkrQUVXNDdOMjJDR0UyREVWSEJWUU9aTzZFRVM1QjdFVkJOSEhETVlTQVg0QHJlcGx5LmdpdGh1Yi5jb20%3D).
You are receiving this because you were mentioned.

I just realized it works correctly from outside my network. Just tried it with my phone. As soon as I connect to the wifi thoug, the maindomain.de @.***/0?redirect=maindomain.de&recipient=cmVwbHkrQUVXNDdOMjJDR0UyREVWSEJWUU9aTzZFRVM1QjdFVkJOSEhETVlTQVg0QHJlcGx5LmdpdGh1Yi5jb20%3D) is showing me the router's web ui and the subdomains gives me the rebind protection warning.
On Apr. 12 2024, at 9:03 am, Jan Claußen @.***> wrote:

So I added maindomain.de. as CNAME and now the FritzBox is complaining about DNS Rebind protection. The Strato customer support didn't know how to help me :D Guess they only have qualified support for corporate customers.
On Apr. 12 2024, at 8:53 am, Jan Claußen @.***> wrote:

The link you sent me is an A-record, where I should enter an IP, although I don't understand how this would work with DynDNS. Afaik the IP changes from time to time.
I looked at changing the CNAME, but it doesn't accept maindomain.de. Calling the Strato support now. I just wonder why the proxy for the main domain is not working anymore. This is probably a configuration issue with NPM. My DuckDNS proxies are still active and working though.
On Apr. 12 2024, at 8:47 am, Felix Maaß @.***> wrote:

@jclsn @./1?redirect=https%3A%2F%2Fgithub.com%2Fjclsn&recipient=cmVwbHkrQUVXNDdOMjJDR0UyREVWSEJWUU9aTzZFRVM1QjdFVkJOSEhETVlTQVg0QHJlcGx5LmdpdGh1Yi5jb20%3D) Its not about your proxy not working, but rather a wrong configuration in your strato package. Each subdomain can point to a different server, thus strato allowing you to assign different IPs to each subdomain.
If you just need them to all point to the same server (e.g. your npm instance) than you can either set up your duckdns to supply dyndns for all your subdomains or just use CNAME records in your primary domain. CNAME stands for canonical name and are basically the DNS way of saying „this is an alias for that“.
—
Reply to this email directly, view it on GitHub @./2?redirect=https%3A%2F%2Fgithub.com%2FNginxProxyManager%2Fnginx-proxy-manager%2Fissues%2F1154%23issuecomment-2051097884&recipient=cmVwbHkrQUVXNDdOMjJDR0UyREVWSEJWUU9aTzZFRVM1QjdFVkJOSEhETVlTQVg0QHJlcGx5LmdpdGh1Yi5jb20%3D), or unsubscribe @.***/3?redirect=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEW47N3KLSQB6CJJ6VSKLZTY457R7AVCNFSM46E5EUK2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVGEYDSNZYHA2A&recipient=cmVwbHkrQUVXNDdOMjJDR0UyREVWSEJWUU9aTzZFRVM1QjdFVkJOSEhETVlTQVg0QHJlcGx5LmdpdGh1Yi5jb20%3D).
You are receiving this because you were mentioned.

I gave up with Strato DNS plugin. I kept my domain with Strato but moved the DNS Records of it to a free Account on Cloudflare. Now the certs incl. wildcard working without any issues also  renewing them is not a problem anymore.
Cheers
Tom

Ha, I made it! Seems like you can't use the DynDNS in the FritzBox. Using ddclient works much better!

When requesting wildcard certificates for my .de domain, i´m still running into issues. The cert request just aborts, with no visible error message. This problem only comes up for .de domains, found my .com and .eu domains from same strato account are working fine. Any idea, what could block me here?
Using Nginx Proxy Manager v2.11.1, certbot-dns-strato v0.2.1
Details

2024-05-02 16:18:38,612:DEBUG:certbot._internal.main:certbot version: 2.1.0
2024-05-02 16:18:38,612:DEBUG:certbot._internal.main:Location of certbot entry point: /usr/bin/certbot
2024-05-02 16:18:38,612:DEBUG:certbot._internal.main:Arguments: ['--config', '/etc/letsencrypt.ini', '--work-dir', '/tmp/letsencrypt-lib', '--logs-dir', '/tmp/letsencrypt-log', '--cert-name', 'npm-52', '--agree-tos', '--email'<EMAIL_ADDRESS>'--domains', 'domain.de', '--authenticator', 'dns-strato', '--dns-strato-credentials', '/etc/letsencrypt/credentials/credentials-52']
2024-05-02 16:18:38,612:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#dns-cloudflare,PluginEntryPoint#dns-duckdns,PluginEntryPoint#dns-porkbun,PluginEntryPoint#dns-strato,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2024-05-02 16:18:38,619:DEBUG:certbot._internal.log:Root logging level set at 30
2024-05-02 16:18:38,619:DEBUG:certbot._internal.plugins.selection:Requested authenticator dns-strato and installer None
2024-05-02 16:18:38,620:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * dns-strato
Description: Obtain certificates using a DNS TXT record (if you are using Strato for DNS).
Interfaces: Authenticator, Plugin
Entry point: dns-strato = certbot_dns_strato.dns_strato:Authenticator
Initialized: <certbot_dns_strato.dns_strato.Authenticator object at 0x7e703bb94090>
Prep: True
2024-05-02 16:18:38,620:DEBUG:certbot._internal.plugins.selection:Selected authenticator <certbot_dns_strato.dns_strato.Authenticator object at 0x7e703bb94090> and installer None
2024-05-02 16:18:38,620:INFO:certbot._internal.plugins.selection:Plugins selected: Authenticator dns-strato, Installer None
2024-05-02 16:18:38,658:DEBUG:certbot._internal.main:Picked account: <Account(RegistrationResource(body=Registration(key=None, contact=(), agreement=None, status=None, terms_of_service_agreed=None, only_return_existing=None, external_account_binding=None), uri='https://acme-v02.api.letsencrypt.org/acme/acct/1598501227', new_authzr_uri=None, terms_of_service=None), 307c450e4e4c8df29a05c7f1e282d970, Meta(creation_dt=datetime.datetime(2024, 3, 2, 14, 50, 24, tzinfo=<UTC>), creation_host='reverse-proxy.localdomain', register_to_eff=None))>
2024-05-02 16:18:38,658:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2024-05-02 16:18:39,085:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Thu, 02 May 2024 14:18:39 GMT
Content-Type: application/json
Content-Length: 747
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "OCi65trDFA8": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf",
    "website": "https://letsencrypt.org"
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-02/renewalInfo/",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}
2024-05-02 16:18:39,086:DEBUG:certbot._internal.display.obj:Notifying user: Requesting a certificate for domain.de
2024-05-02 16:18:39,097:DEBUG:certbot.crypto_util:Generating ECDSA key (2048 bits): /etc/letsencrypt/keys/0064_key-certbot.pem
2024-05-02 16:18:39,107:DEBUG:certbot.crypto_util:Creating CSR: /etc/letsencrypt/csr/0064_csr-certbot.pem
2024-05-02 16:18:39,110:DEBUG:acme.client:Requesting fresh nonce
2024-05-02 16:18:39,111:DEBUG:acme.client:Sending HEAD request to https://acme-v02.api.letsencrypt.org/acme/new-nonce.
2024-05-02 16:18:39,251:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Thu, 02 May 2024 14:18:39 GMT
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: O0afatDIUYo_tvD0qKgcSxmqX1tK9R_NX45BGoQ8WT4UCWOsn-U
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

2024-05-02 16:18:39,252:DEBUG:acme.client:Storing nonce: O0afatDIUYo_tvD0qKgcSxmqX1tK9R_NX45BGoQ8WT4UCWOsn-U
2024-05-02 16:18:39,252:DEBUG:acme.client:JWS payload:
b'{\n  "identifiers": [\n    {\n      "type": "dns",\n      "value": "domain.de"\n    }\n  ]\n}'
2024-05-02 16:18:39,260:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/new-order:
{
  "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTU5ODUwMTIyNyIsICJub25jZSI6ICJPMGFmYXRESVVZb190dkQwcUtnY1N4bXFYMXRLOVJfTlg0NUJHb1E4V1Q0VUNXT3NuLVUiLCAidXJsIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL25ldy1vcmRlciJ9",
  "signature": "TNaLqp0iX0oneAfzg9KFPB5WFMIwk-983BR1hw2ProTI74Str79_tfoXWjx40wIBPFiIG5eQkohC93KrX6iPNFIo9se4OlTJwpYxolUYDehXtyY6yULfpOMXQBcDUxkUARB0cW5ERoyRVz16CHi8oiCxOkYGRwB3St_EOPCYPKNAxAiRSjT-hb4ONIe_9iSRcgeDBGfqwrp104cRnNJB9qVPVOCpqtoM9WzX5pF9TIY6pKI-uX47FPQR9fcZ3_lbFm53a5Iz9Byt7_Bav1wKvZmZf_noK3u66AAHMjSg05bb3hqS2FoJqR1TB0Kc4YIPF_BSX_3CA-ronONwE4dfhA",
  "payload": "ewogICJpZGVudGlmaWVycyI6IFsKICAgIHsKICAgICAgInR5cGUiOiAiZG5zIiwKICAgICAgInZhbHVlIjogIndvbGV3aWVuc2tpLmRlIgogICAgfQogIF0KfQ"
}
2024-05-02 16:18:39,414:DEBUG:acme.client:Received response:
HTTP 201
Server: nginx
Date: Thu, 02 May 2024 14:18:39 GMT
Content-Type: application/json
Content-Length: 340
Connection: keep-alive
Boulder-Requester:<PHONE_NUMBER>
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Location: https://acme-v02.api.letsencrypt.org/acme/order/1598501227/265980151337
Replay-Nonce: Y_7AIQuUkd3e3_rcDcX4pgPvzO4_O7YtbF9-GNnBAG3kkijVcoA
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "status": "pending",
  "expires": "2024-05-09T14:10:50Z",
  "identifiers": [
    {
      "type": "dns",
      "value": "domain.de"
    }
  ],
  "authorizations": [
    "https://acme-v02.api.letsencrypt.org/acme/authz-v3/345790981617"
  ],
  "finalize": "https://acme-v02.api.letsencrypt.org/acme/finalize/1598501227/265980151337"
}
2024-05-02 16:18:39,415:DEBUG:acme.client:Storing nonce: Y_7AIQuUkd3e3_rcDcX4pgPvzO4_O7YtbF9-GNnBAG3kkijVcoA
2024-05-02 16:18:39,415:DEBUG:acme.client:JWS payload:
b''
2024-05-02 16:18:39,417:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/authz-v3/345790981617:
{
  "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTU5ODUwMTIyNyIsICJub25jZSI6ICJZXzdBSVF1VWtkM2UzX3JjRGNYNHBnUHZ6TzRfTzdZdGJGOS1HTm5CQUcza2tpalZjb0EiLCAidXJsIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2F1dGh6LXYzLzM0NTc5MDk4MTYxNyJ9",
  "signature": "PNZq4tTE50GX_sy3ClPHI4W9tjzlHLWdvZEpCcHHVUfNxTFCGFPXQNLV-XApHrRlhytrTU6GhuVR7l378zqCOV2z4r5nXQe75t0ZqEeHJ-HE70PGhV6uD3bdpNhKdGSpZ4jmEV50oWUpWEL_AG-WjJx4E_5KV5BC3Xlno-0i9OYRlQqTmi4eki2_8NQAmJMfZliUoqiukSLyuLk126OJqGVdhiiF7Q2G4i36e1VH9VbyadoLbtfv3OAn87dJjpFJM_TBVb2X9HsA_0NnUIFp8YTYOimmRRA4--PZdlFfND0KSR4TdPlDeQoiKnlAJ-fVeA7eXyvybYqYJwyONpUWZw",
  "payload": ""
}
2024-05-02 16:18:39,553:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Thu, 02 May 2024 14:18:39 GMT
Content-Type: application/json
Content-Length: 798
Connection: keep-alive
Boulder-Requester:<PHONE_NUMBER>
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: O0afatDI0RLN73rcITo_-Hrn3IjJ_80RKuQsTqncpUMtaf7q9jk
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "identifier": {
    "type": "dns",
    "value": "domain.de"
  },
  "status": "pending",
  "expires": "2024-05-09T14:10:50Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345790981617/e0m2DA",
      "token": "-4gozKMezPVXlBOFkulRMXBDmxXUlwEYdnkEjx8gSak"
    },
    {
      "type": "dns-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345790981617/coLV5g",
      "token": "-4gozKMezPVXlBOFkulRMXBDmxXUlwEYdnkEjx8gSak"
    },
    {
      "type": "tls-alpn-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345790981617/2sm9nQ",
      "token": "-4gozKMezPVXlBOFkulRMXBDmxXUlwEYdnkEjx8gSak"
    }
  ]
}
2024-05-02 16:18:39,553:DEBUG:acme.client:Storing nonce: O0afatDI0RLN73rcITo_-Hrn3IjJ_80RKuQsTqncpUMtaf7q9jk
2024-05-02 16:18:39,554:INFO:certbot._internal.auth_handler:Performing the following challenges:
2024-05-02 16:18:39,555:INFO:certbot._internal.auth_handler:dns-01 challenge for domain.de```

</p>
</details>

When requesting wildcard certificates for my .de domain, i´m still running into issues. The cert request just aborts, with no visible error message. This problem only comes up for .de domains, found my .com and .eu domains from same strato account are working fine. Any idea, what could block me here?
Using Nginx Proxy Manager v2.11.1, certbot-dns-strato v0.2.1
Full log of issue
EDIT: Only difference i found is, that .de domain is trying way more challenges and stays on status "pending" compared to .com. But all domais are routed to my homelab via dyndns and can be used/pinged & i have used the exact same credentials for both.
.de-challenges
.com challenges

Did you finally resolve this for .de domains? Having the same issue here

When requesting wildcard certificates for my .de domain, i´m still running into issues. The cert request just aborts, with no visible error message. This problem only comes up for .de domains, found my .com and .eu domains from same strato account are working fine. Any idea, what could block me here?

Using Nginx Proxy Manager v2.11.1, certbot-dns-strato v0.2.1

Full log of issue

EDIT: Only difference i found is, that .de domain is trying way more challenges and stays on status "pending" compared to .com. But all domais are routed to my homelab via dyndns and can be used/pinged & i have used the exact same credentials for both.

.de-challenges

.com challenges

Did you finally resolve this for .de domains? Having the same issue here

Unfortunately not. There where some recommendations later, but i switched to zoraxy in the meanwhile and never looked back. Wildcard ist there not possible for strato but tested it and it looked good.
Maybe i will try NPM again in the future.

With Strato I could solve by adding mydomain.de. as CNAMEAm 20.07.2024 um 09:20 schrieb markist @.***>:
When requesting wildcard certificates for my .de domain, i´m still running into issues. The cert request just aborts, with no visible error message. This problem only comes up for .de domains, found my .com and .eu domains from same strato account are working fine. Any idea, what could block me here?
Using Nginx Proxy Manager v2.11.1, certbot-dns-strato v0.2.1
Full log of issue
EDIT: Only difference i found is, that .de domain is trying way more challenges and stays on status "pending" compared to .com. But all domais are routed to my homelab via dyndns and can be used/pinged & i have used the exact same credentials for both.
.de-challenges
.com challenges
Did you finally resolve this for .de domains? Having the same issue here
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

This worked for me
Instruction

set up a 2fa device in strato web interface
go to nginx proxy manager web interface
add ssl certificate

Credentials File Content
dns_strato_username = strato customer number
dns_strato_password = strato password
dns_strato_totp_devicename = 2fa_device
dns_strato_totp_secret = 2fa_secret

for example
dns_strato_username = 12345678
dns_strato_password = supersecret
dns_strato_totp_devicename = iPhone
dns_strato_totp_secret = ASHUQW12237811ZHRW109EJDE92HCEHH

Result

with activated 2FA certificate requests for subdomains or wildcards cause errors. Disabled 2FA "solves" the problem :)
error:
    CommandError: Saving debug log to /tmp/letsencrypt-log/letsencrypt.log     Encountered exception during recovery: binascii.Error: Non-base32 digit found     An unexpected error occurred: binascii.Error: Non-base32 digit found     Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/letsencrypt-log/letsencrypt.log or re-run Certbot with -v for more details.
  at /app/lib/utils.js:16:13     at ChildProcess.exithandler (node:child_process:410:5)     at ChildProcess.emit (node:events:513:28)     at maybeClose (node:internal/child_process:1100:16)     at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5)

Hi!
If I try to get thecert for mydomain.com working without problems.
But if I try to get the cert for *.mydomain.com i get this error:
`CommandError: Saving debug log to /tmp/letsencrypt-log/letsencrypt.log
at /app/lib/utils.js:16:13
at ChildProcess.exithandler (node:child_process:430:5)
at ChildProcess.emit (node:events:519:28)
at maybeClose (node:internal/child_process:1105:16)
at ChildProcess._handle.onexit (node:internal/child_process:305:5)`

I can see that I'm been using the version certbot-dns-strato==0.2.2
I have to configure something in strato?
Thanks in advance!

Finally I get my wildcard certificate after some attemtps. I think I just had to wait a few hours becouse is a new domain. Thanks!
For use this wildcard to subdomains like sub1.mydomain.com I have to configure something in stratos? Becouse it's not working 🙄 the one I generated for duckdns I didn't have to do anything and works.

Had to set up a new machine with npm and ran into some problems when using certbot-dns-strato==0.2.1
Updating to version 0.2.2 fixed it
1. exec in to the container 2. apt update 3. apt install pip 4. apt install nano 5. pip install certbot-dns-strato==0.2.2 --break-system-packages 6. cd global/ 7. nano certbot-dns-plugins.json 8. change the version from Strato 0.2.1 to 0.2.2 and save it 9. restart the container 10. Request a new Wildcard within NPM
Im using 2FA as described by noname1001


Support Bower

+1
bower support would be much appreciated. in combination with tsd support to be able to provide a compiled js version of the library in combination with *.d.ts definitions

I'm sorry but bower will not be supported<EMAIL_ADDRESS>Lets all move to NPM. One less package manager you need to maintain / learn / keep up to date with :rose:


how does this binary get invoked?

Hey, this project looks super interesting!  I'm certain I'm missing something here, but how does the /opt/extensions/serverlessish binary get invoked/bootstrapped?  It looks like once the serverlessish executable is started, it polls the lambda runtime api for events (sent by APIG/ALB) and forwards/proxies them to the user's http server process.  Just not seeing how it gets bootstrapped.  It looks like the Dockerfile's entrypoint is the user's executable.

Doh!  I just found the answer here.  it is invoked as a lambda extension.  Nothing to see here...move along :)


Remove regex validator for timeout text field

Timeout text field is integer type that does not need a regex validator
https://bugzilla.redhat.com/show_bug.cgi?id=1274673

@gmcculloug LGTM - please review

@Fryguy @bdunne Any idea why travis did not run here?

@gmcculloug Not sure, maybe it needs a rebase?

I do see it on the Travis queue here: https://travis-ci.org/ManageIQ/manageiq/builds/87524645
So, it is just not reporting it back to GitHub.


Update cloud region carbon intensity factors

Wasn't sure if this should be a bug or feature request
The carbon intensity factors for cloud provider regions & on-premise are slightly dated. The files listed below were last updated between 10 months to 2 years ago.

AwsFootprintEstimationConstants.ts
AliFootprintEstimationConstants.ts
AzureFootprintEstimationConstants.ts
GcpFootprintEstimationConstants.ts
OnPremiseFootprintEstimationConstants.ts

To update the carbon intensity values in these files, there are a couple of recent sources that can be used. Below I have outlined those sources & indicated where they might be best put to use:
Data from the GSF Real-time Cloud project
The GSF's real-time cloud project has published a spreadsheet with data for AWS, GCP, and Azure regions. This was shared in the conversation for Green-Software-Foundation/real-time-cloud/issues/14.
The grid intensity factors for AWS, GCP, and Azure could be updated with values from this document.
Data from CO2.js
For on-premise, the data used is country-level. To update this, there is data available in CO2.js. This can be accessed in JSON format, or by installing CO2.js as a dependency. I have linked below to the JSON file for visibility.
https://github.com/thegreenwebfoundation/co2.js/blob/main/data/output/average-intensities.json
The values in this file are updated every month on a cronjob from Ember, to reflect any changes to their methodology, and represent the most up-to-date, easy to use open data that we can find.
The changes are also checked by Chris Adams (@mrchrisadams) and myself to catch surprises in the numbers, and query them upstream. You can see the most recent example below:
https://github.com/thegreenwebfoundation/co2.js/pull/190

The only cloud provider which I'm not able find updated carbon intensity factors for is Aliyun.

@camcash17 @4upz are you guys okay if I were to create a PR to update the carbon emissions factors as I've outlined above?

Hey @fershad, this is awesome! Thanks for offering to create the PR for this work. Very happy to continuing talking through this here if any questions arise.
Just a couple considerations.. With this change we will want to update both our documentation and also our coefficients repo to reflect these data source updates. In our coefficients repo, we could also consider automation.


Updated validation for component name

Updated validation to throw an error if the component name contains any special character

@Giuliano1993 let me know if you need any changes

That really works great! Thx again @IrfanSalim

Fixes #17


Larger size of the generated worker with wrangler v1.9.x

🐛 Bug Report

Environment

operating system: macOS 10.15.4
output of rustc -V: rustc 1.43.1
output of node -v: v14.3.0
output of wrangler -V: wrangler 1.9.2
contents of wrangler.toml:

name = "log-shipper"
type = "webpack"
account_id = "xxxxx"
workers_dev = true
route = ""
zone_id = "xxxxx"
webpack_config = "webpack.config.js"

[env.dev]
webpack_config = "webpack.dev.config.js"

Steps to reproduce
When building the project using wrangler v1.8 the size of the worker is 635Kib:
❯❯❯ npm install -g<EMAIL_ADDRESS>                                                       23:23:18
/usr/local/bin/wrangler -><EMAIL_ADDRESS>
><EMAIL_ADDRESS>postinstall /usr/local/lib/node_modules/@cloudflare/wrangler
> node ./install-wrangler.js

Downloading release https://workers.cloudflare.com/get-npm-wrangler-binary/1.8.4/x86_64-apple-darwin
wrangler has been installed!
+<EMAIL_ADDRESS>updated 3 packages in 3.694s

~/C/worker master
❯❯❯ wrangler build                                                                                23:23:23
⬇ Installing wranglerjs...
⬇ Installing wasm-pack...
Warning: webpack's output filename is being renamed to worker.js because of requirements from the Workers runtime
✨  Built successfully, built project size is 635 KiB.

After upgrading to v1.9 it goes over the 1Mb limit:
~/C/worker master 7s
❯❯❯ npm install -g<EMAIL_ADDRESS>                                                       23:23:38
/usr/local/bin/wrangler -><EMAIL_ADDRESS>
><EMAIL_ADDRESS>postinstall /usr/local/lib/node_modules/@cloudflare/wrangler
> node ./install-wrangler.js

Downloading release https://workers.cloudflare.com/get-npm-wrangler-binary/1.9.2/x86_64-apple-darwin
wrangler has been installed!
+<EMAIL_ADDRESS>updated 3 packages in 4.24s

~/C/worker master 6s
❯❯❯ wrangler build                                                                     23:25:42
Warning: webpack's output filename is being renamed to worker.js because of requirements from the Workers runtime
✨  Built successfully, built project size is 1 MiB. ⚠  Your built project has grown past the 1MiB size limit and may fail to deploy. ⚠

~/C/worker master 9s
❯❯❯ wrangler --version                                                                              23:26:29
👷 ✨  wrangler 1.9.2

This larger size is also confirmed when trying to publish the worker:
❯❯❯ wrangler publish                                                                                23:54:11
Warning: webpack's output filename is being renamed to worker.js because of requirements from the Workers runtime
✨  Built successfully, built project size is 1 MiB. ⚠  Your built project has grown past the 1MiB size limit and may fail to deploy. ⚠
Error: Something went wrong! Status: 400 Bad Request, Details {
  "result": null,
  "success": false,
  "errors": [
    {
      "code": 10027,
      "message": "workers.api.error.script_too_large"
    }
  ],
  "messages": []
}

What did you expect to see?
Same size of the worker for the different versions of wrangler.
What did you see instead?
The size of the worker should not be different between wrangler versions.
I noticed this issue after upgrading to wrangler v1.9.0 https://github.com/cloudflare/wrangler/issues/1188#issuecomment-630851045 but now I confirmed that the same thing is happening after using the latest release v1.9.2.

Hey @jorgelbg - this seems like a bug but it's hard to know what's happening without a repo that can reliably reproduce the error.
Could you make an example repository or link the repository you're using so we can attempt to reproduce the different behavior between 1.8 and 1.9? Thanks!

If I run wrangler build with wrangler 1.8.4 on that repository, I get the same message about size.
$ wrangler --version
👷 ✨  wrangler 1.8.4

$ wrangler build

><EMAIL_ADDRESS>install ~/dir/loki-log-shipper/node_modules/fsevents
> node-gyp rebuild

  SOLINK_MODULE(target) Release/.node
  CXX(target) Release/obj.target/fse/fsevents.o
  SOLINK_MODULE(target) Release/fse.node
npm WARN<EMAIL_ADDRESS>No repository field.

added 614 packages from 905 contributors and audited 615 packages in 18.146s

16 packages are looking for funding
  run `npm fund` for details

found 19 vulnerabilities (16 low, 3 moderate)
  run `npm audit fix` to fix them, or `npm audit` for details
⬇ Installing wranglerjs...
⬇ Installing wasm-pack...
Warning: webpack's output filename is being renamed to worker.js because of requirements from the Workers runtime
✨  Built successfully, built project size is 1 MiB. ⚠  Your built project has grown past the 1MiB size limit and may fail to deploy. ⚠

that being said - if you remove devtool: 'source-map' from your custom webpack.config.js, the size should be much smaller (that's my bad, it's in my template, i'll submit a pr to fix that)

🤔 I've even cloned the repository into a different path and run with 1.8.4 and I don't get the error, I do get it with 1.9.2.
Indeed removing the source maps trims down the size, but I was more puzzled about the difference in size between the 2 versions without any other changes.

Tried again now and this is the console output of the entire clone/build process: https://gist.github.com/jorgelbg/734a401858bdae18275276180bc76741

hmmmmmm - i cannot reproduce this for the life of me. perhaps @ashleymichal  can take a look? super strange for sure...
as for the template, i've updated it to not include source maps: https://github.com/EverlastingBugstopper/worker-typescript-template/compare/972ddb6..aa7435c

To make things even more strange, after removing the source maps, I still see a difference in the project size between v1.8 and v1.9:
v1.8.4:
✨  Built successfully, built project size is 181 KiB.

v1.9.2:
✨  Built successfully, built project size is 275 KiB.

One important note, the value derives from webpack. The uncompressed id 885 KiB (compressed 275 KiB). @jorgelbg can you check the uncompressed of the other versions?
v1.10.1:
✨  Built successfully, built project size is 275 KiB.

v1.8.4: 522.4 KB
v1.9.4: 885.9 KB
v1.10.1:  886 KB

@adaptive Sizes between v1.9.x and v1.10.x are somehow similar but still larger than v.1.8.4.

I'm having this exact problem.
The same project/code, builds and packages to 206KB with wrangler 1.6, but jumps to 377KB when I upgrade wrangler to 1.11. This is the same on windows and mac. This jump in size is unacceptable for a platform like this.
I'll be sticking with old versions of wrangler until this issues is sorted out.
Attached screenshot:

I think I've found the underlying problem. It's dependency duplication. In the bundled worker.js file, I have the same package (bn.js) included 8 times! It is highly likely that there are other packages duplicated as well. See below references:
// "../../../../AppData/Local/.wrangler/wranglerjs-1.11.0/node_modules/asn1.js/node_modules/bn.js/lib/bn.js":
// "../../../../AppData/Local/.wrangler/wranglerjs-1.11.0/node_modules/bn.js/lib/bn.js":
// "../../../../AppData/Local/.wrangler/wranglerjs-1.11.0/node_modules/browserify-rsa/node_modules/bn.js/lib/bn.js":
// "../../../../AppData/Local/.wrangler/wranglerjs-1.11.0/node_modules/create-ecdh/node_modules/bn.js/lib/bn.js":
// "../../../../AppData/Local/.wrangler/wranglerjs-1.11.0/node_modules/diffie-hellman/node_modules/bn.js/lib/bn.js":
// "../../../../AppData/Local/.wrangler/wranglerjs-1.11.0/node_modules/elliptic/node_modules/bn.js/lib/bn.js":
// "../../../../AppData/Local/.wrangler/wranglerjs-1.11.0/node_modules/miller-rabin/node_modules/bn.js/lib/bn.js":
// "../../../../AppData/Local/.wrangler/wranglerjs-1.11.0/node_modules/public-encrypt/node_modules/bn.js/lib/bn.js":

Just to confirm, this is still an issue with version 1.12.2. With a minified production build, there is a difference of around 90kb compared to version 1.6. This difference does not seem to change with the amount of (user) code in the worker. This is all due to different version references of BN.js and couple of other duplicated dependencies in the core. In version 1.6, the bundle contains only one version of those dependencies hence a lot smaller in size.

Just wanted to give an update here, we're introducing custom builds as part of #1818. After that merges, if you use custom builds, this will not longer be an issue.

This sounds great. Please let us know when this is merged and I'll test again. Thanks.

This should actually be fixed in #1722


Skip to specified page

Is there an easy way to skip to a specific page?
I have tried:
int customPageNumber = 25;
mViewPager.setAdapter(mSectionsPagerAdapter);
mViewPager.setCurrentItem(customPageNumber);
but I get a strange bug where the next few pages are repeats. My goal is to create a bookmark effect by manually inserting the desired page number.
Tested on the sample application.
Also:
mViewPager.setOffscreenPageLimit(0);
outputs this message:
W/ViewPager: Requested offscreen page limit 0 too small; defaulting to 1

This is currently not possible. Library is meant to proceed sequentially.
But I am willing to add that functionality in the future. With the saving progress functionality.

Looking forward to it and thanks for the quick response.

Let the issue stay opened. This and progress-saving functionalities are must :)

Skipping to specified page is now available. Please let me know if there is any issue.
You can also check the functionality on sample application.


Test with new pluggable agent releases

Test against version 2.1.0 of both the .NET Core 3.1 and the .NET 8.0 pluggable agents.

:tada: This issue has been resolved in version 2.0.0-alpha8 :tada:
The release is available on:

GitHub Release
NuGet Package


Cannot find module yargs (Docker image)

Using the branch from #1388...
# docker build --tag gbif/portal16
# hcon -Rt svirt_sandbox_file_t config/
# docker run --publish 1234:80 --volume $PWD/config:/etc/portal16 --rm --name portal16 --interactive --tty gbif/portal16
npm info it worked if it ends with ok
npm info using<EMAIL_ADDRESS>npm info using<EMAIL_ADDRESS>npm info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>npm info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>
><EMAIL_ADDRESS>start /usr/src/app
> NODE_ENV=prod node app.js

module.js:472
    throw err;
    ^

Error: Cannot find module 'yargs'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.Module._load (module.js:418:25)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/etc/portal16/config.js:2:13)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)

npm info lifecycle<EMAIL_ADDRESS>Failed to exec start script
npm ERR! Linux 5.6.15-200.fc31.x86_64
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "start"
npm ERR! node v7.9.0
npm ERR! npm  v4.2.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `NODE_ENV=prod node app.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'NODE_ENV=prod node app.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the gbif-portal16 package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     NODE_ENV=prod node app.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs gbif-portal16
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls gbif-portal16
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /root/.npm/_logs/2020-07-06T15_11_37_379Z-debug.log

Hi @frafra
Thank you so much for your interest in the project. May I ask what you are trying to achieve?
Unlikely to run locally
I'm asking because the project depends on secret keys and firewall access.
Almost all data on the website is freely available through our APIs (see https://www.gbif.org/developer)
But there are a few exceptions (participation data, login, downloads, cms prose, literature)
Occurrence/dataset/publisher search and presentation could in theory be reused, but it would require a fair amount of rewriting.
Alternatives
You are likely better of building of our APIs, and we will be happy to help getting you started.
We are also in the process of building a more standalone project for reusing occurrence search, that might have interest as that matures.
Thanks

Hi @MortenHofft,
Sure! I was just trying to spin up a GBIF instance for testing and to evaluate if it could be further extended for the https://livingnorway.no/ initiative, instead of developing something custom, while contributing back to the original source code as much as possible. That is one of the scenario we are exploring.

This item from the GBIF work program 2020 might have your interest
https://docs.gbif.org/2020-work-programme/en/#_activity_1c_equip_participant_nodes

The Secretariat will design and implement user interfaces and services necessary to support simple hosted portals. The initial deployment will be of the BID programme portal followed by exploration of country portals and an exemplar virtual natural history collection. Discussions will determine whether such services should be restricted to Voting Participant countries and/or institutions that contribute a fee to create institutional portals.

@frafra - perhaps Morten could join in the Living Norway symposium this year, relating to this?

@timrobertson100 Sure, it seems a great idea to me :)
https://livingnorway.no/towards-open-science-in-applied-ecology/


Small fixes

Hi, I tried this code a little. I didn’t get everything going, but did find these things:

edges were found via an O(n^2) brute force search, I tried to update this to use dicts which was much faster for me
crash using omega which is treated as a tensor, i made it a tensor
unknown ops can significantly impact the algorithm, i had it print when it finds them

Thanks for the PR @xloem . I will test and review in the early of next week. The unknown operator indeed affects the library a lot, while can be usually resolved after investigation then fed into the supported operator. You could share your model script for me for a quick look if it is not confidential.

I was trying this with the 7 billion parameter llama model from huggingface to explore. I'm just a hobbyist, not experienced with sparsification yet. It takes 74GB float16 vram (110GB float32 ram on cpu) to construct the graph and presently crashes in a later phase; it looks like it is because the parameter groups are empty and the incorporation of unknown operators is needed like you mention. https://codeberg.org/xloem/zigllama/src/branch/main/testoto.py
I glanced at your examples and I infer it makes sense to start with a small model and to manually code the script for oto, which I haven't done at this time.

@xloem Thanks for the PR. I have tested it on my end, which indeed accelerated the graph construction.


CSP blocking List-Unsubscribe POST request in ProtonMail (both BETA and non-BETA)

Hi, I emailed this bug to<EMAIL_ADDRESS>last week but did not get a reply, so I figure this would be a good place to post it.

I'm using the BETA version of the ProtonMail web application (beta.protonmail.com), but have also tested this functionality on the non-BETA web application and the issue described below is present in both.
To Reproduce
The web client's implementation of the List-Unsubscribe functionality is failing due to the Content-Security-Policy. The screenshot below shows an example:
Screenshots
When clicking 'Unsubscribe' from a mailing list email that defines a POST URL in List-Unsubscribe:

The following error occurs:

Desktop (please complete the following information):

OS: Linux
Browser: Brave
Version: Version 1.10.90 Chromium: 83.0.4103.97
Resolution: 3840*2160
URL: mail.protonmail.com, beta.protonmail.com

Additional context
The issue is what is stated in the console error—the XHR POST request is failing because the connect-src directive won't allow it.
This can be fixed by changing the directive from connect-src 'self' blob: to something like connect-src 'self' blob: https:, which would allow XHR requests to any URL over TLS, but that may still be too strict, as some sites may include a List-Unsubscribe header that contains a non-HTTPS url. You may have to include both https: and http: in connect-src for this to work.

Hi @charukiewicz , sorry about the slow reply from support, we did receive your message and were discussing internally how to fix it. We'll probably do it via an API route for the client to request that the server send the unsubscribe on its behalf, as I think allowing unrestricted XHR to any domain in the CSP would be an unacceptable security risk.

@bartbutler makes sense. Definitely a good approach. With the server making the request on behalf of the browser, you also have the benefit of not getting blocked by a misconfigured CORS policy that the mailing list server has. Unless they explicitly include something like:
access-control-allow-origin: *
access-control-allow-methods: POST

as OPTIONS headers, the endpoint will not work in most modern browsers, since they will refuse to make cross-origin requests.

Yes, misconfigured CORS could also be a problem in certain cases with the client-side approach--we hadn't thought of that. In any case, server-side definitely seems to be the right way to go.