INWX: "Mobile TAN detected" but not activated

[simonszu]

I have an issue with DNS validation via INWX. The error mail i get is:

[Di 11. Sep 00:25:04 CEST 2018] Mobile TAN detected.
[Di 11. Sep 00:25:04 CEST 2018] Please define a shared secret.
[Di 11. Sep 00:27:15 CEST 2018] Mobile TAN detected.
[Di 11. Sep 00:27:15 CEST 2018] Please define a shared secret.

However, Mobile TAN isn't activated.

Steps to reproduce

1. Install acme.sh plain, non-containerized
2. Configure it to use INWX DNS validation
3. Issue a certificate
4. Wait for renewal via cron

Debug log

"/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" --debug 2

This just works. It is currently 11 hours after i got the email above. I currently have no idea why the manual execution works, but the cron refresh doesn't. I'll open this issue anyway, maybe there are other users with the same problem.

[danielclasen]

The same thing happened to me twice in september as well (on 1st and 25th). But as it is highly irregular and working at least on the next day again it might be an issue on INWXs side... or just a hiccup in their API.

[zimbodan]

I've seen the same behaviour today as well - issuing a certificate from bash. It occured when generating the TXT record to the file as well when deleting it again. Interestingly it seems to currently have no effect on the execution of the script itself as the certificate is properly issued.

[Tue Nov 6 09:36:33 CET 2018] Registering account [Tue Nov 6 09:36:35 CET 2018] Registered [Tue Nov 6 09:36:35 CET 2018] ACCOUNT_THUMBPRINT='LIXJ1B5kOQIXYF8Q1GVs7G9mmWbiGLc98wWonoMQVwg' [Tue Nov 6 09:36:35 CET 2018] Creating domain key [Tue Nov 6 09:36:35 CET 2018] The domain key is here: /root/.acme.sh/[our domain]/[our domain].key [Tue Nov 6 09:36:35 CET 2018] Single domain='[our domain]' [Tue Nov 6 09:36:35 CET 2018] Getting domain auth token for each domain [Tue Nov 6 09:36:35 CET 2018] Getting webroot for domain='[our domain]' [Tue Nov 6 09:36:36 CET 2018] Getting new-authz for domain='[our domain]' [Tue Nov 6 09:36:37 CET 2018] The new-authz request is ok. [Tue Nov 6 09:36:37 CET 2018] Found domain api file: /root/.acme.sh/dnsapi/dns_inwx.sh [Tue Nov 6 09:36:37 CET 2018] Mobile TAN detected. [Tue Nov 6 09:36:37 CET 2018] Please define a shared secret. [Tue Nov 6 09:36:38 CET 2018] Adding record [Tue Nov 6 09:36:38 CET 2018] Sleep 120 seconds for the txt records to take effect [Tue Nov 6 09:38:40 CET 2018] Verifying:[domain] [Tue Nov 6 09:38:43 CET 2018] Success [Tue Nov 6 09:38:43 CET 2018] Removing DNS records. [Tue Nov 6 09:38:44 CET 2018] Mobile TAN detected. [Tue Nov 6 09:38:44 CET 2018] Please define a shared secret. [Tue Nov 6 09:38:44 CET 2018] Deleting record [Tue Nov 6 09:38:45 CET 2018] Verify finished, start to sign. [Tue Nov 6 09:38:47 CET 2018] Cert success.

[simonszu]

Yeah, i have seen it a few times in between again. Usually it is sufficient to just run the cert issuing again right afterwards, then it would succeed.

[zimbodan]

I opened a ticket with INWX today so they can investigate. Obviously it is a '-z' value that is returned by the API and interpreted by the script as an error.

[speedmann]

It looks like the API now always contains tfa in the login response <member> <name>tfa</name> <value><string>0</string></value> </member>

Therefore if _contains "$response" "tfa"; then(line 161) is always true I currently do not have 2fa activated and i am traveling, but i do get an Command completed successfully back without 2fa enabled. Can anyone confirm the response does not contain this when using 2fa? If this is the case, we could test for Command completed successfully or we have to figure out how to check if tfa != 0.

Can anyone possible post a response you receive when 2fa is actually activated and the secret has not been set? Make sure to remove sensitive data like accountID and customerID

[ChillerDragon]

Can anyone possible post a response you receive when 2fa is actually activated and the secret has not been set? Make sure to remove sensitive data like accountID and customerID

Not sure if this is what you need. But that is the response I get when logging in to the json api to my account that has 2FA activated.

#!/bin/bash

source .env

read -r -d '' INWX_LOGIN_CMD <<EOF
{
       "method": "account.login",
       "params": {
               "user": "$INWX_USER",
               "pass": "$INWX_PASS"
       }
}
EOF

curl --silent -X POST --data "$INWX_LOGIN_CMD" https://api.domrobot.com/jsonrpc/ | jq .

{
 "code": 1000,
 "msg": "Command completed successfully",
 "resData": {
   "customerId": 0,
   "customerNo": 0,
   "accountId": 0,
   "tfa": "GOOGLE-AUTH"
 }
}