Expressway - ACME - CSR

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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

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

Is there any alternative way to send the CSR to get signed by the Let’s Encrypt?

Any help? Anyone with a similar scenario?

1 Like

indeed, there is no A record for that domain. what are you trying to do?

what is this?

to the acme directory? no.

1 Like

Hi @ricardo.godinho

start with some basics:

If you have root access, perhaps another client may be a solution.

1 Like

The expressway is the

The ACME Certificate Service is service that allows you to communicate directly through the expressway so you can send the CSR directly to get signed.

My last question was if bu having the CSR, as I actually have, how can I get that signed?!

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

1 Like

Hi @ricardo.godinho

looks so. If that tool uses http validation, you need an A-record.

But checking your domain -

Host T IP-Address is auth. ∑ Queries ∑ Timeout Name Error yes 1 0 Name Error yes 1 0

There is no A or AAAA record.

Has that machine a public ip address? If yes, add that ip address in your dns management.

1 Like

OK. I will ask the customer to point the expressway hostname to its public ip address!
Let’s see if it resolves after that!

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 03/30/20 11:01:45

Do you have any idea why is this message?

I’ve investigated a bit but still without success:

Expressway public name (DNS):


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

According to the logs:

Invalid response from []: "\r\n<html xmlns=“http” Failed authorization procedure. (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from

My question is if it is normal that the Let’s encrypt is getting the token/challenge from the rather than the specific server:

Thank you!


is no webserver, no answer.

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 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.

Thanks for your answer. The problem I’m facing right now and that may cause a huge issue is the following:

So what happens is:

  • The challenge is being made to the ( and not to the ACME Client / Expressway.

  • Pointing the Domain public IP to the Expressway-E will cause a tremendous problem in everything that is hosted there.

So, at this point I’m stuck in here.

Any idea?

I’ve only skimmed through this thread but if you need a certificate for then that has nothing to do with - if you are using the built in ACME system of expressway (which is right?) and it’s resulting in a challenge to then your configuration in Expressway seems to be wrong. It should only be trying to acquire a certificate for

If the problem persists, contact Cisco support, that’s what you’re paying them (lots of money) for!

1 Like

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 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.)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.