I am using the getssl client to do the DNS challenge for my domain.
However, when the domain is being verified, I get stuck at “Pending” (outputted when we haven’t received a reply from the server).
srvrco believes that this is an error with the ACME server not responding to the domain. Here is a link to the discussion we had.
The domain is spydar007.net.
Has anyone else had this issue, and is there anything I can do to fix it?
@jsha @schoen @pfg @cpu any ideas on this one ? it’s not one I’ve seen before. The DNS seems to have the token listed correctly, it isn’t getting a “fail”, just a “pending” which remains as a pending.
Hi @serverco, @Spydar007:
I checked into this for you and it looks to me like you might have fallen into the case I described on an update to the authz announcement thread:
If your client creates an authorization object and expects to solve multiple challenges it will appear as though some of the challenges are stuck in a pending state. Once the first challenge for an authorization is satisfied and valid the overall authorization changes to valid and no subsequent challenges will be updated. E.g. if I create an authorization and complete the http-01 challenge the authorization will be marked valid and the dns-01 and sni-01 challenges will remain in a pending state.
When I checked the production server logs I can see that the overall authorization for spydar007.net is valid, and was confirmed by way of a http-01 challenge (which itself is marked valid). The dns-01 and tls-sni-01 challenges for the authorization are marked pending. Since we have a valid authz already we won't verify the DNS-01 challenge for this identifier/account.
Does this make sense given what you two know so-far? If so I would recommend the client code be updated to evaluate the overall authorization record instead of the individual challenges.
Many Thanks, I hadn’t spotted that and realised there was already a valid autorization via http. I’ll look at updating the getssl code to check that.
Happy to help! For additional context we will likely be proposing changes to the ACME spec in the IETF WG soon such that challenges don’t have a validity status outside of the authorization (called an “application” in current draft) to help avoid this confusion when authz’s are reused.
@cpu, so how do I go about using dns-01? I used the http-01 challenge first, but because I’m using the certificates across multiple servers with multiple subdomains, I decided that dns-01 would be way easier. Can the old http-01 verification be removed so that dns-01 will pass?
@spydar007 Right now we expire valid authentications after 90 days*. Unfortunately there isn't a way to deactivate a valid authorization on-demand. We have a Boulder issue open to track adding that feature and a pull-request is under way. I don't have an ETA for that feature but I suspect it will be deployed to staging in the next couple of weeks.
I'm sure that's not what you were hoping to hear. Thanks for your patience.
* This is likely going to be reduced even further in the near future
So....are you saying I can't get a certificate for that domain with the dns-01 challenge for 90 days? Does this mean that when I add the subdomains, I'm going to have to use the HTTP verification?
Yes - or until the explicit authentication deactivation feature is available, whichever is first.
Does this mean that when I add the subdomains, I'm going to have to use the HTTP verification?
This authorization is just for the top level spydar007.net domain. I believe you can use DNS-01 verification for the subdomains.
Hopefully @serverco will be able to update the code so that it knows you don’t need to pass any further challenge for that name for (approximately) 90 days.
In this case you should be able to say you’re going to pass DNS or HTTP or, I don’t know say a hypothetical custard pie race challenge, and before it even tries the challenge getssl will spot you’ve passed one already, and skip it for that name. Other names you haven’t passed any challenge for yet still need to pass a new challenge.
Done well this should “just work” although of course it’s some effort for @serverco - like a swan swimming, it looks effortless but there’s frantic work under the water.
updates to getssl completed, and tested working on all my test scenarios. Thanks 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.