Challenge still pending after 4 days

Hello there,

I recently had to migrate my server hence I changed:

  • IP address (DNS entries changed 4 days ago) for my domain finart.xyz
  • client (letencrypt's official client → acme-tiny from debian/jessie)

On my previous setup, it was working fine, i.e. I used to receve certificates.

I re-used my account and server keys by following acme-tiny's guide, but the validation is still pending:

Output of the script:

user@machine: acme-tiny --account-key /etc/letsencrypt/account.key --csr finart.xyz.csr --acme-dir /var/www/acme-challenge/ > signed.crt
Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying finart.xyz...
Challenge URI: https://acme-v01.api.letsencrypt.org/acme/challenge/yIjLvQFg72p8OjQ0ThCBpRxGDP4RiaT3yqWaQmafucY/95932503
[...]

I added the URI display to see it; the json says 'pending' as does the script that infloops while waiting for file change.
I ran a tcpdump to see incoming traffic on HTTP but saw nothing (interesting) except the script itself that does verify that redirect is ok, of course querying the challenge URL from an other host does return something (token . something).

Every time I re-run the script, it re-uses the same challenge URI (might be ok), but the status is still pending.

Notes:

  • with my previous server, I was issuing certificate for two domains (finart.xyz and mail.finart.xyz), I changed to only generate cert for finart.xyz
  • I first tried it on 31/01/2017, and the script stopped due to acme-v01 migration

Any thought ?

Thanks,

Marc.

Could you try applying the patch from this pull request and see if that solves the problem? I believe you’re running into this issue because Let’s Encrypt started reusing existing valid authorizations a few months ago.

1 Like

Well spotted, it indeed is the issue I'm running into. However the patch from the PR does not seem to exactly fix my issue since the 'first' challenge in the json is my http-01 challenge and not the 'valid' one that 'blocks' other challenges. > json: {

"expires": "2017-03-22T07:58:46Z",
"identifier": {
    "type": "dns",
    "value": "finart.xyz"
},
"combinations": [
    [
        2
    ],
    [
        0
    ],
    [
        1
    ]
],
"status": "valid",
"challenges": [
    {
        "type": "http-01",
        "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/yIjLvQFg72p8OjQ0ThCBpRxGDP4RiaT3yqWaQmafucY/95932503",
        "token": "AiH_2XjB0w-HR5Ly9i6EeJy17eXD2-C-42Wk7yWjUZo",
        "status": "pending"
    },
    {
        "keyAuthorization": "...",
        "status": "valid",
        "validationRecord": [
            {
                "addressesResolved": [
                    "62.210.243.75"
                ],
                "hostname": "finart.xyz",
                "port": "443",
                "addressUsed": "62.210.243.75"
            }
        ],
        "type": "tls-sni-01",
        "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/yIjLvQFg72p8OjQ0ThCBpRxGDP4RiaT3yqWaQmafucY/95932504",
        "token": "OE0RK76ZC8gG54w_7OWQFYd3ugbhIW2pUqSrtkf4gJ0"
    },
    {
        "type": "dns-01",
        "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/yIjLvQFg72p8OjQ0ThCBpRxGDP4RiaT3yqWaQmafucY/95932505",
        "token": "4trOujwa0WNom2fS-p1rb3LYLXocXmFfdE4XaGrCYCg",
        "status": "pending"
    }
]

}

To my point of view, the PR is not the correct fix, since it could install the "valid" challenge (only if it comes first) but for a wrong type. I patched by first checking that a challenge is valid to skip the whole challenge/verification part. Doing that led acme-tiny to ask for cert signature (as claimed by the PR) and generated a valid certificate.
I should open a PR against acme-tiny but am unsure to have the time for that, and worse, it does not seem that the project (at least diafygi/acme-tiny) is maintained. I might chose an other light client.

Thanks for help.

Marc.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.