Re: [VOTE] Release httpd-2.4.40
Daniel Ruggeri in gmane.comp.apache.devel (Mon, 05 Aug 2019 18:54:18 -0500): >Thanks, Jan; > I'm afraid I have no way to verify or dig into Windows-specific > issues. Can you share more information or errors that can help, or is > this related to the things already discussed on the list? There is a fix for the APLOGNO warnings in trunk. And there is a solution for my problems with mod_md.so. See https://lists.apache.org/thread.html/8246b0b077defd9a84d6cc3e32cf0d87a8a4753c2f7f566de336e4d5@ and follow-up messages. -- Jan
[RESULT] [VOTE] Release httpd-2.4.40
Hi, All; As discussed on this list, a minor regression has been detected with a fix in flight. I'll go ahead and terminate this release vote and will plan to T&R again in the near future with the fix in place. Thanks to all who prepped for testing. Keep those testing rigs warm - we'll be back again soon! -- Daniel Ruggeri On August 3, 2019 8:51:07 AM CDT, Daniel Ruggeri wrote: >Hi, all; > Please find below the proposed release tarball and signatures: >https://dist.apache.org/repos/dist/dev/httpd/ > >I would like to call a VOTE over the next few days to release this >candidate tarball as 2.4.40: >[ ] +1: It's not just good, it's good enough! >[ ] +0: Let's have a talk. >[ ] -1: There's trouble in paradise. Here's what's wrong. > >The computed digests of the tarball up for vote are: >sha1: 31bc6f87ac209010b8b364abc1c80dfaee53cc64 *httpd-2.4.40.tar.gz >sha256: >451e6cf6caa09119900b74652266427f70050de5c51948acd4aaaf60d0d3cad0 >*httpd-2.4.40.tar.gz > >-- >Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.40
Thanks, Jan; I'm afraid I have no way to verify or dig into Windows-specific issues. Can you share more information or errors that can help, or is this related to the things already discussed on the list? -- Daniel Ruggeri On August 4, 2019 6:33:58 AM CDT, Jan Ehrhardt wrote: >Gregg Smith in gmane.comp.apache.devel (Sat, 3 Aug 2019 08:43:21 >-0700): >>Opps, looks like the APLOGNO's didn't get filled in. I'm still ok with > >>releasing .40 w/o them. >> >>mod_md.c(386): warning C4003: not enough actual parameters for macro >>'APLOGNO' >>mod_md.c(391): warning C4003: not enough actual parameters for macro >>'APLOGNO' >>mod_md.c(601): warning C4003: not enough actual parameters for macro >>'APLOGNO' >>mod_md.c(608): warning C4003: not enough actual parameters for macro >>'APLOGNO' >>mod_md.c(659): warning C4003: not enough actual parameters for macro >>'APLOGNO' >>mod_md.c(702): warning C4003: not enough actual parameters for macro >>'APLOGNO' >>mod_md.c(912): warning C4003: not enough actual parameters for macro >>'APLOGNO' > >My conclusion after testing a lot of Visual Studio builds: mod_md.so is >broken. At least on Windows, but probably on any other OS as well. Do >not release this version. >-- >Jan
buildbot failure in on httpd-trunk
The Buildbot has detected a new failure on builder httpd-trunk while building . Full details are available at: https://ci.apache.org/builders/httpd-trunk/builds/3863 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: bb_slave6_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'httpd-trunk-on-commit' triggered this build Build Source Stamp: [branch httpd/httpd/trunk] 1864435 Blamelist: rjung BUILD FAILED: failed compile Sincerely, -The Buildbot
Re: [VOTE] Release httpd-2.4.40
The fix is in trunk and I proposed it for backport. Needs 2 votes. > Am 05.08.2019 um 15:44 schrieb Jan Ehrhardt : > > Jim Jagielski in gmane.comp.apache.devel (Mon, 5 Aug 2019 09:15:22 > -0400): >> I vote -1 due to the known issue w/ building and running mod_md. >> >> Yes, it's not a regression, but the fix is easy and version numbers are >> cheap. We should release the best possible version each time. > > The fix for the APLOGNO warnings is probably easy. But a fix for 'my' > issue with running it in combination with a SSLCertificateChainFile > directive might not be that easy, if possible at all. But Stefan Eissing > should be able to tell us. > -- > Jan >
Re: [VOTE] Release httpd-2.4.40
Jim Jagielski in gmane.comp.apache.devel (Mon, 5 Aug 2019 09:15:22 -0400): >I vote -1 due to the known issue w/ building and running mod_md. > >Yes, it's not a regression, but the fix is easy and version numbers are >cheap. We should release the best possible version each time. The fix for the APLOGNO warnings is probably easy. But a fix for 'my' issue with running it in combination with a SSLCertificateChainFile directive might not be that easy, if possible at all. But Stefan Eissing should be able to tell us. -- Jan
Re: [VOTE] Release httpd-2.4.40
On 8/5/19 4:04 AM, Joe Orton wrote: > On Sun, Aug 04, 2019 at 04:51:45PM -0400, Dennis Clarke wrote: >> Quick reply here to let you know that the build fails instantly >> within server/config.c at func process_resource_config_cb() with >> a strange error uttered by Oracle Studio 12.6 thus : > ... >> "config.c", line 1907: error: undefined symbol: ap_dir_match_t > > Do you have httpd headers installed in /usr/local/include from an older > httpd? My best guess would be it's picking up the wrong httpd.h. > > Regards, Joe > Yes of course .. sorry for the noises. Having done this fifty times you would think I would recall to check for the previous versions headers. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: mod_md with no vhosts, sni and ssl only, no go
Thanks, Same, also get again : The https: challenge 'tls-alpn-01' is disabled because the Protocols configuration does not include the 'acme-tls/1' protocol. It is in the protocols directive: ProtocolsHonorOrder On Protocols h2 http/1.1 acme-tls/1 MDomain apachelounge.nl www.apachelounge.nl vosadministraties.nl www.vosadministraties.nl land10web.com MDBaseServer on MDPortMap https:443 MDCertificateAgreement accepted MDRenewMode Always - Steffen On Monday 05/08/2019 at 14:52, Stefan Eissing wrote: I think mod_md is not particularly suited to server setups without any VirtualHosts. I have at least no tests for this. You can try (with a 2.4.40): # the new, shorter form MDCertificateAgreement accepted # we want the base server to be managed MDBaseServer on # the list of domains, including one from the base server MDomain apachelounge.nl http://www.apachelounge.nl vosadministraties.nlhttp://www.vosadministraties.nl land10web.com # since we have no vhost, we need to say where https requests arrive MDPortMap https:443 # since we have only https, we need to enable the new ACME tls challenge protocol Protocols h2 http/1.1 acme-tls/1 ... - Stefan Am 05.08.2019 um 14:06 schrieb Steffen : I read in the new docu that you can generate a certificate for domains(s) that does not appear in any host. So I did a try to generate one certificate for two domains (in Subject Alternative Name) Configuration SSL only on port 443 No vhosts Listen 443 Protocols h2 http/1.1 acme-tls/1 MDomain apachelounge.nl http://www.apachelounge.nl vosadministraties.nlhttp://www.vosadministraties.nl MDCertificateAgreement https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf MDRenewMode Always ServerName land10web.com SSLEngine on ... ... Apache does not start. It exits with a mod_ssl error, no SSL certificates configured and no other module contributed any See attachment serror1.log When I add to the config a valid certificate SSLCertificateFile conf/land10web.com-chain.pem SSLCertificateKeyFile conf/land10web.com key.pem Then Apache starts but mod_md gives error in the log. See attachment serror2.log See now e.g. : . - server seems not reachable via http: (port 80->80) and reachable via https: (port 443->443) - The https: challenge 'tls-alpn-01' is disabled because the Protocols configuration does not include the 'acme-tls/1' protocol. (it is in the protocols directive). Or what I want is not supported, or I do some wrong. Appreciate some help. - Steffen
Re: [VOTE] Release httpd-2.4.40
I vote -1 due to the known issue w/ building and running mod_md. Yes, it's not a regression, but the fix is easy and version numbers are cheap. We should release the best possible version each time. Let's mark 2.4.40 DOA and release 2.4.41 w/ the patch. > On Aug 3, 2019, at 9:51 AM, Daniel Ruggeri wrote: > > Hi, all; >Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.40: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: 31bc6f87ac209010b8b364abc1c80dfaee53cc64 *httpd-2.4.40.tar.gz > sha256: 451e6cf6caa09119900b74652266427f70050de5c51948acd4aaaf60d0d3cad0 > *httpd-2.4.40.tar.gz > > -- > Daniel Ruggeri >
Re: mod_md with no vhosts, sni and ssl only, no go
I think mod_md is not particularly suited to server setups without any VirtualHosts. I have at least no tests for this. You can try (with a 2.4.40): # the new, shorter form MDCertificateAgreement accepted # we want the base server to be managed MDBaseServer on # the list of domains, including one from the base server MDomain apachelounge.nl www.apachelounge.nl vosadministraties.nlwww.vosadministraties.nl land10web.com # since we have no vhost, we need to say where https requests arrive MDPortMap https:443 # since we have only https, we need to enable the new ACME tls challenge protocol Protocols h2 http/1.1 acme-tls/1 ... - Stefan > Am 05.08.2019 um 14:06 schrieb Steffen : > > > I read in the new docu that you can generate a certificate for domains(s) > that does not appear in any host. > > So I did a try to generate one certificate for two domains (in Subject > Alternative Name) > > Configuration > > SSL only on port 443 > No vhosts > > > > Listen 443 > > Protocols h2 http/1.1 acme-tls/1 > > MDomain apachelounge.nl www.apachelounge.nl > vosadministraties.nlwww.vosadministraties.nl > MDCertificateAgreement > https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf > MDRenewMode Always > > ServerName land10web.com > > SSLEngine on > ... > ... > > Apache does not start. It exits with a mod_ssl error, no SSL certificates > configured and no other module contributed any > See attachment serror1.log > > > When I add to the config a valid certificate > > SSLCertificateFile conf/land10web.com-chain.pem > SSLCertificateKeyFile conf/land10web.com key.pem > > Then Apache starts but mod_md gives error in the log. > See attachment serror2.log > > See now e.g. : . > - server seems not reachable via http: (port 80->80) and reachable via https: > (port 443->443) > - The https: challenge 'tls-alpn-01' is disabled because the Protocols > configuration does not include the 'acme-tls/1' protocol. (it is in the > protocols directive). > > > Or what I want is not supported, or I do some wrong. Appreciate some help. > > > - Steffen > > > > > > > > > > > > > > > > > > > > > > > > > > >
mod_md with no vhosts, sni and ssl only, no go
I read in the new docu that you can generate a certificate for domains(s) that does not appear in any host. So I did a try to generate one certificate for two domains (in Subject Alternative Name) Configuration SSL only on port 443 No vhosts Listen 443 Protocols h2 http/1.1 acme-tls/1 MDomain apachelounge.nl www.apachelounge.nl vosadministraties.nl www.vosadministraties.nl MDCertificateAgreement https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf MDRenewMode Always ServerName land10web.com SSLEngine on ... ... Apache does not start. It exits with a mod_ssl error, no SSL certificates configured and no other module contributed any See attachment serror1.log When I add to the config a valid certificate SSLCertificateFile conf/land10web.com-chain.pem SSLCertificateKeyFile conf/land10web.com key.pem Then Apache starts but mod_md gives error in the log. See attachment serror2.log See now e.g. : . - server seems not reachable via http: (port 80->80) and reachable via https: (port 443->443) - The https: challenge 'tls-alpn-01' is disabled because the Protocols configuration does not include the 'acme-tls/1' protocol. (it is in the protocols directive). Or what I want is not supported, or I do some wrong. Appreciate some help. - Steffen
Re: [VOTE] Release httpd-2.4.40
Runs all fine, no issues seen sofar. +1 On Saturday 03/08/2019 at 15:51, Daniel Ruggeri wrote: Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.40: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: 31bc6f87ac209010b8b364abc1c80dfaee53cc64 *httpd-2.4.40.tar.gz sha256: 451e6cf6caa09119900b74652266427f70050de5c51948acd4aaaf60d0d3cad0 *httpd-2.4.40.tar.gz -- Daniel Ruggeri
Re: svn commit: r1864425 - in/httpd/httpd/trunk/modules/md:md_acme_acct.c md_acme_order.c md_crypt.cmd_time.c md_version.h mod_md.cmod_md_config.c mod_md_drive.c
Oh so sorry. For completeness all the warnings of the mentioned modules: proxy\mod_proxy.c(111,28): warning C4244: '=': conversion from 'double' to 'int', possible loss of data proxy\mod_proxy.c(557,22): warning C4244: 'return': conversion from '__int64' to 'int', possible loss of data proxy\mod_proxy.c(1052,60): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' proxy\proxy_util.c(331,71): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(337,55): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(653,30): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(671,25): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(665,1): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(706,30): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(726,27): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(727,26): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(849,26): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(882,41): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(890,48): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(917,30): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(923,42): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(999,49): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(1019,51): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(1681,29): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(1696,37): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(1701,37): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(1714,64): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(1726,64): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(2225,60): warning C4267: 'function': conversion from 'size_t' to 'apr_int32_t', possible loss of data proxy\proxy_util.c(2708,22): warning C4267: '+=': conversion from 'size_t' to 'int', possible loss of data proxy\proxy_util.c(2986,69): warning C4267: 'function': conversion from 'size_t' to 'apr_int32_t', possible loss of data http2\h2_bucket_beam.c(306,36): warning C4018: '>': signed/unsigned mismatch http2\h2_conn_io.c(295,17): warning C4018: '>': signed/unsigned mismatch http2\h2_conn_io.c(301,20): warning C4018: '>': signed/unsigned mismatch http2\h2_from_h1.c(241,27): warning C4018: '<': signed/unsigned mismatch http2\h2_session.c(196,22): warning C4267: 'return': conversion from 'size_t' to 'long', possible loss of data http2\h2_session.c(642,77): warning C4267: '=': conversion from 'size_t' to 'long', possible loss of data http2\h2_session.c(649,48): warning C4267: '=': conversion from 'size_t' to 'long', possible loss of data http2\h2_session.c(659,28): warning C4267: 'return': conversion from 'size_t' to 'long', possible loss of data http2\h2_session.c(634,1): warning C4267: 'initializing': conversion from 'size_t' to 'long', possible loss of data http2\h2_session.c(1625,51): warning C4018: '>': signed/unsigned mismatch http2\h2_stream.c(787,1): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' http2\h2_stream.c(923,15): warning C4018: '<': signed/unsigned mismatch http2\h2_util.c(1284,28): warning C4018: '<': signed/unsigned mismatch http2\h2_util.c(1329,28): warning C4018: '<': signed/unsigned mismatch http2\h2_util.c(1434,26): warning C4018: '>': signed/unsigned mismatch http2\h2_util.c(1556,24): warning C4018: '<': signed/unsigned mismatch ssl\ssl_engine_config.c(551,1): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_config.c(639,1): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_init.c(275,48): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_io.c(620,60): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_io.c(626,44): warning C4267: '+=': conversion from 'size_t' to 'int', possible loss of data ssl\ssl_engine_io.c(669,75): warning C4267: 'function': conversion
Re: svn commit: r1864425 - in /httpd/httpd/trunk/modules/md:md_acme_acct.c md_acme_order.c md_crypt.c md_time.c md_version.h mod_md.cmod_md_config.c mod_md_drive.c
Hi Steffen, it would help, it you could copy in the warnings here. Not everyone uses a compiler setup that shows these warnings. Being explicit about observations lowers the bar for us to fix them. Thanks and regards, Rainer Am 05.08.2019 um 12:54 schrieb Steffen: Also APLOGNO warnings in: mod_proxy mod_http2 mod_ssl On Monday 05/08/2019 at 12:32, Rainer Jung wrote: Hi Stefan, Am 05.08.2019 um 12:27 schrieb ic...@apache.org: Author: icing Date: Mon Aug 5 10:27:34 2019 New Revision: 1864425 URL: http://svn.apache.org/viewvc?rev=1864425&view=rev Log: * mod_md: fix compiler warnings thanks for that. Some trailing spaces have now slipped in though (judged on the diff). Did you notice this report by Gregg: mod_md.c(386): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(391): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(601): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(608): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(659): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(702): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(912): warning C4003: not enough actual parameters for macro 'APLOGNO' Thanks and regards, Rainer
Re: svn commit: r1864425 - in /httpd/httpd/trunk/modules/md:md_acme_acct.c md_acme_order.c md_crypt.c md_time.c md_version.h mod_md.cmod_md_config.c mod_md_drive.c
Also APLOGNO warnings in: mod_proxy mod_http2 mod_ssl On Monday 05/08/2019 at 12:32, Rainer Jung wrote: Hi Stefan, Am 05.08.2019 um 12:27 schrieb ic...@apache.org: Author: icing Date: Mon Aug 5 10:27:34 2019 New Revision: 1864425 URL: http://svn.apache.org/viewvc?rev=1864425&view=rev Log: * mod_md: fix compiler warnings thanks for that. Some trailing spaces have now slipped in though (judged on the diff). Did you notice this report by Gregg: mod_md.c(386): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(391): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(601): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(608): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(659): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(702): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(912): warning C4003: not enough actual parameters for macro 'APLOGNO' Thanks and regards, Rainer
Re: svn commit: r1864425 - in /httpd/httpd/trunk/modules/md: md_acme_acct.c md_acme_order.c md_crypt.c md_time.c md_version.h mod_md.c mod_md_config.c mod_md_drive.c
> Am 05.08.2019 um 12:32 schrieb Rainer Jung : > > Hi Stefan, > > Am 05.08.2019 um 12:27 schrieb ic...@apache.org: >> Author: icing >> Date: Mon Aug 5 10:27:34 2019 >> New Revision: 1864425 >> URL: http://svn.apache.org/viewvc?rev=1864425&view=rev >> Log: >> * mod_md: fix compiler warnings > > thanks for that. Some trailing spaces have now slipped in though (judged on > the diff). > > Did you notice this report by Gregg: > > mod_md.c(386): warning C4003: not enough actual parameters for macro 'APLOGNO' > mod_md.c(391): warning C4003: not enough actual parameters for macro 'APLOGNO' > mod_md.c(601): warning C4003: not enough actual parameters for macro 'APLOGNO' > mod_md.c(608): warning C4003: not enough actual parameters for macro 'APLOGNO' > mod_md.c(659): warning C4003: not enough actual parameters for macro 'APLOGNO' > mod_md.c(702): warning C4003: not enough actual parameters for macro 'APLOGNO' > mod_md.c(912): warning C4003: not enough actual parameters for macro 'APLOGNO' This is from 2.4.x, or? I am just about to backport the current trunk there...I am working as fast as I can! :) > > Thanks and regards, > > Rainer
Re: svn commit: r1864425 - in /httpd/httpd/trunk/modules/md: md_acme_acct.c md_acme_order.c md_crypt.c md_time.c md_version.h mod_md.c mod_md_config.c mod_md_drive.c
Hi Stefan, Am 05.08.2019 um 12:27 schrieb ic...@apache.org: Author: icing Date: Mon Aug 5 10:27:34 2019 New Revision: 1864425 URL: http://svn.apache.org/viewvc?rev=1864425&view=rev Log: * mod_md: fix compiler warnings thanks for that. Some trailing spaces have now slipped in though (judged on the diff). Did you notice this report by Gregg: mod_md.c(386): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(391): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(601): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(608): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(659): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(702): warning C4003: not enough actual parameters for macro 'APLOGNO' mod_md.c(912): warning C4003: not enough actual parameters for macro 'APLOGNO' Thanks and regards, Rainer
Re: [VOTE] Release httpd-2.4.40
Stefan Eissing in gmane.comp.apache.devel (Mon, 5 Aug 2019 11:01:32 +0200): >I suspect it is the change in mod_ssl interface to the other modules. I >have to write a test for it. > >It used to be that this chain file was ignored in mod_ssl 2.4.39 when it >retrieved certificates from mod_md. Now mod_md adds its certificate via >a hook and the chain file seems to remain in effect. > >I would say that 2.4.40 refuses a configuration that does not really >make sense. And 2.4.39 silently ignored it. 2.4.40 accepts the configuration when there is a valid MDomain certificate. Then the intermediate certificate is loaded twice: by mod_md's hook and by the SSLCertificateChainFile directive. 2.4.40 apparently only refuses a fallback certificate in combination with the ChainFile. -- Jan
Re: [VOTE] Release httpd-2.4.40
I suspect it is the change in mod_ssl interface to the other modules. I have to write a test for it. It used to be that this chain file was ignored in mod_ssl 2.4.39 when it retrieved certificates from mod_md. Now mod_md adds its certificate via a hook and the chain file seems to remain in effect. I would say that 2.4.40 refuses a configuration that does not really make sense. And 2.4.39 silently ignored it. > Am 05.08.2019 um 10:53 schrieb Jan Ehrhardt : > > Stefan Eissing in gmane.comp.apache.devel (Mon, 5 Aug 2019 10:23:27 > +0200): >> Trying to sum up what you are saying: mod_md 2.4.40 does not introduce a >> new problem, but testing with it exposed an issue that affects both. >> There is no regression in 2.4.40. > > It was not an noticable issue in 2.4.39 and previous versions. The > SSLCertificateChainFile statement may have been superfluous, but it did > not prevent Apache from running and it also did not prevent mod_md to do > what it is supposed to do: generate a new certificate when the time is > there. It had been working flawlessly for the last 7 months. > >> As to the problem: the SSLCertificateChainFile directive made mod_ssl >> fail in conjunction with mod_md and an empty MDomain. Probably, the >> fallback certificate was conflicting with the additional chain file. >> This fallback is installed until mod_md gets the "real" certificate >> from Lets Encrypt. > > The fallback certificate does not conflict with the > SSLCertificateChainFile directive in 2.4.39. Any idea why it fails in > 2.4.40, but does not in 2.4.39? > >> I try to add a test case for that and see how we can improve the >> interworking. > > Thanks for your continuing work on the mod_md module! Thanks! Nice to hear! - Stefan > -- > Jan >
Re: [VOTE] Release httpd-2.4.40
Stefan Eissing in gmane.comp.apache.devel (Mon, 5 Aug 2019 10:23:27 +0200): >Trying to sum up what you are saying: mod_md 2.4.40 does not introduce a >new problem, but testing with it exposed an issue that affects both. >There is no regression in 2.4.40. It was not an noticable issue in 2.4.39 and previous versions. The SSLCertificateChainFile statement may have been superfluous, but it did not prevent Apache from running and it also did not prevent mod_md to do what it is supposed to do: generate a new certificate when the time is there. It had been working flawlessly for the last 7 months. >As to the problem: the SSLCertificateChainFile directive made mod_ssl >fail in conjunction with mod_md and an empty MDomain. Probably, the >fallback certificate was conflicting with the additional chain file. >This fallback is installed until mod_md gets the "real" certificate >from Lets Encrypt. The fallback certificate does not conflict with the SSLCertificateChainFile directive in 2.4.39. Any idea why it fails in 2.4.40, but does not in 2.4.39? >I try to add a test case for that and see how we can improve the interworking. Thanks for your continuing work on the mod_md module! -- Jan
Re: [VOTE] Release httpd-2.4.40
Trying to sum up what you are saying: mod_md 2.4.40 does not introduce a new problem, but testing with it exposed an issue that affects both. There is no regression in 2.4.40. As to the problem: the SSLCertificateChainFile directive made mod_ssl fail in conjunction with mod_md and an empty MDomain. Probably, the fallback certificate was conflicting with the additional chain file. This fallback is installed until mod_md gets the "real" certificate from Lets Encrypt. I try to add a test case for that and see how we can improve the interworking. - Stefan > Am 05.08.2019 um 10:12 schrieb Jan Ehrhardt : > > Jan Ehrhardt in gmane.comp.apache.devel (Sun, 04 Aug 2019 01:26:27 > +0200): >> Maybe some config changes are needed, but then they should be clearly >> documented in the change log. The trouble with this release is that the >> problem with mod_md will only show up when the first certificate has to >> be renewed. > > Countless tests later I guess I have found out what was wrong. The > server that I used for testing previously had a certificate by > letsencrypt-win-simple. Back in the old days you had to load the > intermediate certificate (Let's Encrypt Authority X3) with a > SSLCertificateChainFile statement. The server was still doing that. The > mod_md in 2.4.39 did not bother and just created a new certificate. > > However, the mod_md in 2.4.40 stumbled over it, despite the fact that > the intermediate certificate was exactly the same that mod_md would have > loaded. > > @icing: I tried it once again to see what is in the logs: > > | AH02572: Failed to configure at least one certificate and key for > example.com:443 > | SSL Library Error: error:140A80B1:SSL routines:SSL_CTX_check_private_key:no > certificate assigned > > This gave me no clue at all why it failed. And it was not Apache that > stumbled. With a valid MDomain certificate mod_md and the > SSLCertificateChainFile could happily co-exist. So without the test to > remove the /md dir I would have run into troubles at the moment when the > certificates had to be renewed (somewhere in September). > -- > Jan >
Re: [VOTE] Release httpd-2.4.40
Jan Ehrhardt in gmane.comp.apache.devel (Sun, 04 Aug 2019 01:26:27 +0200): >Maybe some config changes are needed, but then they should be clearly >documented in the change log. The trouble with this release is that the >problem with mod_md will only show up when the first certificate has to >be renewed. Countless tests later I guess I have found out what was wrong. The server that I used for testing previously had a certificate by letsencrypt-win-simple. Back in the old days you had to load the intermediate certificate (Let's Encrypt Authority X3) with a SSLCertificateChainFile statement. The server was still doing that. The mod_md in 2.4.39 did not bother and just created a new certificate. However, the mod_md in 2.4.40 stumbled over it, despite the fact that the intermediate certificate was exactly the same that mod_md would have loaded. @icing: I tried it once again to see what is in the logs: | AH02572: Failed to configure at least one certificate and key for example.com:443 | SSL Library Error: error:140A80B1:SSL routines:SSL_CTX_check_private_key:no certificate assigned This gave me no clue at all why it failed. And it was not Apache that stumbled. With a valid MDomain certificate mod_md and the SSLCertificateChainFile could happily co-exist. So without the test to remove the /md dir I would have run into troubles at the moment when the certificates had to be renewed (somewhere in September). -- Jan
Re: [VOTE] Release httpd-2.4.40
On Sun, Aug 04, 2019 at 04:51:45PM -0400, Dennis Clarke wrote: > Quick reply here to let you know that the build fails instantly > within server/config.c at func process_resource_config_cb() with > a strange error uttered by Oracle Studio 12.6 thus : ... > "config.c", line 1907: error: undefined symbol: ap_dir_match_t Do you have httpd headers installed in /usr/local/include from an older httpd? My best guess would be it's picking up the wrong httpd.h. Regards, Joe
Compilation warnings in 2.4.40 mod_md
Nothing critcal, just as an info that we should silence them before the next release: /path/to/modules/md/md_time.c:222: warning: ‘percent’ may be used uninitialized in this function /path/to/modules/md/md_time.c:238:65: warning: 'percent' may be used uninitialized in this function [-Wmaybe-uninitialized] and /path/to/modules/md/mod_md_drive.c:152: warning: ‘rv’ may be used uninitialized in this function I think at least the "percent" ones are false positives, but since we are warning free apart from the ones above, it would be nice to silence them. Regards, Rainer
Re: [VOTE] Release httpd-2.4.40
What fails and how? What is in the log? > Am 03.08.2019 um 21:22 schrieb Jan Ehrhardt : > > Gregg Smith in gmane.comp.apache.devel (Sat, 3 Aug 2019 08:43:21 -0700): >> On 8/3/2019 6:51 AM, Daniel Ruggeri wrote: >>> Hi, all; >>>Please find below the proposed release tarball and signatures: >>> https://dist.apache.org/repos/dist/dev/httpd/ >> >> [X] +1: It's good enough! >> >> VC14 & 15 x86 & x64 w/ makefiles > > Did you test mod_md? If I remove the apache/md directory httpd 2.4.39 > creates certificates, first in md/staging then in md/domains. > httpd 2.4.40 fails. > > No config changes. VC9 x86 OpenSSL 1.0.2, if that matters. Both 2.4.39 > and 2.4.40 were compiled today. > > I will test later on with VC15 x64 OpenSSL 1.1.1. > -- > Jan >
Re: changelog mod_md ssl patch
As Rainer said. This should have been removed after the mod_ssl backport. > Am 03.08.2019 um 13:00 schrieb Rainer Jung : > > Hi Steffen, > > Am 03.08.2019 um 12:36 schrieb Steffen: >> Changelog says mod_ssl needs patch. >> That is a typo or where is the patch. >> *) mod_md: new features >> - supports the ACMEv2 protocol >> - new challenge method 'tls-alpn-01' implemented, needs mod_ssl patch to >> become available > > I would say it's conatined in: > > *) mod_ssl/mod_md: reversing dependency by letting mod_ssl offer hooks for > adding certificates and keys to a virtual host. An additional hook allows > answering special TLS connections as used in ACME challenges. > Adding 2 new hooks for init/get of OCSP stapling status information when > other modules want to provide those. Falls back to own implementation with > same behaviour as before. > [Stefan Eissing] > > especially in "An additional hook allows answering special TLS connections as > used in ACME challenges.". > > The refence to a needed mod_ssl patch is a bit hard tu understand here and > probably had a historical reason, before that patch actually got applied to > mod_ssl (and if you are using mod_md from github and mod_ssl is older). > > Regards, > > Rainer
