By mistake I ended up with two _acme-challenge txt records on the dns for this domain.
When I noticed it and after trying to figure out which one was the correct without any luck I deleted both thinking that the process might generate a new _acme-challenge info so I could add it to the dns again, which it did not happen and now obviously the renewal process fails since the _acme-challenge txt record is missing.
Is there anyway / anywhere I can get back the correct _acme-challenge txt record data to put back on the dns?
The current certificate is still valid until March 9, 2022
My domain is: bijoux.pt
I ran this command: Renewal it's auto run by the Plesk interface
It produced this output: ------
My web server is (include version): Apache 2.4.37-43 / PHP 7.4.27-1
The operating system my web server runs on is (include version): CentOS Stream 8
My hosting provider, if applicable, is: OVH
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): Plesk Obsidian Version 18.0.41
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): ----
You need not worry since _acme-challenge TXT records for the DNS-01 challenge are only used once and should be removed immediately after each verification attempt regardless of whether the verification succeeded or failed.
If, on the other hand, you removed an _acme-challenge CNAME record, which delegates the DNS-01 challenge to another domain name, that would need to be restored.
I use a mix system, the dns is on OVH system and on my the actual dedicate servers I do not run dns (bind) at all, email is also elsewhere (on google) so I do have to add records by hand and in this case I'll delete them too.
If you're adding DNS TXT records manually, the certificates won't renew automatically. Automatic renewal for DNS-01 assumes that you have a method for automatically adding and removing the TXT records.
Also, some hints regarding your CAA records:
;; ANSWER SECTION:
bijoux.pt. 3600 IN CAA 1 issuewild "letsencrypt.org"
bijoux.pt. 3600 IN CAA 1 iodef "mailto:email@example.com"
bijoux.pt. 3600 IN CAA 1 issue "letsencrypt.org"
You have set the least significant bit of the flags value on your CAA records. As per RFC 8659, this bit is currently reserved for future use and must not be set.
You probably intended to set the critical flag, which would mean setting the MSb. However, the current spec doesn't allow that either, as that's meant for extensions, not the base spec. As per the current specification, the flag value should be 0. Let's Encrypts CAA checker is relatively permissive at this time, but future changes to the CAA specification can create unpredictable changes to that behaviour, if your CAA record violates the specification.
Additonally, having both issue and issuewild set to the same value is redundant. issue controls all issuance, if issuewild is not present. So you do not actually require the issuewild directive in your case.
Also, note that many CA's, including Let's Encrypt, do not support CAA iodef, so you won't see any mails regarding (failing) CAA.