DNS challenge failing


#1

Hello,

I have a certificate for the domain bvergnaud.fr that I initially generated by hand, interactively, with certbot.
I’m trying to renew it now using DNS challenges, so that I can automate the renewal.
My domain is hosted by OVH. In case it is relevant, DNSSEC and ANYCAST are enabled for this domain.

The command I run :

certbot certonly --renew-by-default --server "https://acme-v02.api.letsencrypt.org/directory" --dns-ovh --dns-ovh-credentials /config/dns-conf/ovh.ini --manual-public-ip-logging-ok --rsa-key-size 4096 -m 'me@kry.wtf' --no-eff-email --agree-tos -d *.bvergnaud.fr -d bvergnaud.fr

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-ovh, Installer None
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for bvergnaud.fr
dns-01 challenge for bvergnaud.fr
Cleaning up challenges
Unable to determine zone identifier for bvergnaud.fr using zone names: [u'bvergnaud.fr', u'fr']

This happens in a docker container:

root@eae8e4993084:/$ cat /etc/os-release 
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.8.1
PRETTY_NAME="Alpine Linux v3.8"
HOME_URL="http://alpinelinux.org"
BUG_REPORT_URL="http://bugs.alpinelinux.org"

I’m having trouble identifying what this error means. Googling it raised only 5 result, all pointing to certbot’s source code, but even with that, I’m still unsure what the problem is exactly.

The way I understand the code, I don’t even know how I reach this exception. There are domain_name_guesses, I should go in the for loop, and either succeed authenticating, or return in one of the two exceptions being caught, given that the second one is generic and should therefore be caught in any odd case.

I’ve been banging my head on this all afternoon. I’ll gladly take any help.

Thanks.


#2

This requires quotes:
-d "*.bvergnaud.fr"


#3

Indeed, good catch.
It doesn’t fix the problem, however.


#4

Did it “change” the problem?


#5

Sorry, I should have been clearer. The problem remains exactly as is. No change.


#6

What version of certbot are you running?


#7

From my time working with Lexicon, the error to me indicates that the domain can’t be found in your OVH account’s DNS zones.

My other theory is that Lexicon is mishandling the wildcard.

Can you tell me, if you run Certbot with --staging and without the *. wildcard, does it succeed?


#8

@rg305 certbot 0.27.1.

@_az Looks like it’s no better:

root@eae8e4993084:/$ certbot certonly --renew-by-default --staging --dns-ovh --dns-ovh-credentials /config/dns-conf/ovh.ini --manual-public-ip-logging-ok --rsa-key-size 4096 -m "me@kry.wtf" --no-eff-email --agree-tos  -d "bvergnaud.fr"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-ovh, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for bvergnaud.fr
Cleaning up challenges
Unable to determine zone identifier for bvergnaud.fr using zone names: [u'bvergnaud.fr', u'fr']

IMPORTANT NOTES:
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

As for it not finding the domain in my account, I assume it could be from invalid credentials in my ovh.ini file ? I don’t think I made a mistake there but I’ll triple check just to be safe :slight_smile:


#9

I think that the error would be different if the credentials were wrong.

What if you try list your zones via API?

#!/usr/bin/env bash

# https://eu.api.ovh.com/createToken/
APPLICATION_KEY="replace me"
APPLICATION_SECRET="replace me"
CONSUMER_KEY="replace me"
URL="https://eu.api.ovh.com/1.0/domain/zone" # or ca instead of eu

NOW=$(date +%s)
DIGEST=$(echo -n "$APPLICATION_SECRET+$CONSUMER_KEY+GET+$URL++$NOW" | sha1sum | awk '{print $1}')

curl -H "X-Ovh-Application: $APPLICATION_KEY" \
-H "X-Ovh-Consumer: $CONSUMER_KEY" \
-H "X-Ovh-Timestamp: $NOW" \
-H "X-Ovh-Signature: \$1\$$DIGEST" \
-i "$URL"

#10

I get the following:

{
    "errorCode": "NOT_GRANTED_CALL",
    "httpCode": "403 Forbidden",
    "message": "This call has not been granted"
}

Which, I presume, is why Lexicon is unhappy.
Here are the rules available for those credentials:

[
    {
        method: "GET"
        path: "/domain/zone/*"
    },
    {
        method: "PUT"
        path: "/domain/zone/*"
    },
    {
        method: "POST"
        path: "/domain/zone/*"
    },
    {
        method: "DELETE"
        path: "/domain/zone/*"
    }
]

Are these correct ?
For the record, I got them from the doc:
https://certbot-dns-ovh.readthedocs.io/en/stable/


#11

I just passed * as the path in the token creation interface for that script with a short validity. We only want to determine whether your account actually contains that domain.

Edit: But I guess you can also alter the script to use /zone/ instead of /zone which should match your rules.


#12

Ok so, testing a bit further with credentials that have access to GET on /*, I could list the domains.
So I created proper credentials with the same list of of rules but an additional access to GET on /domain/zone and it works too.

The API’s answer DOES list the domain bvergnaud.fr.

However, certbot is still not happy, still with the same error, when I use these credentials.


#13

For the hell of it, I just tried with credentials with the following (generous) rules on the OVH API:

{
    "method": "GET",
    "path": "/*"
},
{
    "method": "POST",
    "path": "/domain/*"
},
{
    "method": "PUT",
    "path": "/domain/*"
},
{
    "method": "DELETE",
    "path": "/domain/*"
}

Running @_az’s script produced this:

% ./ovh.sh
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 09 Nov 2018 15:23:38 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 40
Connection: keep-alive
Vary: Accept-Encoding
Access-Control-Allow-Origin: *
Cache-Control: no-cache
X-Ovh-Queryid: EU.ext-5.5be5a67a.20511.ab6f4edd-304f-4ed4-a584-b227b114524e
X-Recruitment: You know how to code? This is a good start, but it may not be enough! We are looking for engineers who LOVE coding. Programming enthusiasts, code aesthetes, CTF winners, ... In short, geeks eager to learn, obstinate, involved. You want to challenge yourself? Join us! http://ovh.jobs
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
X-Content-Type-Options: nosniff

["kry.wtf","bvergnaud.fr"]

Certbot failed with the same error as before.


#14

:thinking:

Have you tried with Certbot 0.28.0? Since 0.27.1, Lexicon v3 compatibility was added, which did affect the OVH DNS provider.

Maybe @bmw has an idea on what’s happening :man_shrugging: .


#15

Well that did it. \o/

Since the docker image I used installs certbot with pip, I assumed I was already using the latest. It never occured to me to try an upgrade. Must be needing a rebuild.

Anywho, thanks a bunch @_az !


#16

Maybe @bmw has an idea on what’s happening :man_shrugging: .

Unfortunately I don’t, so I asked a Lexicon contributor and while they’re not sure either, they made a lot of changes with their v3 release which seems to have fixed something.

The certbot-dns-ovh Docker image is built using Certbot 0.28.0 and Lexicon 3.0.1 so people using that shouldn’t hit this problem going forward.


#17

I love the slick well placed ad.
LOL