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.
This still means nothing to me: is it a proxy? is it an acme server?
You can choose one of many acme clients that have that functionality (most of them, I’d say) and tell them to get a certificate based on that csr. But none of them will be able to get a certificate for a domain that points nowhere (unless you use dns-01 validation)
Also, as your Cisco Expressway system is running your ACME client (requesting certificates) and serving the challenge responses (answering http challenges from Let’s Encrypt) you can only request certificates for domains that the Expressway system actually hosts, i.e. domains that point directly to the Expressway system.
I’ve only skimmed through this thread but if you need a certificate for expe.abreuadvogados.com then that has nothing to do with abreuadvogados.com - if you are using the built in ACME system of expressway (which is expe.abreuadvogados.com right?) and it’s resulting in a challenge to abreuadvogados.com then your configuration in Expressway seems to be wrong. It should only be trying to acquire a certificate for expe.abreuadvogados.com.
If the problem persists, contact Cisco support, that’s what you’re paying them (lots of money) for!
Right, an important difference for @ricardo.godinho to understand between Let’s Encrypt and other CAs here:
With some other CAs you send in a CSR “asynchronously”—whenever you want—and the CA then tells you some step that you have to take in order to get it signed (maybe confirming receipt of an e-mail).
With Let’s Encrypt, the software that requests the certificate will be told the necessary step right away and is expected to perform the verification step itself, immediately. There is not supposed to be a human (you) involved in the verification. That means that most users need to run the Let’s Encrypt client application directly on the web server where the certificate will be used, so that the client application itself can perform the steps needed for the verification (for example, creating a file with a specified name and contents) before proceeding.with the process. Let’s Encrypt certificates last for only 90 days and so this process will have to be repeated very frequently. Ideally, it should always be performed by software and never by an interaction involving a human completing the verification!
In the case where you need to get a certificate for a machine operated by someone else, Let’s Encrypt really does not have a general way to optimize this with the existing API and issuance technology. In the Let’s Encrypt design, normally most machines are supposed to request their own certificates for their own names. There are various ideas about delegating this authority by means of an HTTP 301 redirect or a DNS CNAME record, but it’s not straightforward “at arm’s length” without at least some proactive involvement of the operator of the device where the certificate will be used.
However, if you are the one who controls the entire domain name abreucardigos.com or if you operate its nameservers, there is a different method where Let’s Encrypt can check a DNS record (which should also be created from software, normally using a DNS API) and use that as the basis of the authorization to issue the certificate.
It’s also rare for people to have a good experience when using CSRs to request certificates from Let’s Encrypt. That’s because CSRs are easier to integrated into a manual workflow than into an automated workflow. Yes, the Let’s Encrypt technology uses CSRs internally behind the scenes, but they’re usually not submitted directly by the end user.
(Se você ainda tiver dúvidas e precisar de ajuda em português, posso tentar esclarecer as coisas em português também.)