Add option to disable "already validated" feature #206

Closed
opened 2025-12-29 01:18:54 +01:00 by adam · 10 comments
Owner

Originally created by @nh2 on GitHub (Mar 22, 2017).

Release 0.4.0 adds the Skip challenges for already validated domains feature.

While the feature makes sense, this makes it difficult to test hooks.

Please add an option to disable this feature (or make skipping it part of --force).

Originally created by @nh2 on GitHub (Mar 22, 2017). Release 0.4.0 adds the `Skip challenges for already validated domains` feature. While the feature makes sense, this makes it difficult to test hooks. Please add an option to disable this feature (or make skipping it part of `--force`).
adam closed this issue 2025-12-29 01:18:54 +01:00
Author
Owner

@txr13 commented on GitHub (Mar 22, 2017):

@nh2 Does this happen in staging as well?

@txr13 commented on GitHub (Mar 22, 2017): @nh2 Does this happen in staging as well?
Author
Owner

@nh2 commented on GitHub (Mar 23, 2017):

Does this happen in staging as well?

Yes it says:

 + Requesting challenge for mydomain.com...
 + Already validated!
@nh2 commented on GitHub (Mar 23, 2017): > Does this happen in staging as well? Yes it says: ``` + Requesting challenge for mydomain.com... + Already validated! ```
Author
Owner

@lukas2511 commented on GitHub (Jul 10, 2017):

Mh, sorry, but if you need to test a hook just call it manually with the corresponding parameters or use different subdomains to force validation.

@lukas2511 commented on GitHub (Jul 10, 2017): Mh, sorry, but if you need to test a hook just call it manually with the corresponding parameters or use different subdomains to force validation.
Author
Owner

@w194 commented on GitHub (Aug 1, 2017):

How to work around this? Need to force this tool really quick as my certificates expire. Trying to work around this issue for two days now..

@w194 commented on GitHub (Aug 1, 2017): How to work around this? Need to force this tool really quick as my certificates expire. Trying to work around this issue for two days now..
Author
Owner

@w194 commented on GitHub (Aug 1, 2017):

Here is solution
rm -rf /etc/dehydrated/accounts/*
rm -rf /etc/dehydrated/certs/*

@w194 commented on GitHub (Aug 1, 2017): Here is solution rm -rf /etc/dehydrated/accounts/* rm -rf /etc/dehydrated/certs/*
Author
Owner

@txr13 commented on GitHub (Aug 1, 2017):

@widder What is the issue you're experiencing? The "already validated" response will not block the renewal of certificates.

And I think it a very bad "solution" to register a brand-new account with the CA every time you want a new certificate...

@txr13 commented on GitHub (Aug 1, 2017): @widder What is the issue you're experiencing? The "already validated" response will not block the renewal of certificates. And I think it a very bad "solution" to register a brand-new account with the CA every time you want a new certificate...
Author
Owner

@pinkgothic commented on GitHub (Oct 28, 2017):

@txr13 I'm not widder, but I might be able to provide some insight into a comparable situation. The problem I've got is trying to get a validation hook to work properly.

The "Already validated!" feature (as excellent and useful as it is in normal situations!) is interfering with repeated testing of the hook against LE's staging network. I can test the hook on its own, but one of the problems it's wrought with is actually its integration with dehydrated - occasionally it will complain it's not being called with the right arguments.

So, basically, I'd like a way to skip validation-caching, too, to try and force more deterministic behaviour out of this hook I'm trying to run. That said, I'm going to see if I can take care of this with a sloppy hack on my end (or less sloppy if I get lucky), so there's hopefully no urgency - but I wanted to explain a possible usecase in this ticket.

tl;dr: Flag would be useful for hook<->dehydrated integration testing against LE's staging network.

@pinkgothic commented on GitHub (Oct 28, 2017): @txr13 I'm not widder, but I might be able to provide some insight into a comparable situation. The problem I've got is trying to get a validation hook to work properly. The "Already validated!" feature (as excellent and useful as it is in normal situations!) is interfering with repeated testing of the hook against LE's staging network. I can test the hook on its own, but one of the problems it's wrought with is actually its integration with dehydrated - occasionally it will complain it's not being called with the right arguments. So, basically, I'd like a way to skip validation-caching, too, to try and force more deterministic behaviour out of this hook I'm trying to run. That said, I'm going to see if I can take care of this with a sloppy hack on my end (or less sloppy if I get lucky), so there's hopefully no urgency - but I wanted to explain a possible usecase in this ticket. tl;dr: Flag would be useful for hook<->dehydrated integration testing against LE's staging network.
Author
Owner

@w194 commented on GitHub (Nov 6, 2017):

What @pinkgothic says is correct.
I'm not using dehydrated any more because of its inability to use it with staging.

@w194 commented on GitHub (Nov 6, 2017): What @pinkgothic says is correct. I'm not using dehydrated any more because of its inability to use it with staging.
Author
Owner

@txr13 commented on GitHub (Nov 7, 2017):

@lukas2511 There does seem to be a solid use case for wanting to skip the validation caching. Rather than adding a new flag, what about the suggestion of making --force also request a new validation?

@txr13 commented on GitHub (Nov 7, 2017): @lukas2511 There does seem to be a solid use case for wanting to skip the validation caching. Rather than adding a new flag, what about the suggestion of making --force also request a new validation?
Author
Owner

@lukas2511 commented on GitHub (Nov 7, 2017):

See referenced commit, this should allow you to do what you are trying to do. Thanks @txr13 for the suggestion.

@lukas2511 commented on GitHub (Nov 7, 2017): See referenced commit, this should allow you to do what you are trying to do. Thanks @txr13 for the suggestion.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#206