DNS TXT - I had insert the dns entries but don't spread fast enough - What to do?


#1

Hello all,

So. I had insert the dns TXT entry in all 3 domain (vide image)

But:

Waiting for verification...
Cleaning up challenges
Failed authorization procedure. i2u.com.br (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.i2u.com.br, webid.com.br (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.webid.com.br, libraslivre.com.br (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.libraslivre.com.br

Problem:
I think that the DNS do had spread fast enough…
Now, I’m sure that is totally spread and what i had to do?

  1. I think if I execute the same command again, the key on the DNS Entry will need to change… So i think that isn’t what i have to do.
  2. Execute some command to re-do the verification and continue the process, but what command and what to do next?

__before sending i had research about but i don´t find anything that was approachable in my point of view. Because all steps i saw i need to run the same command again and like i sad before on item 1. __


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. https://crt.sh/?q=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: i2u.com.br, webid.com.br, libraslivre.com.br
[fmorais.com.br too but isn’t in this scope]

I ran this command: sudo certbot --server https://acme-v02.api.letsencrypt.org/directory -d .i2u.com.br,.webid.com.br,*.libraslivre.com.br --manual --preferred-challenges dns-01 certonly

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): [ommited]

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: a

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: y
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for i2u.com.br
dns-01 challenge for libraslivre.com.br
dns-01 challenge for webid.com.br

-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: y

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.i2u.com.br with the following value:

U*****************************************E

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.libraslivre.com.br with the following value:

e*****************************************k

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.webid.com.br with the following value:

l*****************************************Q

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. i2u.com.br (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.i2u.com.br, webid.com.br (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.webid.com.br, libraslivre.com.br (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.libraslivre.com.br

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: i2u.com.br
   Type:   None
   Detail: DNS problem: NXDOMAIN looking up TXT for
   _acme-challenge.i2u.com.br

   Domain: webid.com.br
   Type:   None
   Detail: DNS problem: NXDOMAIN looking up TXT for
   _acme-challenge.webid.com.br

   Domain: libraslivre.com.br
   Type:   None
   Detail: DNS problem: NXDOMAIN looking up TXT for
   _acme-challenge.libraslivre.com.br
 - 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.

My web server is (include version):
nginx version: nginx/1.14.0 (Ubuntu)
built with OpenSSL 1.1.0g 2 Nov 2017
TLS SNI support enabled
configure arguments: --with-cc-opt=’-g -O2 -fdebug-prefix-map=/build/nginx-FIJPpj/nginx-1.14.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2’ --with-ld-opt=’-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC’ --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module

The operating system my web server runs on is (include version):
ubuntu 18.04 server lts
My hosting provider, if applicable, is:
locaweb (VPS)
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


#2

The three domains shown are using the same DNS provider and thus have the same refresh/retry wait times:
refresh = 3600 (1 hour)
retry = 600 (10 minutes)
You may need to wait long enough for the entries to propagate.
Probably more than 10 minutes to be sure.


#3

You’re correct that the DNS record value will change when you run the command again. Unfortunately, it is exactly what you have to do. :sweat:

It’s not possible to retry a challenge with the same value. You have to run the command again, and set the new values.

By the way, *.example.com does not include example.com. If a user visits https://i2u.com.br/ or so forth – instead of a subdomain like https://www.i2u.com.br/ – they will get an error. To fix that, you’d have to include all 6 names in the certificate, and set 6 DNS records to validate it.

And, of course, the DNS records will change again every time you renew the certificate every couple months.

DNS validation is much more pleasant if you can fully automate DNS record changes. Maybe you can switch DNS providers, use dynamic updates if your provider supports them, use something like acme-dns, or develop a custom plugin for Certbot or another client.

Edit: Also, you don’t have to specify “--server https://acme-v02.api.letsencrypt.org/directory” with recent versions of Certbot. It’s taken care of automatically now. I’m not sure whether the version of Certbot you’re using is new enough, though.


#4

@mnordhoff, @rg305
First all, wow the most fast answer i had in any community forum so ever.
Secondly, thank you. Really detailed answer.
Finally, so, yet i do not know what to do, so more question, some could escape the scope:

obs.: If i run the commands again, will not (like you predicted) fit my needs. This panel in screenshot is the only way i could made DNS Entry changes. And do not spread fast enough the changes.

  1. what is the most easiest way i could have the 3 wildcard domain certificated? (i don’t familiar with any of this).
    1.a) I had read the dynamic updates that you linked… but i flying on it.
    1.b) use http instead is less recommended or insecure?

… i will let the other questions to another time… lets see the path this take.


#5

that i know of… i can configure in a vps others dns zone manager without negative interfere with general provider dns zones ?


#6

I could install or configure BIND9 (for example) and do this without messing around?


#7

This sounds like a job for acme-dns. I found it kind of confusing at the outset, so started a thread for some clarification–that thread is at:


#8

You need to understand how Internet DNS works.
The root DNS servers (".") know where the “.br” DNS servers are.
The “.br” DNS servers know where the “.com.br” DNS servers are.
The “.com.br” DNS servers know where your domains are.
Your domain registrar contains the DNS information for your domains.
They are responsible for updating the “.com.br” DNS servers with your specific information:
Which is presently:
ns1.locaweb.com.br [ 189.126.108.2 | 2804:218:d3::faca ]
ns2.locaweb.com.br [ 201.76.40.2 | 2804:218:d2::café ]
ns3.locaweb.com.br [ 187.45.246.2 | 2804:218:d1::ca5a ]
If you add “your own” DNS servers, they may not “interact” well with the existing DNS servers.
You can replace the existing DNS servers with your own DNS servers…


#9

…unless you put them on a subdomain, as acme-dns does.


#10

If they could run acme-dns, they could/would be running their own DNS servers.
Which is far from the typical “GoDaddy” users’ expertise and comfort zone.


#11

Likely so, but we aren’t dealing with a GoDaddy user, typical or otherwise.


#12

Really??
You can change the service provider name but that doesn’t change the situation.


#13

I don’t understood all informations…

This way I ask… If isn’t better I simply do not use wildcard for my case… IDK, so much job.
And is less than 5sub per domain.

I really want to use wildcard certs… But in a really simple way, if exists one, without using a possible breach like:

"deploying a global API key that can, if compromised, do anything to any of the DNS records for any of my domains"


#14

Let’s Encrypt wildcard certs are only available when you prove control of your domain at least every 90 days by creating custom DNS TXT records. The content of the TXT records is different every time. While it is definitely possible to avoid having

a global API key that can, if compromised, do anything to any of the DNS records for any of my domains

it’s not possible to have that in “a really simple way”, unless a domain registrar or hosting provider automates this for you.


#15

Ty all.
Since my native language isn’t English and I don’t feel 100% secure doing this configurations with any plugin I won’t be doing this by now.
But I will use per domain/subdomain. Will study more about how do this and maybe other time I try again. TKS.


#16

Many people here speak many different languages.
Feel free to open another ticket in your native language and you may get a better/clearer understanding.


#17

Por exemplo, eu falo portuguĂŞs do Brasil que parece ser o idioma nativo do @wallas. :slight_smile:


#18

Que Maravilha… Era tudo o que eu precisava.
[Edit]
Posso continuar nesse tĂłpico? Ou prefere que eu crie outro? @schoen
[Edit2]
Vou continuando nesse, qualquer coisa abro outro.

Então, há alguma diferença significativa (em questão de segurança) entre usar dns-01 ou http-01 (manual ou webroot)?

Outra coisa, estava pensando como seria possĂ­vel eu criar na minha prĂłpria api um endpoint (similar ao dos outros pluguins).

[Edit3]
Como estou usando o NGINX apenas para fazer o reverse-proxy dos domínios e sub-domínios e usando NodeJS para realmente servir as aplicações e os arquivos estáticos meio que poderia dar alguns problemas. Que se eu pudesse servir pela minha API resolveria.


#19

Qual aspecto de segurança?

  • O dns-01 pode emitir um certificado wildcard, e o http-01 nĂŁo.
  • O certificado em si Ă© o mesmo e nĂŁo indica como a AC verificou os domĂ­nios.
  • No prĂłprio processo de verificação, o http-01 abre mais possibilidades de ataque porque a AC precisa contectar-se diretamente ao seu servidor. Entretanto, a possibilidade de ataque nĂŁo fica maior por causa do uso do http-01 pelo usuário; o cenário de ataque nĂŁo Ă© algum tipo de interferĂŞncia com um pedido legĂ­timo, mas um pedido independente por um terceiro malicioso com capacidade de manipular a rede.

Também há a diferença que o manual plugin não pode fazer uma renovação automática do certificado (sem um script de autenticação que ensina o plugin a fazer as mudanças necessárias no DNS sem assistência humana). O webroot plugin pode fazer a renovação sem ajuda de um ser humano e normalmente pode fazê-lo num cronjob.

Qual tipo de endpoint? Para fazer o que?


#20

As respostas anteriores já meio que respondem essa… a não ser que eu use http-01 para configurar os crons.