Challenge failed for domain

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: domain.com

I ran this command: certbot renew --dry-run

It produced this output:

*Cert is due for renewal, auto-renewing...*
*Plugins selected: Authenticator dns-google, Installer None*
*Renewing an existing certificate*
*Performing the following challenges:*
*dns-01 challenge for mydomain.com*
*dns-01 challenge for mydomain.com*
*URL being requested: GET https://www.googleapis.com/discovery/v1/apis/dns/v1/rest*
*URL being requested: GET https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones?alt=json&dnsName=mydomain.com.*
*URL being requested: GET https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones/4482075479114290134/rrsets?alt=json*
*URL being requested: POST https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones/4482075479114290134/changes?alt=json*
*URL being requested: GET https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones/4482075479114290134/changes/493?alt=json*
*URL being requested: GET https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones/4482075479114290134/changes/493?alt=json*
*URL being requested: GET https://www.googleapis.com/discovery/v1/apis/dns/v1/rest*
*URL being requested: GET https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones?alt=json&dnsName=mydomain.com.*
*URL being requested: GET https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones/4482075479114290134/rrsets?alt=json*
*URL being requested: POST https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones/4482075479114290134/changes?alt=json*
*URL being requested: GET https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones/4482075479114290134/changes/494?alt=json*
*URL being requested: GET https://dns.googleapis.com/dns/v1/projects/verb-surgical/managedZones/4482075479114290134/changes/494?alt=json*
*Waiting 60 seconds for DNS changes to propagate*
*Waiting for verification...*
*Challenge failed for domain mydomain.com*
*Challenge failed for domain mydomain.com*

My web server is (include version): nginx

The operating system my web server runs on is (include version): Ubuntu 16.04

My hosting provider, if applicable, is: Use to be google domains, now moved to Verisign

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.0.0

Problem statement:
The original certificates are generated using command certbot -a dns-google -i nginx certonly \ --server https://acme-v02.api.letsencrypt.org/directory \ --email "${LETSENCRYPT_ADMIN_EMAIL}" --agree-tos --no-eff-email \ -d "*.${host}" \ -d "${host}"
Later, the hosting domain moved from google domains to verisign. I see no plugins to validate the dns challenge for verisign unlike dns-google plugin. Now, I'm trying to renew the certificates and without mentioning the dns-google plugin, it is trying to access dns.googleapi to verify the challenge. Is there a way to generate TXT record using certbot and add the record in verisign? Will that even bypass the dns-google plugin? I tried to hide the domain, I don't think domain name matters in my case.

Also, I do see some API requests coming in at google console end with TXT record information with Rrdata. If I add that TXT record manually in Verisign, will it work? I have no control over Verisign side, so checking before requesting to add TXt record.

1 Like

You mention the Hosting Service Provider (HSP) changed.
OK.
But did the DNS Service Provider (DSP) change?

Without a domain name it makes things very difficult for us to visualize and/or troubleshoot.

That looks like you are trying to add a record to the VERISIGN.com domain:
image

1 Like

Additionally, I don't see the use of --dns-google-credentials
Are you sure you were using DNS-01 authentication?

1 Like

image
Both HSP and DSP changed from Google cloud (Google domains & Google Cloud DNS) to Verisign.
The domain name is verbsurgicaleng.com
image
No, our domain name starts with 've' and it is not verisign.com

I'm not sure how it was working without --dns-google-credentials, but it is using DNS-01 auth and working until move to verisign.

1 Like

I'm sorry I don't have better news for you...
But I can't find an ACME client that lists API support for Verisign.

You will have to either:

  • use manual DNS authentication (not recommended - automation is key)
  • switch to HTTP authentication (not allowed for wildcard certs)
  • switch DSP [HSPs and DSPs are mutually exclusive]
  • augment your DNS implementation to include an alternate DNS method of authentication
    like: by setting a CNAME to another DSP or to a self-managed DNS system
  • use CDN [like: Cloudflare] (not recommended - huge security tradeoff)
  • pay Verisign to solution this problem (surely they will be glad to charge a fee to resolve a problem they created)
2 Likes

I think you mean to say here that the DNS service provider doesn't need to be the same as the hosting service provider (i.e., you can have two different providers for both services), but that's not what I read in your sentence when I read it more literal. Because now you're saying "the DNS service provider and hosting service provider cannot be the same", which is not true?

Like acme-dns!

I think "huge" is quite subjective here, unless you have proof of major security breaches in the past with CDNs?

1 Like

I want speed, high availability and a global presence, DDoS protection, etc.
But all that comes with a security price "tradeoff"; Of installing a vendor owned/operated MITM system.
Just because someone you trust hasn't broken that trust doesn't mean there isn't a huge risk being taken by having to trust a third party with your secure information.
Can you honestly say that using a MITM system doesn't fit "huge security tradeoff"?

1 Like

As I said, I think it's subjective. Do you trust a virus scanner to do MitM on your HTTPS, so it can intercept malware? I can guess what your opinion is, but the matter of fact is: it's a trust thing. And I believe it's up to everyone to determine for themselves if it's a tiny, small, normal, big or huge security tradeoff.

Anyway, we're going offtopic. My point was: in my opinion you're statement was your opinion and I think it's better to make objective suggestions instead of opinions. Or make clear it's your opinion instead of a fact.

2 Likes

I do get the feeling that I should clarify/emphasize more on what is my own opinion and will strive to do so henceforth.

But you can't equate a MITM service that runs within your own computer (Anti-Virus) to a MITM service that runs in someone else's "computer" (online CDN).
I guess the values:

are completely subjective; But clearly the two examples mentioned aren't equal - one is bigger than the other.

2 Likes

They're certainly different, I agree. It's just up to the user to determine if the security tradeoff is worth it or not.

2 Likes

@rg305 Thank you for listing down my options. I will go with manual DNS authentication for now to get unblocked and work with Verisign for a better automated solution.

2 Likes