Manual DNS method authorisation - failing


#21

Thanks, I’m using mx toolbox. Just delete the value you have and start again, you don’t need both. If you can use a lower TTL it may(?) affect propagation to your other nameservers. Let’s Encrypt will try any one of the authoritative nameservers for your DNS, you currently have 4 and they all have to respond with the same answer.


#22

it always seems to pass the first stage of authentication once i put the first TXT record in.
then it asks me to enter a second, i add an additional entry to the existing TXT record and that’s where it fails.


#23

So right now (this minute) your name server are not all reporting a TXT record at all, so if you’ve already created a new one with a new value then it hasn’t propagated to all the name server yet.

As your TTL is 60 mins I would delete your TXT record, wait an hour, run the request - ensure you are creating the TXT record value asked for at the bottom of the log file (older values won’t count), then wait 60 mins before resuming the request.

Make sure when you get to the ‘Waiting for User Action’ screen that it’s a new value, not the last one you were asked for. If it’s an old value close the UI and open it again to be sure, that steps should be unnecessary but I have seen it not update the Status tab before, until you close the managed certificate (little X on top right above Request Certificate) and open it again.
https://community.certifytheweb.com/uploads/default/original/1X/6d8a616ffadb0da7303cf1de9463ed49e4cc5b59.png

Hitting Request Certificate should then resume the request and either be successful or a complete fail. If it’s fail then it will show you the error and then need to start a whole new request to attempt validation again.


#24

that’s because i’ve deleted and i’m waiting a period of time before i try again.


#25

OK that’s me going to attempt this again.
i hit “request certificate”, it asked me to add a TXT record with the required string (ending “bmAFg”)
i have added that and i will now wait until i hit “request certificate” again.


#26

OK it has worked now, only asked for the one TXT record to be created and accepted it first time.
so i’m guessing previous failures were down to timing and propagation.


#27

Awesome, glad it worked.


#28

but please support google domains for automatic renewal :slight_smile:


#29

I really do want to! I just have a log of bugs to investigate and emails to answer etc, first up is support for ACME DNS and hopefully a certifytheweb branded CNAME redirection service as these would provide a workaround to cover almost all other DNS providers by pointing a one-time CNAME record in your DNS instead of updating TXT records all the time. It’s probably still best to support the DNS providers directly if we can, so that’s a goal.


#30

We also have wildcard domain about to expire, updated the new version on Centify and that’s when issues started. On previous versions we have renewed twice with success.

Today we updated manual DNS keys, then tried to renewal, however Centify is stuck permanently on a screen titled “Renew All”, “in Progress” with a message “Starting…” which has not completed in serval hours.
an we get previous version to test if the issue is present or not?

UPDATE:
We had a backup that we restored the centify programs folder and data folder and tried again… This worked
I then reviewed the updated version against the previous version and found that a setting on the old restored version was different to the updated version. Enable DNS Validation Checks was disabled prior to upgrade but enabled after todays update.
Since I am the only person that has access I am certain that this was not manually changed. would like others who perform manual validation to comment if they experienced this.

Kind regards


#31

Hi @TechnicaOne It was just the UI that was stuck updating, if you’d closed it and re-opened it would have been fine. Certify is split into a UI and Background Service and it’s possible for updates from the background service to timeout for long running operations. This uses a combination of local http API and SignalR listener (for event streaming back to the UI), perhaps there’s a bug there.

Thanks for raising the issue regarding ‘Enabled DNS Validation Checks’, let me know if unchecking that and Saving fails to stick properly. Our default is 'false; for that property.