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`).
+ 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!
```
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.
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..
@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...
@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.
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.
@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?
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @nh2 on GitHub (Mar 22, 2017).
Release 0.4.0 adds the
Skip challenges for already validated domainsfeature.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).@txr13 commented on GitHub (Mar 22, 2017):
@nh2 Does this happen in staging as well?
@nh2 commented on GitHub (Mar 23, 2017):
Yes it says:
@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.
@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):
Here is solution
rm -rf /etc/dehydrated/accounts/*
rm -rf /etc/dehydrated/certs/*
@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...
@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.
@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.
@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?
@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.