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).


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 ).

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( state=2, driving [md:debug] [pid 7508:tid 1052] md_reg.c(884): run staging [md:debug] [pid 7508:tid 1052] md_acme_drive.c(690): 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/ (D:/servers/apacheS/md/staging/ [md:debug] [pid 7508:tid 1052] md_acme.c(144): get directory from [md:debug] [pid 7508:tid 1052] md_acme.c(407): req: POST [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 ""; 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): setup ACME( [md:debug] [pid 7508:tid 1052] md_acme_drive.c(912): (20014)Internal error (specific information not available): ACME, ACME staging [md:debug] [pid 7508:tid 1052] md_reg.c(891): (20014)Internal error (specific information not available): staging done [md:error] [pid 7508:tid 1052] (20014)Internal error (specific information not available): AH10056: processing [md:info] [pid 7508:tid 1052] AH10057: 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.


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: encountered error for the 1. time, next run in 0:00:05 hours [md:info] [pid 10372:tid 1964] AH10057: encountered error for the 2. time, next run in 0:00:10 hours [md:info] [pid 10372:tid 1964] AH10057: encountered error for the 3. time, next run in 0:00:20 hours [md:info] [pid 10372:tid 1964] AH10057: encountered error for the 4. time, next run in 0:00:40 hours [md:info] [pid 10372:tid 1964] AH10057: encountered error for the 5. time, next run in 0:01:20 hours [md:info] [pid 10372:tid 1964] AH10057: encountered error for the 6. time, next run in 0:02:40 hours [md:info] [pid 10372:tid 1964] AH10057: encountered error for the 7. time, next run in 0:05:20 hours [md:info] [pid 10372:tid 1964] AH10057: 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

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..

Reply via email to