Re: 2.4.x STATUS needs you!

[Jordan Gigov]

On 12 December 2017 at 11:32, Stefan Eissing 
wrote:

> Fellow Apache developers: if we want to make an X-mas 2.4 release for the
> people on this planet, the backports in STATUS need your attention:
>
> B2: mod_remoteip: Add PROXY protocol support
>   - needs 1 more vote!
>
> I find that trying to have both Proxy Protocol and the old remoteip
functionality in the same mod is harder to maintain. I propose that they be
split up before an official release.

I have not kept-up with the changes over the past few months on the matter,
but I do still have a patch for 2.4.29 that adds HTTPS-identifying headers
to the original mod_remoteip, that also affect the choice of VirtualHost.

Re: 2.4.x STATUS needs you!

[William A Rowe Jr]

On Tue, Dec 12, 2017 at 3:32 AM, Stefan Eissing
 wrote:
> Fellow Apache developers: if we want to make an X-mas 2.4 release for the
> people on this planet, the backports in STATUS need your attention:
>
> B2: mod_remoteip: Add PROXY protocol support
>   - needs 1 more vote!

The caveat to this one, which none of us have found time to work on,
is that we agreed we wanted an affirmative whitelist of the subnets
which are submitting requests under the PROXY protocol, before
we consider the blacklist of plain requests. Not sure whether or not
we want to advance it before resolving that missing feature, which
is why I haven't registered any vote one way or another.

Re: mod_md 1.1.0 repeating on error

[Steffen]

Help !
Your reaction makes me very sad that you accuse me. 

Other dev’s are slilence about mod_md, as you said before: they are shoulder 
clapping etc. And you said: You got to be kiddding me! Afterwords maybe better 
that I was also more silent. But on the other-hand we did not discovered all 
the errors and improvements. 

Marketing wise is that the first release not raises too much questions and have 
dev’s for support.  So other dev’s please go testing it. 

 I am very serious in the mail and I do not see any personal offense. Only the 
sentence with  bikeshedding can maybe trigger, but that sentence I begin with 
“Looks”, so you can answer there normal. Please let me know where more you feel 
offense, maybe better off -list. 

You ask what I want here: I want the best possible module. As I said I want 
quality and a good function set for our users. Looks you have an other goal at 
the moment and emotional. Looks you want to stall issues to get it quick in 
httpd (this is no offense), fine but say it, then can I shut my mouth on the 
list etc. and wait till the experimental module is released. 

Your advise is that I stop testing/ helping ? Please answer this question. 
If yes, then I have to  remove the test mod_md download from Apache Lounge and 
cannot give anymore support  there to the users I represent. Do not under 
estimate the many users that are testing via me, not only windows. 

Last question on this list about mod_md:
What  is your opinion about the MDNotifyCMD on error. 

Still some design decisions are not clear to me. 

Cheers and drying my tears from your mail. 

Sorry that I triggered you in some way. 

Steffen


> Op 12 dec. 2017 om 18:07 heeft Stefan Eissing  
> het volgende geschreven:
> 
> There is so much personal offence and mal-attribution in this mail, I am not 
> sure where you get that from. I ask you to take a deep breath and consider 
> what you want here. Just because I do what I feel is right does not make me 
> your enemy. Give me a break.
> 
> -Stefan
> 
> 
 Am 12.12.2017 um 16:19 schrieb Steffen :
>>> 
>>> - No, I will not change the endless retry behaviour.
>> 
>> I still not see the reason for retries on all the errors, I am not aware of 
>> other modules doing it this way.
>> 
>> But Ok, when mdnotifycmd on error is added (see other post feature request). 
>> Then I  vote a  SUPER +1  for an experimental release.
>> 
>> User are going to be happy with mdnotifycmd on error, had already requests. 
>> Now it only triggered when it is OK, which is not logical.
>> 
>> See for a mdnotifycmd script see : 
>> https://www.apachelounge.com/viewtopic.php?p=36054#36054 
>> 
>> 
>>> - Yes, I expect people to check their server logs, somehow. Either manual 
>>> or with some tools.
>>>   There is more than mod_md that can have trouble and every module 
>>> implementing its own
>>>   solution is not a good service for users.
>> 
>> Be aware that most users only check there logs when there is an issue. Agree 
>> a standard for every module (the retry is not standard behavior), but mod_md 
>> log  messages must be more clear to see what is going on, see also next 
>> point.
>>> - Yes, I think some log levels need adjustment, e.g. when LE cannot be 
>>> reached at all.
>> 
>> Let me know which one you pick. We had mentions on GIT about this.
>>> - Yes, I think there should be a high level NOTICE log entry when a 
>>> certificate could not
>>>   be renewed and the existing one only last a couple of days.
>> 
>> Agree, plus a mdnotifycmd should be nice.
>> 
>>> All that said: I do not want to make more changes to mod_md before a 
>>> release. If we find a
>>> serious error, sure. But otherwise I'd rather enhance the documentation for 
>>> now.
>> 
>> Looks here you are bikeshedding my reports/requests (again). What is 
>> serious, an introduction with too much user questions is not good. Consider 
>> me as a user in this case. 
>> 
>> I spend tons of hours in testing mod_md (I am not paid).   My only goal was 
>> to get quality and a usable function set  for our users, and not to 
>> frustrate you. Looks you are only interested now to get it in httpd as 
>> quickly as possible, I can only guess the reason for your pressing.
>> 
>>> If you want to add some Windows specific advice to the mod_md XML, please 
>>> do so.
>> 
>> At the moment no advice. On Apache Lounge users can follow the dev at 
>> http://www.apachelounge.com/viewtopic.php?t=7786 
>> 
>> 
>> PS.
>> For windows there is still testing and work (like cmake) to be done. I did 
>> not tested completely the .dsp/mak etc.  I see in trunk there are still 
>> changes on the way, so when voting starts for 2.4.30 then I shall test all 
>> again.
>> 
>> 
>> Regards,
>> 
>> Steffen
>> 
>> 
>>> On Tuesday 12/12/2017 at 14:49, Stefan Eissing wrote:
>>> 
>>> 
 Am 

Re: mod_md 1.1.0 repeating on error

[Stefan Eissing]

There is so much personal offence and mal-attribution in this mail, I am not 
sure where you get that from. I ask you to take a deep breath and consider what 
you want here. Just because I do what I feel is right does not make me your 
enemy. Give me a break.

-Stefan


> Am 12.12.2017 um 16:19 schrieb Steffen :
> 
>> - No, I will not change the endless retry behaviour.
> 
> I still not see the reason for retries on all the errors, I am not aware of 
> other modules doing it this way.
> 
> But Ok, when mdnotifycmd on error is added (see other post feature request). 
> Then I  vote a  SUPER +1  for an experimental release.
> 
> User are going to be happy with mdnotifycmd on error, had already requests. 
> Now it only triggered when it is OK, which is not logical.
> 
> See for a mdnotifycmd script see : 
> https://www.apachelounge.com/viewtopic.php?p=36054#36054 
> 
> 
>> - Yes, I expect people to check their server logs, somehow. Either manual or 
>> with some tools.
>>There is more than mod_md that can have trouble and every module 
>> implementing its own
>>solution is not a good service for users.
> 
> Be aware that most users only check there logs when there is an issue. Agree 
> a standard for every module (the retry is not standard behavior), but mod_md 
> log  messages must be more clear to see what is going on, see also next point.
>> - Yes, I think some log levels need adjustment, e.g. when LE cannot be 
>> reached at all.
> 
> Let me know which one you pick. We had mentions on GIT about this.
>> - Yes, I think there should be a high level NOTICE log entry when a 
>> certificate could not
>>be renewed and the existing one only last a couple of days.
> 
> Agree, plus a mdnotifycmd should be nice.
> 
>> All that said: I do not want to make more changes to mod_md before a 
>> release. If we find a
>> serious error, sure. But otherwise I'd rather enhance the documentation for 
>> now.
> 
> Looks here you are bikeshedding my reports/requests (again). What is serious, 
> an introduction with too much user questions is not good. Consider me as a 
> user in this case. 
> 
> I spend tons of hours in testing mod_md (I am not paid).   My only goal was 
> to get quality and a usable function set  for our users, and not to frustrate 
> you. Looks you are only interested now to get it in httpd as quickly as 
> possible, I can only guess the reason for your pressing.
> 
>> If you want to add some Windows specific advice to the mod_md XML, please do 
>> so.
> 
> At the moment no advice. On Apache Lounge users can follow the dev at 
> http://www.apachelounge.com/viewtopic.php?t=7786 
> 
> 
> PS.
> For windows there is still testing and work (like cmake) to be done. I did 
> not tested completely the .dsp/mak etc.  I see in trunk there are still 
> changes on the way, so when voting starts for 2.4.30 then I shall test all 
> again.
> 
> 
> Regards,
> 
> Steffen
>  
> 
> On Tuesday 12/12/2017 at 14:49, Stefan Eissing wrote:
>> 
>> 
>>> Am 12.12.2017 um 14:37 schrieb Steffen >> >:
>>> 
>>> The curl error was just to show you the debug log entries which you asked.
>>> 
>>> This curl error we discussed by mail already in the very beginning (mod_md 
>>> does not work with curl openssl on Windows).
>>> 
>>> 1.1.0 is working fine so far.
>>> 
>>> I am only testing rare cases (you asked to test).
>> 
>> I see. I did not understand you before. I suspected you had a real error 
>> with v1.1.0.
>> 
>> As to your design proposals:
>> - No, I will not change the endless retry behaviour.
>> - Yes, I expect people to check their server logs, somehow. Either manual or 
>> with some tools.
>>There is more than mod_md that can have trouble and every module 
>> implementing its own
>>solution is not a good service for users.
>> - Yes, I think some log levels need adjustment, e.g. when LE cannot be 
>> reached at all.
>> - Yes, I think there should be a high level NOTICE log entry when a 
>> certificate could not
>>be renewed and the existing one only last a couple of days.
>> 
>> All that said: I do not want to make more changes to mod_md before a 
>> release. If we find a
>> serious error, sure. But otherwise I'd rather enhance the documentation for 
>> now.
>> 
>> If you want to add some Windows specific advice to the mod_md XML, please do 
>> so.
>> 
>> Cheers,
>> 
>> Stefan
>> 
> 
> 

Re: mod_md 1.1.0 repeating on error

[Steffen]

- No, I will not change the endless retry behaviour.
I still not see the reason for retries on all the errors, I am not 
aware of other modules doing it this way.



But Ok, when mdnotifycmd on error is added (see other post feature 
request). Then I  vote a  SUPER +1  for an experimental release.



User are going to be happy with mdnotifycmd on error, had already 
requests. Now it only triggered when it is OK, which is not logical.



See for a mdnotifycmd script see : 
https://www.apachelounge.com/viewtopic.php?p=36054#36054




- Yes, I expect people to check their server logs, somehow. Either 
manual or with some tools.
  There is more than mod_md that can have trouble and every module 
implementing its own

  solution is not a good service for users.
Be aware that most users only check there logs when there is an issue. 
Agree a standard for every module (the retry is not standard 
behavior), but mod_md log  messages must be more clear to see what is 
going on, see also next point.


- Yes, I think some log levels need adjustment, e.g. when LE cannot be 
reached at all.

Let me know which one you pick. We had mentions on GIT about this.


- Yes, I think there should be a high level NOTICE log entry when a 
certificate could not

  be renewed and the existing one only last a couple of days.


Agree, plus a mdnotifycmd should be nice.



All that said: I do not want to make more changes to mod_md before a 
release. If we find a
serious error, sure. But otherwise I'd rather enhance the 
documentation for now.
Looks here you are bikeshedding my reports/requests (again). What is 
serious, an introduction with too much user questions is not good. 
Consider me as a user in this case.



I spend tons of hours in testing mod_md (I am not paid).   My only 
goal was to get quality and a usable function set  for our users, and 
not to frustrate you. Looks you are only interested now to get it in 
httpd as quickly as possible, I can only guess the reason for your 
pressing.




If you want to add some Windows specific advice to the mod_md XML, 
please do so.
At the moment no advice. On Apache Lounge users can follow the dev at 
http://www.apachelounge.com/viewtopic.php?t=7786


PS.
For windows there is still testing and work (like cmake) to be done. I 
did not tested completely the .dsp/mak etc.  I see in trunk there are 
still changes on the way, so when voting starts for 2.4.30 then I 
shall test all again.



Regards,

Steffen



On Tuesday 12/12/2017 at 14:49, Stefan Eissing  wrote:





Am 12.12.2017 um 14:37 schrieb Steffen :

The curl error was just to show you the debug log entries which you 
asked.


This curl error we discussed by mail  already in the very beginning 
(mod_md does not work with curl openssl on Windows).


1.1.0 is working  fine so far.

I am only testing rare cases  (you asked to test).


I see. I did not understand you before. I suspected you had a real 
error with v1.1.0.


As to your design proposals:
- No, I will not change the endless retry behaviour.
- Yes, I expect people to check their server logs, somehow. Either 
manual or with some tools.
   There is more than mod_md that can have trouble and every module 
implementing its own

   solution is not a good service for users.
- Yes, I think some log levels need adjustment, e.g. when LE cannot be 
reached at all.
- Yes, I think there should be a high level NOTICE log entry when a 
certificate could not

   be renewed and the existing one only last a couple of days.

All that said: I do not want to make more changes to mod_md before a 
release. If we find a
serious error, sure. But otherwise I'd rather enhance the 
documentation for now.


If you want to add some Windows specific advice to the mod_md XML, 
please do so.


Cheers,

Stefan

MDNotifyCmd on Error :: feature request

[Steffen]

On errors with sigining up and renewing there are only log entries, 
and mod-md is retrying in a loop.



Now the MDNotifyCmd is only triggered when it is ok, seems logical 
also notify when there is some wrong.


Request :
Use MDNotifyCmd for the first error AH10057 and it should be nice with 
the description of  the error (AH10056 and (20014)Internal error )



So the users can be notified by mail or whatever action they want from 
the script.



Current docu MDNotifyCmd : 
https://httpd.apache.org/docs/trunk/mod/mod_md.html#mdnotifycmd


Steffen

Re: mod_md 1.1.0 repeating on error

[Stefan Eissing]

> Am 12.12.2017 um 14:37 schrieb Steffen :
> 
> The curl error was just to show you the debug log entries which you asked.
> 
> This curl error we discussed by mail  already in the very beginning (mod_md 
> does not work with curl openssl on Windows).
> 
> 1.1.0 is working  fine so far.
> 
> I am only testing rare cases  (you asked to test).

I see. I did not understand you before. I suspected you had a real error with 
v1.1.0.

As to your design proposals:
- No, I will not change the endless retry behaviour.
- Yes, I expect people to check their server logs, somehow. Either manual or 
with some tools.
  There is more than mod_md that can have trouble and every module implementing 
its own
  solution is not a good service for users.
- Yes, I think some log levels need adjustment, e.g. when LE cannot be reached 
at all.
- Yes, I think there should be a high level NOTICE log entry when a certificate 
could not
  be renewed and the existing one only last a couple of days.

All that said: I do not want to make more changes to mod_md before a release. 
If we find a
serious error, sure. But otherwise I'd rather enhance the documentation for now.

If you want to add some Windows specific advice to the mod_md XML, please do so.

Cheers,

Stefan

> Steffen
>  
> On Tuesday 12/12/2017 at 14:21, Stefan Eissing wrote:
>> *without* introducing new ones, I meant. Please provide a log.
>> 
>>> Am 12.12.2017 um 14:21 schrieb Stefan Eissing 
>>> :
>>> 
>>> 
>>> 
 Am 12.12.2017 um 14:17 schrieb Steffen :
 
 To be clear : As I said the curl error I have introduced (by my self), so 
 I know exactly what is wrong.
>>> 
>>> Ah, that was not clear to me.
>>> 
>>> So, what is the error happening with you introducing new ones? Is there 
>>> nothing to see in the logs or did I miss it?
>>> 
 Your reply shows me that you want to keep the endless retry loop. I the 
 worst case a user can end with a non working SSL because a certificate is 
 not renewed.
 
 Why is it retried again and again ? Looks all hard errors, except when LE 
 is temporary down.
 
 I think it should be fixed. No every one is constantly look at the 
 error.log.
 
 
 What I like:
 
 Use MDNotifyCmd for the first error AH10057 . 
 Now the MDNotifyCmd is only triggered when it is ok, seems logical to also 
 notify when there is some wrong.
 
 
 On Tuesday 12/12/2017 at 13:58, Stefan Eissing wrote: 
> 
> 
>> Am 12.12.2017 um 13:47 schrieb Steffen :
>> 
>> It was happening before 1.1.0, but i did not give it attention, seen it 
>> in several situations which all I unfortunate cannot recall (see the 
>> retries as example https://github.com/icing/mod_md/issues/52and 
>> https://github.com/icing/mod_md/issues/62 ).
>> 
>> It is a more serious issue then I thought before. 
>> 
>> I think we must first fix this, otherwise it is a bad introduction to 
>> our users. This because Windows community first-time users learned that 
>> they are dealing with it and are dealing with all kind of (try) errors, 
>> most users stopped using it. As said in an other post mod_md is not that 
>> easy to start with.
>> 
>> Also when the loglevel is on the default Warn, users see hardly what is 
>> happening. I advise our users to use LogLevel info md:trace2 ssl:notice
>> 
>> The Endless Retry loop Tested now in the following situations, tested 
>> during renew and no new certificate is generated, httpd running fine 
>> with the old certificate which was still valid.
>> 
>> 1 - Mis-configuration like below.
>> 2 - ACME CA service down (cause Letsencrypt down)
>> 3 - ACME CA service not reachable (cause local network, or OS 
>> failure/misconfig)
>> 4 - Error response (Get/Post errors)when accessing Letsencrypt, 
>> dependency issue like curl, mod_ssl.
>> 5 - mod_md/mod_ssl faults
>> 6 - Should be more
>> 
>> 
>> 2) 3) Both can be that Letsencrypt is temp down maybe retry there, but 
>> hard to tell if the cause is temp LE-Down, issue local or OS misconfig.
>> 
>> 4) Is a good example: Error response from LE, which happens quite some 
>> situations, Curl issues, Rate-Limits, mod_md faults etc.
>> 
>> Below I introduced a Curl issue:
>> 
>> ...
>> [md:debug] [pid 7508:tid 1052] mod_md.c(762): AH10055: md watchdog run, 
>> auto drive 2 mds
>> [md:debug] [pid 7508:tid 1052] mod_md.c(691): AH10052: 
>> md(apachelounge.nl): state=2, driving
>> [md:debug] [pid 7508:tid 1052] md_reg.c(884): apachelounge.nl: run 
>> staging
>> [md:debug] [pid 7508:tid 1052] md_acme_drive.c(690): apachelounge.nl: 
>> staging started, state=2, can_http=0, can_https=1, 
>> challenges='tls-sni-01'
>> [md:debug] [pid 

Re: mod_md 1.1.0 repeating on error

[Steffen]

The curl error was just to show you the debug log entries which you 
asked.


This curl error we discussed by mail  already in the very beginning 
(mod_md does not work with curl openssl on Windows).


1.1.0 is working  fine so far.

I am only testing rare cases  (you asked to test).

Steffen


On Tuesday 12/12/2017 at 14:21, Stefan Eissing  wrote:

*without* introducing new ones, I meant. Please provide a log.



Am 12.12.2017 um 14:21 schrieb Stefan Eissing 
:






Am 12.12.2017 um 14:17 schrieb Steffen :

To be clear :  As I said the curl error I have introduced (by my 
self), so I know exactly what is wrong.


Ah, that was not clear to me.

So, what is the error happening with you introducing new ones? Is 
there nothing to see in the logs or did I miss it?




Your reply shows me that you want to keep the endless retry loop. I 
the worst case a user can end with a non working SSL because a 
certificate is not renewed.


Why is it retried again and again ?  Looks all hard errors, except 
when LE is temporary down.


I think it should be fixed. No every one is constantly look at the 
error.log.



What I like:

Use MDNotifyCmd for the first error AH10057 .
Now the MDNotifyCmd is only triggered when it is ok, seems logical to 
also notify when there is some wrong.



On Tuesday 12/12/2017 at 13:58, Stefan Eissing wrote:






Am 12.12.2017 um 13:47 schrieb Steffen :

It was happening before 1.1.0, but i did not give it attention, seen 
it in several situations which all I unfortunate cannot recall (see 
the retries as example https://github.com/icing/mod_md/issues/52and 
https://github.com/icing/mod_md/issues/62 ).


It is a more serious issue then I thought before.

I think we must first fix this, otherwise it is a bad introduction to 
our users. This because Windows community first-time users learned 
that they are dealing with it and are dealing with all kind of (try) 
errors, most users stopped using it. As said in an other post mod_md 
is not that easy to start with.


Also when the loglevel is on the default Warn, users see hardly what 
is happening. I advise our users to use LogLevel info md:trace2 
ssl:notice


The Endless Retry loop Tested now in the following situations, tested 
during renew and no new certificate is generated, httpd running fine 
with the old certificate which was still valid.


1 - Mis-configuration like below.
2 - ACME CA service down (cause Letsencrypt down)
3 - ACME CA service not reachable (cause local network, or OS 
failure/misconfig)
4 - Error response (Get/Post errors)when accessing Letsencrypt, 
dependency issue like curl, mod_ssl.

5 - mod_md/mod_ssl faults
6 - Should be more


2) 3) Both can be that Letsencrypt is temp down maybe retry there, but 
hard to tell if the cause is temp LE-Down, issue local or OS 
misconfig.


4) Is a good example: Error response from LE, which happens quite some 
situations, Curl issues, Rate-Limits, mod_md faults etc.


Below I introduced a Curl issue:

...
[md:debug] [pid 7508:tid 1052] mod_md.c(762): AH10055: md watchdog 
run, auto drive 2 mds
[md:debug] [pid 7508:tid 1052] mod_md.c(691): AH10052: 
md(apachelounge.nl): state=2, driving
[md:debug] [pid 7508:tid 1052] md_reg.c(884): apachelounge.nl: run 
staging
[md:debug] [pid 7508:tid 1052] md_acme_drive.c(690): apachelounge.nl: 
staging started, state=2, can_http=0, can_https=1, 
challenges='tls-sni-01'
[md:debug] [pid 7508:tid 1052] md_store_fs.c(690): purge 
staging/apachelounge.nl 
(D:/servers/apacheS/md/staging/apachelounge.nl)
[md:debug] [pid 7508:tid 1052] md_acme.c(144): get directory from 
https://acme-v01.api.letsencrypt.org/directory
[md:debug] [pid 7508:tid 1052] md_acme.c(407): req: POST 
https://acme-v01.api.letsencrypt.org/directory
[md:debug] [pid 7508:tid 1052] md_curl.c(258): (20014)Internal error 
(specific information not available): request 10 failed(60): Peer 
certificate cannot be authenticated with given CA certificates


Ok, this needs to be logged at ERROR level, so users do not have to 
mess with LogLevel to see what is going on.


As for the reason, this seems to indicate that the curl client finds 
no way to verify the Let's Encrypt server certificate. Can you verify 
that the "curl.exe" can connect to 
"https://acme-v01.api.letsencrypt.org/directory; and retrieve the JSON 
there *without* you giving it the '-k' or '--insecure' option? And 
where does your curl.exe/libcurl come from? Did you build it yourself?




[md:debug] [pid 7508:tid 1052] md_acme.c(425): (20014)Internal error 
(specific information not available): req sent
[md:error] [pid 7508:tid 1052] (20014)Internal error (specific 
information not available): apachelounge.nl: setup 
ACME(https://acme-v01.api.letsencrypt.org/directory)
[md:debug] [pid 7508:tid 1052] md_acme_drive.c(912): (20014)Internal 
error (specific information not available): apachelounge.nl: ACME, 
ACME staging
[md:debug] [pid 7508:tid 1052] 

Re: mod_md 1.1.0 repeating on error

[Stefan Eissing]

*without* introducing new ones, I meant. Please provide a log.

> Am 12.12.2017 um 14:21 schrieb Stefan Eissing :
> 
> 
> 
>> Am 12.12.2017 um 14:17 schrieb Steffen :
>> 
>> To be clear :  As I said the curl error I have introduced (by my self), so I 
>> know exactly what is wrong.
> 
> Ah, that was not clear to me.
> 
> So, what is the error happening with you introducing new ones? Is there 
> nothing to see in the logs or did I miss it?
> 
>> Your reply shows me that you want to keep the endless retry loop. I the 
>> worst case a user can end with a non working SSL because a certificate is 
>> not renewed.
>> 
>> Why is it retried again and again ?  Looks all hard errors, except when LE 
>> is temporary down.
>> 
>> I think it should be fixed. No every one is constantly look at the error.log.
>> 
>> 
>> What I like:
>> 
>> Use MDNotifyCmd for the first error AH10057 . 
>> Now the MDNotifyCmd is only triggered when it is ok, seems logical to also 
>> notify when there is some wrong.
>> 
>> 
>> On Tuesday 12/12/2017 at 13:58, Stefan Eissing wrote: 
>>> 
>>> 
 Am 12.12.2017 um 13:47 schrieb Steffen :
 
 It was happening before 1.1.0, but i did not give it attention, seen it in 
 several situations which all I unfortunate cannot recall (see the retries 
 as example https://github.com/icing/mod_md/issues/52and 
 https://github.com/icing/mod_md/issues/62 ).
 
 It is a more serious issue then I thought before. 
 
 I think we must first fix this, otherwise it is a bad introduction to our 
 users. This because Windows community first-time users learned that they 
 are dealing with it and are dealing with all kind of (try) errors, most 
 users stopped using it. As said in an other post mod_md is not that easy 
 to start with.
 
 Also when the loglevel is on the default Warn, users see hardly what is 
 happening. I advise our users to use LogLevel info md:trace2 ssl:notice
 
 The Endless Retry loop Tested now in the following situations, tested 
 during renew and no new certificate is generated, httpd running fine with 
 the old certificate which was still valid.
 
 1 - Mis-configuration like below.
 2 - ACME CA service down (cause Letsencrypt down)
 3 - ACME CA service not reachable (cause local network, or OS 
 failure/misconfig)
 4 - Error response (Get/Post errors)when accessing Letsencrypt, dependency 
 issue like curl, mod_ssl.
 5 - mod_md/mod_ssl faults
 6 - Should be more
 
 
 2) 3) Both can be that Letsencrypt is temp down maybe retry there, but 
 hard to tell if the cause is temp LE-Down, issue local or OS misconfig.
 
 4) Is a good example: Error response from LE, which happens quite some 
 situations, Curl issues, Rate-Limits, mod_md faults etc.
 
 Below I introduced a Curl issue:
 
 ...
 [md:debug] [pid 7508:tid 1052] mod_md.c(762): AH10055: md watchdog run, 
 auto drive 2 mds
 [md:debug] [pid 7508:tid 1052] mod_md.c(691): AH10052: 
 md(apachelounge.nl): state=2, driving
 [md:debug] [pid 7508:tid 1052] md_reg.c(884): apachelounge.nl: run staging
 [md:debug] [pid 7508:tid 1052] md_acme_drive.c(690): apachelounge.nl: 
 staging started, state=2, can_http=0, can_https=1, challenges='tls-sni-01'
 [md:debug] [pid 7508:tid 1052] md_store_fs.c(690): purge 
 staging/apachelounge.nl (D:/servers/apacheS/md/staging/apachelounge.nl)
 [md:debug] [pid 7508:tid 1052] md_acme.c(144): get directory from 
 https://acme-v01.api.letsencrypt.org/directory
 [md:debug] [pid 7508:tid 1052] md_acme.c(407): req: POST 
 https://acme-v01.api.letsencrypt.org/directory
 [md:debug] [pid 7508:tid 1052] md_curl.c(258): (20014)Internal error 
 (specific information not available): request 10 failed(60): Peer 
 certificate cannot be authenticated with given CA certificates
>>> 
>>> Ok, this needs to be logged at ERROR level, so users do not have to mess 
>>> with LogLevel to see what is going on.
>>> 
>>> As for the reason, this seems to indicate that the curl client finds no way 
>>> to verify the Let's Encrypt server certificate. Can you verify that the 
>>> "curl.exe" can connect to "https://acme-v01.api.letsencrypt.org/directory; 
>>> and retrieve the JSON there *without* you giving it the '-k' or 
>>> '--insecure' option? And where does your curl.exe/libcurl come from? Did 
>>> you build it yourself?
>>> 
 [md:debug] [pid 7508:tid 1052] md_acme.c(425): (20014)Internal error 
 (specific information not available): req sent
 [md:error] [pid 7508:tid 1052] (20014)Internal error (specific information 
 not available): apachelounge.nl: setup 
 ACME(https://acme-v01.api.letsencrypt.org/directory)
 [md:debug] [pid 7508:tid 1052] md_acme_drive.c(912): (20014)Internal error 
 (specific information not available): 

Re: mod_md 1.1.0 repeating on error

[Stefan Eissing]

> Am 12.12.2017 um 14:17 schrieb Steffen :
> 
> To be clear :  As I said the curl error I have introduced (by my self), so I 
> know exactly what is wrong.

Ah, that was not clear to me.

So, what is the error happening with you introducing new ones? Is there nothing 
to see in the logs or did I miss it?
 
> Your reply shows me that you want to keep the endless retry loop. I the worst 
> case a user can end with a non working SSL because a certificate is not 
> renewed.
> 
> Why is it retried again and again ?  Looks all hard errors, except when LE is 
> temporary down.
> 
> I think it should be fixed. No every one is constantly look at the error.log.
> 
> 
> What I like:
> 
> Use MDNotifyCmd for the first error AH10057 . 
> Now the MDNotifyCmd is only triggered when it is ok, seems logical to also 
> notify when there is some wrong.
> 
>  
> On Tuesday 12/12/2017 at 13:58, Stefan Eissing wrote: 
>> 
>> 
>>> Am 12.12.2017 um 13:47 schrieb Steffen :
>>> 
>>> It was happening before 1.1.0, but i did not give it attention, seen it in 
>>> several situations which all I unfortunate cannot recall (see the retries 
>>> as example https://github.com/icing/mod_md/issues/52and 
>>> https://github.com/icing/mod_md/issues/62 ).
>>> 
>>> It is a more serious issue then I thought before. 
>>> 
>>> I think we must first fix this, otherwise it is a bad introduction to our 
>>> users. This because Windows community first-time users learned that they 
>>> are dealing with it and are dealing with all kind of (try) errors, most 
>>> users stopped using it. As said in an other post mod_md is not that easy to 
>>> start with.
>>> 
>>> Also when the loglevel is on the default Warn, users see hardly what is 
>>> happening. I advise our users to use LogLevel info md:trace2 ssl:notice
>>> 
>>> The Endless Retry loop Tested now in the following situations, tested 
>>> during renew and no new certificate is generated, httpd running fine with 
>>> the old certificate which was still valid.
>>> 
>>> 1 - Mis-configuration like below.
>>> 2 - ACME CA service down (cause Letsencrypt down)
>>> 3 - ACME CA service not reachable (cause local network, or OS 
>>> failure/misconfig)
>>> 4 - Error response (Get/Post errors)when accessing Letsencrypt, dependency 
>>> issue like curl, mod_ssl.
>>> 5 - mod_md/mod_ssl faults
>>> 6 - Should be more
>>> 
>>> 
>>> 2) 3) Both can be that Letsencrypt is temp down maybe retry there, but hard 
>>> to tell if the cause is temp LE-Down, issue local or OS misconfig.
>>> 
>>> 4) Is a good example: Error response from LE, which happens quite some 
>>> situations, Curl issues, Rate-Limits, mod_md faults etc.
>>> 
>>> Below I introduced a Curl issue:
>>> 
>>> ...
>>> [md:debug] [pid 7508:tid 1052] mod_md.c(762): AH10055: md watchdog run, 
>>> auto drive 2 mds
>>> [md:debug] [pid 7508:tid 1052] mod_md.c(691): AH10052: md(apachelounge.nl): 
>>> state=2, driving
>>> [md:debug] [pid 7508:tid 1052] md_reg.c(884): apachelounge.nl: run staging
>>> [md:debug] [pid 7508:tid 1052] md_acme_drive.c(690): apachelounge.nl: 
>>> staging started, state=2, can_http=0, can_https=1, challenges='tls-sni-01'
>>> [md:debug] [pid 7508:tid 1052] md_store_fs.c(690): purge 
>>> staging/apachelounge.nl (D:/servers/apacheS/md/staging/apachelounge.nl)
>>> [md:debug] [pid 7508:tid 1052] md_acme.c(144): get directory from 
>>> https://acme-v01.api.letsencrypt.org/directory
>>> [md:debug] [pid 7508:tid 1052] md_acme.c(407): req: POST 
>>> https://acme-v01.api.letsencrypt.org/directory
>>> [md:debug] [pid 7508:tid 1052] md_curl.c(258): (20014)Internal error 
>>> (specific information not available): request 10 failed(60): Peer 
>>> certificate cannot be authenticated with given CA certificates
>> 
>> Ok, this needs to be logged at ERROR level, so users do not have to mess 
>> with LogLevel to see what is going on.
>> 
>> As for the reason, this seems to indicate that the curl client finds no way 
>> to verify the Let's Encrypt server certificate. Can you verify that the 
>> "curl.exe" can connect to "https://acme-v01.api.letsencrypt.org/directory; 
>> and retrieve the JSON there *without* you giving it the '-k' or '--insecure' 
>> option? And where does your curl.exe/libcurl come from? Did you build it 
>> yourself?
>> 
>>> [md:debug] [pid 7508:tid 1052] md_acme.c(425): (20014)Internal error 
>>> (specific information not available): req sent
>>> [md:error] [pid 7508:tid 1052] (20014)Internal error (specific information 
>>> not available): apachelounge.nl: setup 
>>> ACME(https://acme-v01.api.letsencrypt.org/directory)
>>> [md:debug] [pid 7508:tid 1052] md_acme_drive.c(912): (20014)Internal error 
>>> (specific information not available): apachelounge.nl: ACME, ACME staging
>>> [md:debug] [pid 7508:tid 1052] md_reg.c(891): (20014)Internal error 
>>> (specific information not available): apachelounge.nl: staging done
>>> [md:error] [pid 7508:tid 1052] (20014)Internal error (specific information 

Re: mod_md 1.1.0 repeating on error

[Steffen]

To be clear :  As I said the curl error I have introduced (by my 
self), so I know exactly what is wrong.


Your reply shows me that you want to keep the endless retry loop. I 
the worst case a user can end with a non working SSL because a 
certificate is not renewed.


Why is it retried again and again ?  Looks all hard errors, except 
when LE is temporary down.


I think it should be fixed. No every one is constantly look at the 
error.log.



What I like:

Use MDNotifyCmd for the first error AH10057 .
Now the MDNotifyCmd is only triggered when it is ok, seems logical to 
also notify when there is some wrong.




On Tuesday 12/12/2017 at 13:58, Stefan Eissing  wrote:





Am 12.12.2017 um 13:47 schrieb Steffen :

It was happening before 1.1.0, but i did not give it attention, seen 
it in several situations which all I unfortunate cannot recall (see 
the retries  as example https://github.com/icing/mod_md/issues/52and 
https://github.com/icing/mod_md/issues/62 ).


It is a more serious issue then I thought before.

I think we must first fix this, otherwise it is a bad introduction to 
our users. This because Windows community first-time users learned 
that they  are dealing with it and are dealing with all kind of (try) 
errors, most users stopped using it.  As said in an other post mod_md 
is not that easy to start with.


Also when the loglevel is on the default Warn, users see hardly what 
is happening. I advise our users to use  LogLevel info md:trace2 
ssl:notice


The Endless Retry loop Tested now in the following situations, tested 
during renew and no new certificate is generated, httpd running fine 
with the old certificate which was still valid.


1 - Mis-configuration like below.
2 - ACME CA service  down (cause Letsencrypt down)
3 - ACME CA service not reachable (cause local network, or OS 
failure/misconfig)
4 - Error response (Get/Post errors)when accessing Letsencrypt, 
dependency issue like curl, mod_ssl.

5 - mod_md/mod_ssl faults
6 - Should be more


2) 3) Both can be that Letsencrypt is temp down maybe retry there, but 
hard to tell if the cause is temp LE-Down, issue local or OS 
misconfig.


4) Is a good example: Error response from LE, which happens quite  
some situations, Curl issues, Rate-Limits, mod_md faults  etc.


Below I introduced a Curl issue:

...
[md:debug] [pid 7508:tid 1052] mod_md.c(762): AH10055: md watchdog 
run, auto drive 2 mds
[md:debug] [pid 7508:tid 1052] mod_md.c(691): AH10052: 
md(apachelounge.nl): state=2, driving
[md:debug] [pid 7508:tid 1052] md_reg.c(884): apachelounge.nl: run 
staging
[md:debug] [pid 7508:tid 1052] md_acme_drive.c(690): apachelounge.nl: 
staging started, state=2, can_http=0, can_https=1, 
challenges='tls-sni-01'
[md:debug] [pid 7508:tid 1052] md_store_fs.c(690): purge 
staging/apachelounge.nl 
(D:/servers/apacheS/md/staging/apachelounge.nl)
[md:debug] [pid 7508:tid 1052] md_acme.c(144): get directory from 
https://acme-v01.api.letsencrypt.org/directory
[md:debug] [pid 7508:tid 1052] md_acme.c(407): req: POST 
https://acme-v01.api.letsencrypt.org/directory
[md:debug] [pid 7508:tid 1052] md_curl.c(258): (20014)Internal error 
(specific information not available): request 10 failed(60): Peer 
certificate cannot be authenticated with given CA certificates


Ok, this needs to be logged at ERROR level, so users do not have to 
mess with LogLevel to see what is going on.


As for the reason, this seems to indicate that the curl client finds 
no way to verify the Let's Encrypt server certificate. Can you verify 
that the "curl.exe" can connect to 
"https://acme-v01.api.letsencrypt.org/directory; and retrieve the JSON 
there *without* you giving it the '-k' or '--insecure' option? And 
where does your curl.exe/libcurl come from? Did you build it yourself?




[md:debug] [pid 7508:tid 1052] md_acme.c(425): (20014)Internal error 
(specific information not available): req sent
[md:error] [pid 7508:tid 1052] (20014)Internal error (specific 
information not available): apachelounge.nl: setup 
ACME(https://acme-v01.api.letsencrypt.org/directory)
[md:debug] [pid 7508:tid 1052] md_acme_drive.c(912): (20014)Internal 
error (specific information not available): apachelounge.nl: ACME, 
ACME staging
[md:debug] [pid 7508:tid 1052] md_reg.c(891): (20014)Internal error 
(specific information not available): apachelounge.nl: staging done
[md:error] [pid 7508:tid 1052] (20014)Internal error (specific 
information not available): AH10056: processing apachelounge.nl
[md:info] [pid 7508:tid 1052] AH10057: apachelounge.nl: encountered 
error for the 6. time, next run in  0:02:40 hours

...

Maybe a little solution:  starting httpd, mod_md checks if LE is 
reachable without error.


No, I think checking external servers on every httpd restart is a good 
idea.




And a solution for the below one can be: make a check that 443 and/or 
80 is used.


Still my questions:

Does the retry stop ?


The retry does not stop, but it uses longer and 

Re: mod_md 1.1.0 repeating on error

[Stefan Eissing]

And btw. what is the Windows OS version that your server runs on?

And since you had mod_md running before, what did change in relation to
Windows and the curl you use?

> Am 12.12.2017 um 13:58 schrieb Stefan Eissing :
> 
> 
> 
>> Am 12.12.2017 um 13:47 schrieb Steffen :
>> 
>> It was happening before 1.1.0, but i did not give it attention, seen it in 
>> several situations which all I unfortunate cannot recall (see the retries  
>> as example https://github.com/icing/mod_md/issues/52and 
>> https://github.com/icing/mod_md/issues/62 ).
>> 
>> It is a more serious issue then I thought before. 
>> 
>> I think we must first fix this, otherwise it is a bad introduction to our 
>> users. This because Windows community first-time users learned that they  
>> are dealing with it and are dealing with all kind of (try) errors, most 
>> users stopped using it.  As said in an other post mod_md is not that easy to 
>> start with.
>> 
>> Also when the loglevel is on the default Warn, users see hardly what is 
>> happening. I advise our users to use LogLevel info md:trace2 ssl:notice
>> 
>> The Endless Retry loop Tested now in the following situations, tested during 
>> renew and no new certificate is generated, httpd running fine with the old 
>> certificate which was still valid.
>> 
>> 1 - Mis-configuration like below.
>> 2 - ACME CA service  down (cause Letsencrypt down)
>> 3 - ACME CA service not reachable (cause local network, or OS 
>> failure/misconfig)
>> 4 - Error response (Get/Post errors)when accessing Letsencrypt, dependency 
>> issue like curl, mod_ssl.
>> 5 - mod_md/mod_ssl faults
>> 6 - Should be more
>> 
>> 
>> 2) 3) Both can be that Letsencrypt is temp down maybe retry there, but hard 
>> to tell if the cause is temp LE-Down, issue local or OS misconfig.
>> 
>> 4) Is a good example: Error response from LE, which happens quite  some 
>> situations, Curl issues, Rate-Limits, mod_md faults  etc.
>> 
>> Below I introduced a Curl issue:
>> 
>> ...
>> [md:debug] [pid 7508:tid 1052] mod_md.c(762): AH10055: md watchdog run, auto 
>> drive 2 mds
>> [md:debug] [pid 7508:tid 1052] mod_md.c(691): AH10052: md(apachelounge.nl): 
>> state=2, driving
>> [md:debug] [pid 7508:tid 1052] md_reg.c(884): apachelounge.nl: run staging
>> [md:debug] [pid 7508:tid 1052] md_acme_drive.c(690): apachelounge.nl: 
>> staging started, state=2, can_http=0, can_https=1, challenges='tls-sni-01'
>> [md:debug] [pid 7508:tid 1052] md_store_fs.c(690): purge 
>> staging/apachelounge.nl (D:/servers/apacheS/md/staging/apachelounge.nl)
>> [md:debug] [pid 7508:tid 1052] md_acme.c(144): get directory from 
>> https://acme-v01.api.letsencrypt.org/directory
>> [md:debug] [pid 7508:tid 1052] md_acme.c(407): req: POST 
>> https://acme-v01.api.letsencrypt.org/directory
>> [md:debug] [pid 7508:tid 1052] md_curl.c(258): (20014)Internal error 
>> (specific information not available): request 10 failed(60): Peer 
>> certificate cannot be authenticated with given CA certificates
> 
> Ok, this needs to be logged at ERROR level, so users do not have to mess with 
> LogLevel to see what is going on.
> 
> As for the reason, this seems to indicate that the curl client finds no way 
> to verify the Let's Encrypt server certificate. Can you verify that the 
> "curl.exe" can connect to "https://acme-v01.api.letsencrypt.org/directory; 
> and retrieve the JSON there *without* you giving it the '-k' or '--insecure' 
> option? And where does your curl.exe/libcurl come from? Did you build it 
> yourself?
> 
>> [md:debug] [pid 7508:tid 1052] md_acme.c(425): (20014)Internal error 
>> (specific information not available): req sent
>> [md:error] [pid 7508:tid 1052] (20014)Internal error (specific information 
>> not available): apachelounge.nl: setup 
>> ACME(https://acme-v01.api.letsencrypt.org/directory)
>> [md:debug] [pid 7508:tid 1052] md_acme_drive.c(912): (20014)Internal error 
>> (specific information not available): apachelounge.nl: ACME, ACME staging
>> [md:debug] [pid 7508:tid 1052] md_reg.c(891): (20014)Internal error 
>> (specific information not available): apachelounge.nl: staging done
>> [md:error] [pid 7508:tid 1052] (20014)Internal error (specific information 
>> not available): AH10056: processing apachelounge.nl
>> [md:info] [pid 7508:tid 1052] AH10057: apachelounge.nl: encountered error 
>> for the 6. time, next run in 0:02:40 hours
>> ...
>> 
>> Maybe a little solution:  starting httpd, mod_md checks if LE is reachable 
>> without error.
> 
> No, I think checking external servers on every httpd restart is a good idea.
> 
>> And a solution for the below one can be: make a check that 443 and/or 80 is 
>> used.
>> 
>> Still my questions:
>> 
>> Does the retry stop ?
> 
> The retry does not stop, but it uses longer and longer retry intervals. 
> Exactly to recover from errors with the ACME server that are recoverable, 
> e.g. server/internet down. Your local certificate store not able to verify 
> the 

Re: mod_md 1.1.0 repeating on error

[Stefan Eissing]

> Am 12.12.2017 um 13:47 schrieb Steffen :
> 
> It was happening before 1.1.0, but i did not give it attention, seen it in 
> several situations which all I unfortunate cannot recall (see the retries  as 
> example https://github.com/icing/mod_md/issues/52and 
> https://github.com/icing/mod_md/issues/62 ).
> 
> It is a more serious issue then I thought before. 
> 
> I think we must first fix this, otherwise it is a bad introduction to our 
> users. This because Windows community first-time users learned that they  are 
> dealing with it and are dealing with all kind of (try) errors, most users 
> stopped using it.  As said in an other post mod_md is not that easy to start 
> with.
> 
> Also when the loglevel is on the default Warn, users see hardly what is 
> happening. I advise our users to use  LogLevel info md:trace2 ssl:notice
> 
> The Endless Retry loop Tested now in the following situations, tested during 
> renew and no new certificate is generated, httpd running fine with the old 
> certificate which was still valid.
> 
> 1 - Mis-configuration like below.
> 2 - ACME CA service  down (cause Letsencrypt down)
> 3 - ACME CA service not reachable (cause local network, or OS 
> failure/misconfig)
> 4 - Error response (Get/Post errors)when accessing Letsencrypt, dependency 
> issue like curl, mod_ssl.
> 5 - mod_md/mod_ssl faults
> 6 - Should be more
> 
> 
> 2) 3) Both can be that Letsencrypt is temp down maybe retry there, but hard 
> to tell if the cause is temp LE-Down, issue local or OS misconfig.
> 
> 4) Is a good example: Error response from LE, which happens quite  some 
> situations, Curl issues, Rate-Limits, mod_md faults  etc.
> 
> Below I introduced a Curl issue:
> 
> ...
> [md:debug] [pid 7508:tid 1052] mod_md.c(762): AH10055: md watchdog run, auto 
> drive 2 mds
> [md:debug] [pid 7508:tid 1052] mod_md.c(691): AH10052: md(apachelounge.nl): 
> state=2, driving
> [md:debug] [pid 7508:tid 1052] md_reg.c(884): apachelounge.nl: run staging
> [md:debug] [pid 7508:tid 1052] md_acme_drive.c(690): apachelounge.nl: staging 
> started, state=2, can_http=0, can_https=1, challenges='tls-sni-01'
> [md:debug] [pid 7508:tid 1052] md_store_fs.c(690): purge 
> staging/apachelounge.nl (D:/servers/apacheS/md/staging/apachelounge.nl)
> [md:debug] [pid 7508:tid 1052] md_acme.c(144): get directory from 
> https://acme-v01.api.letsencrypt.org/directory
> [md:debug] [pid 7508:tid 1052] md_acme.c(407): req: POST 
> https://acme-v01.api.letsencrypt.org/directory
> [md:debug] [pid 7508:tid 1052] md_curl.c(258): (20014)Internal error 
> (specific information not available): request 10 failed(60): Peer certificate 
> cannot be authenticated with given CA certificates

Ok, this needs to be logged at ERROR level, so users do not have to mess with 
LogLevel to see what is going on.

As for the reason, this seems to indicate that the curl client finds no way to 
verify the Let's Encrypt server certificate. Can you verify that the "curl.exe" 
can connect to "https://acme-v01.api.letsencrypt.org/directory; and retrieve 
the JSON there *without* you giving it the '-k' or '--insecure' option? And 
where does your curl.exe/libcurl come from? Did you build it yourself?

> [md:debug] [pid 7508:tid 1052] md_acme.c(425): (20014)Internal error 
> (specific information not available): req sent
> [md:error] [pid 7508:tid 1052] (20014)Internal error (specific information 
> not available): apachelounge.nl: setup 
> ACME(https://acme-v01.api.letsencrypt.org/directory)
> [md:debug] [pid 7508:tid 1052] md_acme_drive.c(912): (20014)Internal error 
> (specific information not available): apachelounge.nl: ACME, ACME staging
> [md:debug] [pid 7508:tid 1052] md_reg.c(891): (20014)Internal error (specific 
> information not available): apachelounge.nl: staging done
> [md:error] [pid 7508:tid 1052] (20014)Internal error (specific information 
> not available): AH10056: processing apachelounge.nl
> [md:info] [pid 7508:tid 1052] AH10057: apachelounge.nl: encountered error for 
> the 6. time, next run in  0:02:40 hours
> ...
> 
> Maybe a little solution:  starting httpd, mod_md checks if LE is reachable 
> without error.

No, I think checking external servers on every httpd restart is a good idea.

> And a solution for the below one can be: make a check that 443 and/or 80 is 
> used.
> 
> Still my questions:
> 
> Does the retry stop ?

The retry does not stop, but it uses longer and longer retry intervals. Exactly 
to recover from errors with the ACME server that are recoverable, e.g. 
server/internet down. Your local certificate store not able to verify the LE 
server will not recover itself, however.

> When does it happen, on what errors ?

On any error where signup/renew is necessary and could not complete.

> 
> 
> Steffen
> 
>  
> On Tuesday 12/12/2017 at 10:18, Stefan Eissing wrote:
>> Can you switch to "LogLevel md:debug" for a while and send me the details? 
>> Did this start on the v1.1.0 or before that?
>> 
>>> Am 

Re: mod_md 1.1.0 repeating on error

[Steffen]

It was happening before 1.1.0, but i did not give it attention, seen 
it in several situations which all I unfortunate cannot recall (see 
the retries  as example https://github.com/icing/mod_md/issues/52 and 
https://github.com/icing/mod_md/issues/62 ).


It is a more serious issue then I thought before.


I think we must first fix this, otherwise it is a bad introduction to 
our users. This because Windows community first-time users learned 
that they  are dealing with it and are dealing with all kind of (try) 
errors, most users stopped using it.  As said in an other post mod_md 
is not that easy to start with.



Also when the loglevel is on the default Warn, users see hardly what 
is happening. I advise our users to use  LogLevel info md:trace2 
ssl:notice


The Endless Retry loop Tested now in the following situations, tested 
during renew and no new certificate is generated, httpd running fine 
with the old certificate which was still valid.


1 - Mis-configuration like below.
2 - ACME CA service  down (cause Letsencrypt down)
3 - ACME CA service not reachable (cause local network, or OS 
failure/misconfig)
4 - Error response (Get/Post errors)when accessing Letsencrypt, 
dependency issue like curl, mod_ssl.

5 - mod_md/mod_ssl faults
6 - Should be more


2) 3) Both can be that Letsencrypt is temp down maybe retry there, but 
hard to tell if the cause is temp LE-Down, issue local or OS 
misconfig.


4) Is a good example: Error response from LE, which happens quite  
some situations, Curl issues, Rate-Limits, mod_md faults  etc.


Below I introduced a Curl issue:


...

[md:debug] [pid 7508:tid 1052] mod_md.c(762): AH10055: md watchdog 
run, auto drive 2 mds
[md:debug] [pid 7508:tid 1052] mod_md.c(691): AH10052: 
md(apachelounge.nl): state=2, driving
[md:debug] [pid 7508:tid 1052] md_reg.c(884): apachelounge.nl: run 
staging
[md:debug] [pid 7508:tid 1052] md_acme_drive.c(690): apachelounge.nl: 
staging started, state=2, can_http=0, can_https=1, 
challenges='tls-sni-01'
[md:debug] [pid 7508:tid 1052] md_store_fs.c(690): purge 
staging/apachelounge.nl 
(D:/servers/apacheS/md/staging/apachelounge.nl)
[md:debug] [pid 7508:tid 1052] md_acme.c(144): get directory from 
https://acme-v01.api.letsencrypt.org/directory
[md:debug] [pid 7508:tid 1052] md_acme.c(407): req: POST 
https://acme-v01.api.letsencrypt.org/directory
[md:debug] [pid 7508:tid 1052] md_curl.c(258): (20014)Internal error 
(specific information not available): request 10 failed(60): Peer 
certificate cannot be authenticated with given CA certificates
[md:debug] [pid 7508:tid 1052] md_acme.c(425): (20014)Internal error 
(specific information not available): req sent
[md:error] [pid 7508:tid 1052] (20014)Internal error (specific 
information not available): apachelounge.nl: setup 
ACME(https://acme-v01.api.letsencrypt.org/directory)
[md:debug] [pid 7508:tid 1052] md_acme_drive.c(912): (20014)Internal 
error (specific information not available): apachelounge.nl: ACME, 
ACME staging
[md:debug] [pid 7508:tid 1052] md_reg.c(891): (20014)Internal error 
(specific information not available): apachelounge.nl: staging done
[md:error] [pid 7508:tid 1052] (20014)Internal error (specific 
information not available): AH10056: processing apachelounge.nl
[md:info] [pid 7508:tid 1052] AH10057: apachelounge.nl: encountered 
error for the 6. time, next run in  0:02:40 hours

...

Maybe a little solution:  starting httpd, mod_md checks if LE is 
reachable without error.


And a solution for the below one can be: make a check that 443 and/or 
80 is used.


Still my questions:

Does the retry stop ?
When does it happen, on what errors ?


Steffen



On Tuesday 12/12/2017 at 10:18, Stefan Eissing  wrote:
Can you switch to "LogLevel md:debug" for a while and send me the 
details? Did this start on the v1.1.0 or before that?




Am 11.12.2017 um 16:09 schrieb Steffen :


Running 1.1.0 with the new naming.

When mod_md encounters an error it looks like it is going in a endless 
loop:



[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 1. time, next run in  0:00:05 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 2. time, next run in  0:00:10 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 3. time, next run in  0:00:20 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 4. time, next run in  0:00:40 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 5. time, next run in  0:01:20 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 6. time, next run in  0:02:40 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 7. time, next run in  0:05:20 hours
[md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered 
error for the 8. time, next run in  0:10:40 hours

...
...
...

Re: svn propchange: r1817894 - svn:log

[ste...@eissing.org]

Sorry, Rüdiger. 

> Am 12.12.2017 um 10:36 schrieb rj...@apache.org:
> 
> Author: rjung
> Revision: 1817894
> Modified property: svn:log
> 
> Modified: svn:log at Tue Dec 12 09:36:05 2017
> --
> --- svn:log (original)
> +++ svn:log Tue Dec 12 09:36:05 2017
> @@ -1,4 +1,4 @@
> On the trunk:
> 
> -mod_ssl: fixed orphaned code path in ssl policy lookup after review by rainer
> +mod_ssl: fixed orphaned code path in ssl policy lookup after review by rpluem
> 
> 

2.4.x STATUS needs you!

[Stefan Eissing]

Fellow Apache developers: if we want to make an X-mas 2.4 release for the 
people on this planet, the backports in STATUS need your attention:

B1: mod_proxy, mod_ssl: Handle SSLProxy* directives in  sections,
  - needs 1 more vote!
B2: mod_remoteip: Add PROXY protocol support
  - needs 1 more vote!
B3: core/mod_ssl: Add new flag int to module struct.
  - needs 1 more vote!
B4: core: A signal received while stopping could have crashed the main process
  - needs 1 more vote!
B5: mod_journald: Add new module mod_journald to log error logs into journald.
  - has comments
B6: mpm_event: avoid a very unlikely race condition
  - needs 1 more vote!
B7: core: silently ignore a not existent file path when IncludeOptional is used.
  - needs 1 more vote!
B8: mod_md: backport of ACME (Let's Encrypt) support.
  - needed 1 more vote, reset after name change
  - requires B3
B9: mod_md related ssl changes
  - has the votes
  - requires B8
B10: mod_proxy_uwsgi: Add in UWSGI proxy (sub)module
  - needs 2 votes

I also like to add the SSLPolicy things for a backport, but that requires a
decision on B1 as the patch is heavily affected by it.

Hope you find some time to test and vote!

Cheers,

Stefan

PS. If you announce you will test, but then do not find the time, let others 
know so they may step in!

Re: mod_md 1.1.0 repeating on error

[Stefan Eissing]

Can you switch to "LogLevel md:debug" for a while and send me the details? Did 
this start on the v1.1.0 or before that?

> Am 11.12.2017 um 16:09 schrieb Steffen :
> 
> 
> Running 1.1.0 with the new naming.
> 
> When mod_md encounters an error it looks like it is going in a endless loop:
> 
> 
> [md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered error 
> for the 1. time, next run in  0:00:05 hours
> [md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered error 
> for the 2. time, next run in  0:00:10 hours
> [md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered error 
> for the 3. time, next run in  0:00:20 hours
> [md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered error 
> for the 4. time, next run in  0:00:40 hours
> [md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered error 
> for the 5. time, next run in  0:01:20 hours
> [md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered error 
> for the 6. time, next run in  0:02:40 hours
> [md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered error 
> for the 7. time, next run in  0:05:20 hours
> [md:info] [pid 10372:tid 1964] AH10057: apachelounge.nl: encountered error 
> for the 8. time, next run in  0:10:40 hours
> ...
> ...
> ...
> 
> Above is during renew and using port 444..
> 
> Apache is running fine  because the certificate is still valid.
> 
> Does it stop ?
> 
> When does it happen,  on what errors ? Above happens when: (20014)Internal 
> error (specific information not available): AH10056: processing 
> apachelounge.nl.
> 
> What to do.  Stopping on above retries can be tricky because when the ACME CA 
> service is temp down or not reachable we do want maybe a retry.  A reachable 
> error/down error is different then a configuration error causing it like in 
> above case..
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: svn commit: r1817381 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/sections.xml modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c modules/ssl/ssl_policies.h modules/

[Stefan Eissing]

Right, you are. Fixed in r1817894.

Changes and Lookups happen now in the same main config pool, so the logic for 
subpools is no longer needed.

Thanks for reviewing!

-Stefan

> Am 11.12.2017 um 21:08 schrieb Ruediger Pluem :
> 
> 
> 
> On 12/07/2017 04:11 PM, ic...@apache.org wrote:
>> Author: icing
>> Date: Thu Dec  7 15:11:13 2017
>> New Revision: 1817381
>> 
>> URL: http://svn.apache.org/viewvc?rev=1817381=rev
>> Log:
>> On the trunk:
>> 
>> mod_ssl: renamed section > for new server config merge flag. Denying global, only once used 
>> directives
>> inside a SSLPolicyDefine.
>> 
>> 
>> Modified:
>>httpd/httpd/trunk/CHANGES
>>httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml
>>httpd/httpd/trunk/docs/manual/sections.xml
>>httpd/httpd/trunk/modules/ssl/mod_ssl.c
>>httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
>>httpd/httpd/trunk/modules/ssl/ssl_policies.h
>>httpd/httpd/trunk/modules/ssl/update_policies.py
>> 
> 
>> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_config.c?rev=1817381=1817380=1817381=diff
>> ==
>> --- httpd/httpd/trunk/modules/ssl/ssl_engine_config.c (original)
>> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_config.c Thu Dec  7 15:11:13 
>> 2017
>> @@ -93,7 +93,7 @@ void ssl_config_global_fix(SSLModConfigR
>> 
>> BOOL ssl_config_global_isfixed(SSLModConfigRec *mc)
>> {
>> -return mc->bFixed;
>> +return mc && mc->bFixed;
>> }
>> 
>> /*  _
>> @@ -635,7 +635,7 @@ static apr_array_header_t *get_policy_na
>> 
>> SSLPolicyRec *ssl_policy_lookup(apr_pool_t *pool, const char *name)
>> {
>> -apr_hash_t *policies = get_policies(pool, 0);
>> +apr_hash_t *policies = get_policies(pool, 1);
>> if (policies) {
>> return apr_hash_get(policies, name, APR_HASH_KEY_STRING);
>> }
> 
> Hm, the else case below the lines above does not seem to be needed any 
> longer, since policies should not be NULL, correct?
> 
> Regards
> 
> Rüdiger