certbot-dns-netcup
certbot-dns-netcup copied to clipboard
Exception: The session id is not in a valid format. (4001)
I'm not sure if this is an error from the client or an error from the netcup API, but as I'm trying to request a new certificate I get the following error:
Exiting abnormally:
Traceback (most recent call last):
File "/snap/certbot/3643/bin/certbot", line 8, in <module>
sys.exit(main())
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/main.py", line 19, in main
return internal_main.main(cli_args)
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/_internal/main.py", line 1894, in main
return config.func(config, plugins)
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/_internal/main.py", line 1600, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/_internal/main.py", line 143, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/_internal/client.py", line 517, in obtain_and_enroll_certificate
cert, chain, key, _ = self.obtain_certificate(domains)
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/_internal/client.py", line 428, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/_internal/client.py", line 496, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/_internal/auth_handler.py", line 88, in handle_authorizations
resps = self.auth.perform(achalls)
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/plugins/dns_common.py", line 76, in perform
self._perform(domain, validation_domain_name, validation)
File "/snap/certbot-dns-netcup/current/lib/python3.8/site-packages/certbot_dns_netcup.py", line 69, in _perform
self._get_netcup_client().add_txt_record(
File "/snap/certbot/3643/lib/python3.8/site-packages/certbot/plugins/dns_common_lexicon.py", line 63, in add_txt_record
self.provider.create_record(rtype='TXT', name=record_name, content=record_content)
File "/snap/certbot-dns-netcup/current/lib/python3.8/site-packages/lexicon/_private/providers/netcup.py", line 60, in create_record
self._update_records(
File "/snap/certbot-dns-netcup/current/lib/python3.8/site-packages/lexicon/_private/providers/netcup.py", line 151, in _update_records
return self._apicall(
File "/snap/certbot-dns-netcup/current/lib/python3.8/site-packages/lexicon/_private/providers/netcup.py", line 175, in _apicall
raise Exception(f"{data['longmessage']} ({data['statuscode']})")
Exception: The session id is not in a valid format. (4001)
An unexpected error occurred:
Exception: The session id is not in a valid format. (4001)
This is taken from the API-Log:
Hi,
thanks for the report. I haven't seen this so far. Does this also occur with the docker version? I'm rather busy this week. If I don't get back to you, ping me again.
Best, Thomas
I didn't test the docker version. I'm a bit old school I assume.
However, the issue seems to be resolved and it was either related to an issue on netcups end or related to a malfunctioning IPv6 link on my server, although I wonder why that would result in this error.
Ok, thank you for the update. In this case I'll close because, although it'd be nice to have a better error message for this case, it will be hard to reproduce and improve.
I'm currently running into the same error. I have a cronjob that executes the docker image every day and it started failing two days ago. I didn't modified anything on the server or in the netcup control panel.
certbot -v logs
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-netcup, Installer None
Certificate is due for renewal, auto-renewing...
Renewing an existing certificate for ...
Performing the following challenges:
dns-01 challenge for ...
Unsafe permissions on credentials configuration file: /credentials.ini
Cleaning up challenges
Encountered exception during recovery: Exception: The session id is not in a valid format. (4001)
An unexpected error occurred:
Exception: The session id is not in a valid format. (4001)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
When using a plain alpine container and installing everything manually (apk update && apk add certbot py3-pip && pip install certbot-dns-netcup ) and executing certbot (certbot certonly --authenticator dns-netcup --dns-netcup-credentials /credentials.ini --dns-netcup-propagation-seconds 900 --keep-until-expiring --non-interactive --agree-tos --email '...' --expand --server https://acme-v02.api.letsencrypt.org/directory -d '...') it works fine
Interesting, so it works with a manual installation, but not with the pulled docker container on docker-hub?
What if you build a new image from this repository? That should have the same effect as your manual installation. Maybe the uploaded image is too out of date?
I just ran into the same problem by installing Certbot on Debian per apt and this package with pip as well as installing both in a venv with pip. The issue seems to lie within the upstream dns-lexicon package. Downgrading to an older version like 3.15.0 fixed this for me.
The code runs into an error in line 52 in the netcup.py when it tries to execute infoDnsZone -> https://github.com/AnalogJ/lexicon/blob/0a83053d8af2fcf803b57a97abc968a23ea02f02/src/lexicon/_private/providers/netcup.py#L52.
_apicall runs into an error in line 175 with an error: The session id is not in a valid format (4001). The ID is set in line 169 and should have been fetched with a call to login in line 47 which does return with HTTP 200 for me.
Strangely, it doesn't seem like the netcup.py has really been changed recently, and there is no obvious bug in the code here. The most likely explanation seems that the session ID is wiped or overwritten somewhere in between. I suspect that this might be some weird dependency issue because of the way in which Certbot itself uses the lexicon package indirectly via its plugins.
I'm currently running into the same error. I have a cronjob that executes the docker image every day and it started failing two days ago. I didn't modified anything on the server or in the netcup control panel. certbot -v logs
When using a plain alpine container and installing everything manually (
apk update && apk add certbot py3-pip && pip install certbot-dns-netcup) and executing certbot (certbot certonly --authenticator dns-netcup --dns-netcup-credentials /credentials.ini --dns-netcup-propagation-seconds 900 --keep-until-expiring --non-interactive --agree-tos --email '...' --expand --server https://acme-v02.api.letsencrypt.org/directory -d '...') it works fine
Well turns out this does not work every time. The issue occured again with the manual setup and it failed. But then after restarting the manual container 2 times it magically worked
So I finally got around to reproducing this locally.
netcup seems to let authenticated sessions time out after 30s without requests and then responds with the above message.
Solution may be to catch this error and re-authenticate + re-execute the query.
I still don't fully understand why this timeout was triggered, because the API calls should have been issued pretty much immediately after authentication - unless the connection to the API endpoint is so bad that you get a timeout(?).
However, I think this should be mitigated in version 2.0.0 by some changes:
- using only a single request after login for adding the DNS entry (instead of previously 3 requests)
- adding a retry mechanism to redo the login in case of flaky connection (default = 3 retries)
- there is now a
--dns-netcup-login-retries NUMcommand line argument to specify an even higher number if needed - adding a command line argument
--dns-netcup-zone-name DOMAINthat lets you specify which zone to use. If unspecified, the zone will be determined by brute-force requests starting with most specific subdomain, ending with least specific domain.