You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2017/11/15 09:59:20 UTC
Let's Encrypt Feature Release
Now that Gregg has landed Windows build support in trunk (yay!), I would really like us to include the Let's Encrypt Support in the next 2.4 release as an experimental mod_md plus the required and recommended changes to mod_ssl.
Atm there is one blocker that prevents me from proposing mod_ssl backports: the pending backport of "Handle SSLProxy* directives in <Proxy> sections" by Yann. That one has just many changes in the module and making independant patches with/without that one is too much work. With one vote missing, if anyone could find the cycles to vote on that, that'd be great.
Once that is out of the way, I will propose the following changes for backport:
1. mod_md plus the *required* mod_ssl changes for interworking
2. SSLPolicy/SSLProxyPolicy feature
3. SSLEngine addr:port feature
2+3 are not required. For 2 I have gotten a lot of responses by people who'd like to have that for their servers. 3 I do not feel strong about.
Maybe we can give our early adopters a nice Xmas present.
Cheers,
Stefan
Re: Let's Encrypt Feature Release
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1 from me!!
> On Nov 15, 2017, at 4:59 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>
> Now that Gregg has landed Windows build support in trunk (yay!), I would really like us to include the Let's Encrypt Support in the next 2.4 release as an experimental mod_md plus the required and recommended changes to mod_ssl.
>
> Atm there is one blocker that prevents me from proposing mod_ssl backports: the pending backport of "Handle SSLProxy* directives in <Proxy> sections" by Yann. That one has just many changes in the module and making independant patches with/without that one is too much work. With one vote missing, if anyone could find the cycles to vote on that, that'd be great.
>
> Once that is out of the way, I will propose the following changes for backport:
>
> 1. mod_md plus the *required* mod_ssl changes for interworking
> 2. SSLPolicy/SSLProxyPolicy feature
> 3. SSLEngine addr:port feature
>
> 2+3 are not required. For 2 I have gotten a lot of responses by people who'd like to have that for their servers. 3 I do not feel strong about.
>
> Maybe we can give our early adopters a nice Xmas present.
>
> Cheers,
>
> Stefan
>
>
Re: Let's Encrypt Feature Release
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Nov 15, 2017 at 10:59 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> Now that Gregg has landed Windows build support in trunk (yay!), I
> would really like us to include the Let's Encrypt Support in the next
> 2.4 release as an experimental mod_md plus the required and
> recommended changes to mod_ssl.
Sounds like a good plan to me, I'll review the proposal (no strong
opinion about +- bullets 2. and 3.).
Thanks Stefan for the good work!
Regards,
Yann.
Re: Let's Encrypt Feature Release
Posted by Steffen <in...@apachelounge.com>.
Yep, we had some discussions. Language was for me a problem to get my wishes/issues to get understand. I had also language problems with others on this list in the past. I mostly do not understand all when posted, and I am not understood.
It was a pleasure to test mod_md on windows.
The result is very positive for me and Apachelounge community, and as I said time to go with mod_mod.
By me and others at Apachelounge reported issues and requests have resulted in changes applied with mod_mod, see issues git and apachelounge.
> Op 20 nov. 2017 om 12:21 heeft Stefan Eissing <st...@greenbytes.de> het volgende geschreven:
>
> Disclaimer: Steffen and me got into each others hairs during the development and testing of mod_md. I often have difficulties understanding what he means. That led to frustrations on both sides, I suppose.
>
> In the comment below, I find several things factually wrong, so I need to answer.
>
>> Am 19.11.2017 um 16:21 schrieb Steffen <in...@apachelounge.com>:
>>
>> Notes:
>>
>> It is not really a module, more a configuration/install utility. And introducing curl and jansson dependencies.
>
> It does several things and "install" utility cannot do without either living in the server or parsing/rewriting arbitrary config files. But if you never use these additional features, other tools might work as well, sure.
>
>> Running mod_md from the beginning and made available at ApacheLounge. It was a struggle to get it working for me and others, docu needs more eyes for reviews. It works ok, but I do not see that advantage over other utilities out there.
>
> You should use the utility that serves you best. If you expect any less than struggle when using pre-alpha versions in development, you should adjust your expectations.
>
>> In January LetsEncrypt is starting with wildcard certs. Maybe worth to wait. I know users waiting for that and experience learns that changes at LE can trouble mod_md.
>
> This is FUD. The protocol that mod_md talks with LE will not change by the wildcard introduction. LE is prepared to maintain the current v1 API point indefinitely, because there are many sites and tools out there that use it.
>
> The bug you probably refer to was the change of the License agreement last week, mod_md stalled on certificate renewal and gave a proper NOTICE message in the logs about what went wrong. The bug was fixed by me the next day. A workaround without the fix is possible by moving aside the existing account data.
>
> So, had this been released already, we could have provided a workaround at once (after analysing the problem) and a fix right after. The marking of it as "experimental" is always a warning that some bumps in the road are to be expected.
>
> Cheers,
>
> Stefan
>
Re: Let's Encrypt Feature Release
Posted by Stefan Eissing <st...@greenbytes.de>.
Disclaimer: Steffen and me got into each others hairs during the development and testing of mod_md. I often have difficulties understanding what he means. That led to frustrations on both sides, I suppose.
In the comment below, I find several things factually wrong, so I need to answer.
> Am 19.11.2017 um 16:21 schrieb Steffen <in...@apachelounge.com>:
>
> Notes:
>
> It is not really a module, more a configuration/install utility. And introducing curl and jansson dependencies.
It does several things and "install" utility cannot do without either living in the server or parsing/rewriting arbitrary config files. But if you never use these additional features, other tools might work as well, sure.
> Running mod_md from the beginning and made available at ApacheLounge. It was a struggle to get it working for me and others, docu needs more eyes for reviews. It works ok, but I do not see that advantage over other utilities out there.
You should use the utility that serves you best. If you expect any less than struggle when using pre-alpha versions in development, you should adjust your expectations.
> In January LetsEncrypt is starting with wildcard certs. Maybe worth to wait. I know users waiting for that and experience learns that changes at LE can trouble mod_md.
This is FUD. The protocol that mod_md talks with LE will not change by the wildcard introduction. LE is prepared to maintain the current v1 API point indefinitely, because there are many sites and tools out there that use it.
The bug you probably refer to was the change of the License agreement last week, mod_md stalled on certificate renewal and gave a proper NOTICE message in the logs about what went wrong. The bug was fixed by me the next day. A workaround without the fix is possible by moving aside the existing account data.
So, had this been released already, we could have provided a workaround at once (after analysing the problem) and a fix right after. The marking of it as "experimental" is always a warning that some bumps in the road are to be expected.
Cheers,
Stefan
Re: Let's Encrypt Feature Release
Posted by Steffen <in...@apachelounge.com>.
To get more needed feedback, it is good to go with experimental mod_md, not with a2md.
Be aware that we have then experimental code in mod_ssl !
Hereby I want to request to notify on error, see below. Missing message(s) in the log can end with a non working ssl site.
The command line utility a2md I have not seen tested by users, a -1 for a2md special because it needs a change for windows to get it working, see below.
2and3 not seen used so far, no opinion.
The .dsp’s etc. are ok in trunk. Utility a2md.exe needs for windows the include of OpenSSL applink.c, like in abs.exe.
Notes:
It is not really a module, more a configuration/install utility. And introducing curl and jansson dependencies.
Running mod_md from the beginning and made available at ApacheLounge. It was a struggle to get it working for me and others, docu needs more eyes for reviews. It works ok, but I do not see that advantage over other utilities out there.
Mod_md is standard oh so silence what it is doing behind the scenes. And with (config)errors it is quite a puzzle what is wrong, loglevel debug/trace2 is mostly needed to figure out. When you miss a message for example with renew in the log, then a change you end with a not working ssl site.
I like to make request to make it possible that on an error we can get a notify (like MDNotifyCmd) for example by email.
On my request already info/ warnings were added. We need more users to evaluate.
In January LetsEncrypt is starting with wildcard certs. Maybe worth to wait. I know users waiting for that and experience learns that changes at LE can trouble mod_md.
> Op 15 nov. 2017 om 10:59 heeft Stefan Eissing <st...@greenbytes.de> het volgende geschreven:
>
> Now that Gregg has landed Windows build support in trunk (yay!), I would really like us to include the Let's Encrypt Support in the next 2.4 release as an experimental mod_md plus the required and recommended changes to mod_ssl.
>
> Atm there is one blocker that prevents me from proposing mod_ssl backports: the pending backport of "Handle SSLProxy* directives in <Proxy> sections" by Yann. That one has just many changes in the module and making independant patches with/without that one is too much work. With one vote missing, if anyone could find the cycles to vote on that, that'd be great.
>
> Once that is out of the way, I will propose the following changes for backport:
>
> 1. mod_md plus the *required* mod_ssl changes for interworking
> 2. SSLPolicy/SSLProxyPolicy feature
> 3. SSLEngine addr:port feature
>
> 2+3 are not required. For 2 I have gotten a lot of responses by people who'd like to have that for their servers. 3 I do not feel strong about.
>
> Maybe we can give our early adopters a nice Xmas present.
>
> Cheers,
>
> Stefan
>
>