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.
Using the Expressway ACME Certificate Service we get the error: There was a problem with a DNS query during identifier validation, Domain A-Record lookup failed for aca.abreucardigos.com
Is there any alternative way to send the CSR to get signed by the Letâs Encrypt?
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)
Thatâs the problem Iâm facing in the Sign CSR. So does it mean that the A-Record lookup on the customer public DNS failed for aca.abreucardigos.com?
Iâve solved the issue with the mentioned domain but Iâm facing an issue still, now with the following message when trying to sign in the certificate with letâs encrypt:
Sign Alarm: The client lacks sufficient authorization, There was an invalid response from abreuadvogados.com: 03/30/20 11:01:45
When trying to Sign CSR with Letâs Encrypt, I get the error reported in the last update: Sign Alarm: The client lacks sufficient authorization, There was an invalid response from abreuadvogados.com
Looks like a redirect subdomain -> domain. But if the domain has another ip address, that can't work if you start the client on the 194.38.142.47 machine.
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.
