What's the specific error being returned by the Let's Encrypt server?
If a (real) certificate has not been issued (like when there's an error), it won't appear on crt.sh. It could also be that your program is currently using the Let's Encrypt staging servers, which are for testing and don't generate real certificates.
I did a request to Lets Encrypt production server , but i don't kown why it is impossible to see the requests. It is true because on monday Let's Encrypt answered that the address did too many requests, now i need to waint one week to do a new request.
I have another question.
Within the crt.sh website is it possible to know which account made a request for that certificate? I do not know if I was clear, but for the domain that I am having problems there is an issuance of a certificate that the network administrator does not know who made this request and he needs to know who made this request and where is this certificate that was issued.
I really appreciate your help.
crt.sh is a site run by a different certificate authority that is querying only public information about certificates. That public information doesn't include any details about how or why the certificate authority decided to issue a certificate, or to whom.
Let's Encrypt does know this information, but normally treats it as private.
The certificate would have to have been created with a proof of control using one of these methods
Only HTTP-01 and DNS-01 are common. Perhaps if your web server keeps logs of accesses, and your DNS servers keep logs of updates, the administrator could check these logs to see if there are relevant HTTP accesses to a file under /.well-known/acme-challenge, or DNS updates to the TXT record _acme-challenge, around the time that the certificate in question was issued. Then the administrator could try to determine who would have been authorized to make those changes.
If you have a server that's using an ACME client like Certbot (or a web server like Caddy), it may be automatically renewing old Let's Encrypt certificates 30 days before they expire—without further human intervention—even if those certificates are no longer otherwise in use in your infrastructure.