You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Frank Meier <fr...@ergon.ch> on 2018/07/18 08:19:30 UTC
ocsp_force_default initialized with UNSET in httpd 2.4.34
We experience a problem with OCSP since Apache HTTP Server 2.4.34.
Certificates, which do include a OCSP responder URL and worked well with
2.4.33 are now reported that they don't. Log Message: "AH01918: no OCSP
responder specified in certificate and no default configured".
After git bisect I found the commit which introduced this behaviour [1].
And more more precisely the line in "ssl_engine_config.c" where
"ocsp_force_default" is initialized with "UNSET" where in 2.4.33 it was
initialized with "FALSE". This is a problem, because
"ocsp_force_default" is used in a if condition without comparison
operator in ssl_engine_ocsp.c:64, therefore resulting in TRUE even it is
UNSET.
I propose 2 ways of fixing this. Either let the initialization be like
in 2.4.33 (ocsp-fix.patch) or compare the "ocsp_force_default" flag with
"TRUE" where it is used (ocsp-fix2.patch).
[1]
https://github.com/apache/httpd/commit/7c64b2e46820d5d7576d9f601142cd33c5c8c42b
Cheers, Frank
Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Ruediger Pluem <rp...@apache.org>.
On 07/18/2018 10:19 AM, Frank Meier wrote:
> We experience a problem with OCSP since Apache HTTP Server 2.4.34. Certificates, which do include a OCSP responder URL
> and worked well with 2.4.33 are now reported that they don't. Log Message: "AH01918: no OCSP responder specified in
> certificate and no default configured".
>
> After git bisect I found the commit which introduced this behaviour [1]. And more more precisely the line in
> "ssl_engine_config.c" where "ocsp_force_default" is initialized with "UNSET" where in 2.4.33 it was initialized with
> "FALSE". This is a problem, because "ocsp_force_default" is used in a if condition without comparison operator in
> ssl_engine_ocsp.c:64, therefore resulting in TRUE even it is UNSET.
>
> I propose 2 ways of fixing this. Either let the initialization be like in 2.4.33 (ocsp-fix.patch) or compare the
> "ocsp_force_default" flag with "TRUE" where it is used (ocsp-fix2.patch).
Stefan do you remember why the default for ocsp_force_default has changed to UNSET? If not I would go for the first patch.
Regards
Rüdiger
>
> [1] https://github.com/apache/httpd/commit/7c64b2e46820d5d7576d9f601142cd33c5c8c42b
>
> Cheers, Frank
Re: AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Ruediger Pluem <rp...@apache.org>.
Proposed for backport as r1836334.
Regards
Rüdiger
On 07/19/2018 11:23 AM, Plüm, Rüdiger, Vodafone Group wrote:
> I can do tomorrow and make a proposal in STATUS. Looks like we are all aligned now how to resolve this.
>
> Regards
>
> Rüdiger
>
>> -----Ursprüngliche Nachricht-----
>> Von: Stefan Eissing <st...@greenbytes.de>
>> Gesendet: Donnerstag, 19. Juli 2018 11:10
>> An: dev@httpd.apache.org
>> Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
>>
>> You'll take care of it, Rüdiger?
>>
>>> Am 18.07.2018 um 13:57 schrieb Ruediger Pluem <rp...@apache.org>:
>>>
>>>
>>>
>>> On 07/18/2018 11:44 AM, Stefan Eissing wrote:
>>>>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic <yl...@gmail.com>:
>>>>>
>>>>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem <rp...@apache.org>
>> wrote:
>>>>>>
>>>>>> Good catch. Maybe a dirty working copy during backport? Yann?
>>>>>
>>>>> Actually the change was in the proposed patch:
>>>>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-
>> enable-leaf.patch
>>>>> A subtle difference between trunk and 2.4.x, around the change...
>>>>
>>>> Hmm, so I had the dirty working dir when creating the patch? I do not
>> remember messing with that setting, but obviously I was mistaken in
>> doing it.
>>>>
>>>> So, patch 1 it is then, Rainer?
>>>>
>>>
>>> I changed my mind :-) Let's backport r1555631 from trunk which is more
>> or less patch 2. So we have aligned trunk and
>>> 2.4.x here. r1555631 does not apply clean though, because r1826995,
>> r1827001 are already backported, but this is fixable.
>>>
>>> Regards
>>>
>>> Rüdiger
>
AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
I can do tomorrow and make a proposal in STATUS. Looks like we are all aligned now how to resolve this.
Regards
Rüdiger
> -----Ursprüngliche Nachricht-----
> Von: Stefan Eissing <st...@greenbytes.de>
> Gesendet: Donnerstag, 19. Juli 2018 11:10
> An: dev@httpd.apache.org
> Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
>
> You'll take care of it, Rüdiger?
>
> > Am 18.07.2018 um 13:57 schrieb Ruediger Pluem <rp...@apache.org>:
> >
> >
> >
> > On 07/18/2018 11:44 AM, Stefan Eissing wrote:
> >>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic <yl...@gmail.com>:
> >>>
> >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem <rp...@apache.org>
> wrote:
> >>>>
> >>>> Good catch. Maybe a dirty working copy during backport? Yann?
> >>>
> >>> Actually the change was in the proposed patch:
> >>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-
> enable-leaf.patch
> >>> A subtle difference between trunk and 2.4.x, around the change...
> >>
> >> Hmm, so I had the dirty working dir when creating the patch? I do not
> remember messing with that setting, but obviously I was mistaken in
> doing it.
> >>
> >> So, patch 1 it is then, Rainer?
> >>
> >
> > I changed my mind :-) Let's backport r1555631 from trunk which is more
> or less patch 2. So we have aligned trunk and
> > 2.4.x here. r1555631 does not apply clean though, because r1826995,
> r1827001 are already backported, but this is fixable.
> >
> > Regards
> >
> > Rüdiger
Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Stefan Eissing <st...@greenbytes.de>.
You'll take care of it, Rüdiger?
> Am 18.07.2018 um 13:57 schrieb Ruediger Pluem <rp...@apache.org>:
>
>
>
> On 07/18/2018 11:44 AM, Stefan Eissing wrote:
>>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic <yl...@gmail.com>:
>>>
>>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem <rp...@apache.org> wrote:
>>>>
>>>> Good catch. Maybe a dirty working copy during backport? Yann?
>>>
>>> Actually the change was in the proposed patch:
>>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-enable-leaf.patch
>>> A subtle difference between trunk and 2.4.x, around the change...
>>
>> Hmm, so I had the dirty working dir when creating the patch? I do not remember messing with that setting, but obviously I was mistaken in doing it.
>>
>> So, patch 1 it is then, Rainer?
>>
>
> I changed my mind :-) Let's backport r1555631 from trunk which is more or less patch 2. So we have aligned trunk and
> 2.4.x here. r1555631 does not apply clean though, because r1826995, r1827001 are already backported, but this is fixable.
>
> Regards
>
> Rüdiger
Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Stefan Eissing <st...@greenbytes.de>.
Thanks!
> Am 23.07.2018 um 11:27 schrieb Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>:
>
>
AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
Wrong revision. Correct one is r1836472.
Regards
Rüdiger
> -----Ursprüngliche Nachricht-----
> Von: Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>
> Gesendet: Montag, 23. Juli 2018 11:26
> An: dev@httpd.apache.org
> Betreff: AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
>
> This is now backported to 2.4.x as r1555631 and will be part of the next
> release.
>
> Regards
>
> Rüdiger
>
> > -----Ursprüngliche Nachricht-----
> > Von: Frank Meier <fr...@ergon.ch>
> > Gesendet: Freitag, 20. Juli 2018 09:26
> > An: dev@httpd.apache.org
> > Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
> >
> >
> > On 18/07/18 13:57, Ruediger Pluem wrote:
> > >
> > > On 07/18/2018 11:44 AM, Stefan Eissing wrote:
> > >>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic <yl...@gmail.com>:
> > >>>
> > >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem
> <rp...@apache.org>
> > wrote:
> > >>>> Good catch. Maybe a dirty working copy during backport? Yann?
> > >>> Actually the change was in the proposed patch:
> > >>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-
> ocsp-
> > enable-leaf.patch
> > >>> A subtle difference between trunk and 2.4.x, around the change...
> > >> Hmm, so I had the dirty working dir when creating the patch? I do
> not
> > remember messing with that setting, but obviously I was mistaken in
> > doing it.
> > >>
> > >> So, patch 1 it is then, Rainer?
> > >>
> > > I changed my mind :-) Let's backport r1555631 from trunk which is
> more
> > or less patch 2. So we have aligned trunk and
> > > 2.4.x here. r1555631 does not apply clean though, because r1826995,
> > r1827001 are already backported, but this is fixable.
> > >
> > > Regards
> > >
> > > Rüdiger
> > Thanks Guys, so we will run with patch 2. For now.
> > Just for other people to know if they hit this issue with 2.4.34 and
> are
> > not able to patch, there is a workaround: Explicitly setting the
> > directive "SSLOCSPOverrideResponder" to "off" in the configuration
> file
> > does also "fix" the issue.
> >
> > Cheers, Frank
AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
This is now backported to 2.4.x as r1555631 and will be part of the next release.
Regards
Rüdiger
> -----Ursprüngliche Nachricht-----
> Von: Frank Meier <fr...@ergon.ch>
> Gesendet: Freitag, 20. Juli 2018 09:26
> An: dev@httpd.apache.org
> Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
>
>
> On 18/07/18 13:57, Ruediger Pluem wrote:
> >
> > On 07/18/2018 11:44 AM, Stefan Eissing wrote:
> >>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic <yl...@gmail.com>:
> >>>
> >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem <rp...@apache.org>
> wrote:
> >>>> Good catch. Maybe a dirty working copy during backport? Yann?
> >>> Actually the change was in the proposed patch:
> >>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-
> enable-leaf.patch
> >>> A subtle difference between trunk and 2.4.x, around the change...
> >> Hmm, so I had the dirty working dir when creating the patch? I do not
> remember messing with that setting, but obviously I was mistaken in
> doing it.
> >>
> >> So, patch 1 it is then, Rainer?
> >>
> > I changed my mind :-) Let's backport r1555631 from trunk which is more
> or less patch 2. So we have aligned trunk and
> > 2.4.x here. r1555631 does not apply clean though, because r1826995,
> r1827001 are already backported, but this is fixable.
> >
> > Regards
> >
> > Rüdiger
> Thanks Guys, so we will run with patch 2. For now.
> Just for other people to know if they hit this issue with 2.4.34 and are
> not able to patch, there is a workaround: Explicitly setting the
> directive "SSLOCSPOverrideResponder" to "off" in the configuration file
> does also "fix" the issue.
>
> Cheers, Frank
Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Frank Meier <fr...@ergon.ch>.
On 18/07/18 13:57, Ruediger Pluem wrote:
>
> On 07/18/2018 11:44 AM, Stefan Eissing wrote:
>>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic <yl...@gmail.com>:
>>>
>>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem <rp...@apache.org> wrote:
>>>> Good catch. Maybe a dirty working copy during backport? Yann?
>>> Actually the change was in the proposed patch:
>>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-enable-leaf.patch
>>> A subtle difference between trunk and 2.4.x, around the change...
>> Hmm, so I had the dirty working dir when creating the patch? I do not remember messing with that setting, but obviously I was mistaken in doing it.
>>
>> So, patch 1 it is then, Rainer?
>>
> I changed my mind :-) Let's backport r1555631 from trunk which is more or less patch 2. So we have aligned trunk and
> 2.4.x here. r1555631 does not apply clean though, because r1826995, r1827001 are already backported, but this is fixable.
>
> Regards
>
> Rüdiger
Thanks Guys, so we will run with patch 2. For now.
Just for other people to know if they hit this issue with 2.4.34 and are
not able to patch, there is a workaround: Explicitly setting the
directive "SSLOCSPOverrideResponder" to "off" in the configuration file
does also "fix" the issue.
Cheers, Frank
Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Ruediger Pluem <rp...@apache.org>.
On 07/18/2018 11:44 AM, Stefan Eissing wrote:
>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic <yl...@gmail.com>:
>>
>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem <rp...@apache.org> wrote:
>>>
>>> Good catch. Maybe a dirty working copy during backport? Yann?
>>
>> Actually the change was in the proposed patch:
>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-enable-leaf.patch
>> A subtle difference between trunk and 2.4.x, around the change...
>
> Hmm, so I had the dirty working dir when creating the patch? I do not remember messing with that setting, but obviously I was mistaken in doing it.
>
> So, patch 1 it is then, Rainer?
>
I changed my mind :-) Let's backport r1555631 from trunk which is more or less patch 2. So we have aligned trunk and
2.4.x here. r1555631 does not apply clean though, because r1826995, r1827001 are already backported, but this is fixable.
Regards
Rüdiger
Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 18.07.2018 um 11:37 schrieb Yann Ylavic <yl...@gmail.com>:
>
> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem <rp...@apache.org> wrote:
>>
>> Good catch. Maybe a dirty working copy during backport? Yann?
>
> Actually the change was in the proposed patch:
> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-enable-leaf.patch
> A subtle difference between trunk and 2.4.x, around the change...
Hmm, so I had the dirty working dir when creating the patch? I do not remember messing with that setting, but obviously I was mistaken in doing it.
So, patch 1 it is then, Rainer?
Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem <rp...@apache.org> wrote:
>
> Good catch. Maybe a dirty working copy during backport? Yann?
Actually the change was in the proposed patch:
https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-enable-leaf.patch
A subtle difference between trunk and 2.4.x, around the change...
Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Ruediger Pluem <rp...@apache.org>.
On 07/18/2018 11:04 AM, Stefan Eissing wrote:
> It looks as if that was added when ylavic backported?
>
> r1834089 has the change, but is supposed to be a merge of r1826995, r1827001 where this change is not present? (If i read that correctly).
>
Good catch. Maybe a dirty working copy during backport? Yann?
Regards
Rüdiger
>> Am 18.07.2018 um 10:19 schrieb Frank Meier <fr...@ergon.ch>:
>>
>> We experience a problem with OCSP since Apache HTTP Server 2.4.34. Certificates, which do include a OCSP responder URL and worked well with 2.4.33 are now reported that they don't. Log Message: "AH01918: no OCSP responder specified in certificate and no default configured".
>>
>> After git bisect I found the commit which introduced this behaviour [1]. And more more precisely the line in "ssl_engine_config.c" where "ocsp_force_default" is initialized with "UNSET" where in 2.4.33 it was initialized with "FALSE". This is a problem, because "ocsp_force_default" is used in a if condition without comparison operator in ssl_engine_ocsp.c:64, therefore resulting in TRUE even it is UNSET.
>>
>> I propose 2 ways of fixing this. Either let the initialization be like in 2.4.33 (ocsp-fix.patch) or compare the "ocsp_force_default" flag with "TRUE" where it is used (ocsp-fix2.patch).
>>
>> [1] https://github.com/apache/httpd/commit/7c64b2e46820d5d7576d9f601142cd33c5c8c42b
>>
>> Cheers, Frank
>> <ocsp-fix.patch><ocsp-fix2.patch>
>
>
Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
Posted by Stefan Eissing <st...@greenbytes.de>.
It looks as if that was added when ylavic backported?
r1834089 has the change, but is supposed to be a merge of r1826995, r1827001 where this change is not present? (If i read that correctly).
> Am 18.07.2018 um 10:19 schrieb Frank Meier <fr...@ergon.ch>:
>
> We experience a problem with OCSP since Apache HTTP Server 2.4.34. Certificates, which do include a OCSP responder URL and worked well with 2.4.33 are now reported that they don't. Log Message: "AH01918: no OCSP responder specified in certificate and no default configured".
>
> After git bisect I found the commit which introduced this behaviour [1]. And more more precisely the line in "ssl_engine_config.c" where "ocsp_force_default" is initialized with "UNSET" where in 2.4.33 it was initialized with "FALSE". This is a problem, because "ocsp_force_default" is used in a if condition without comparison operator in ssl_engine_ocsp.c:64, therefore resulting in TRUE even it is UNSET.
>
> I propose 2 ways of fixing this. Either let the initialization be like in 2.4.33 (ocsp-fix.patch) or compare the "ocsp_force_default" flag with "TRUE" where it is used (ocsp-fix2.patch).
>
> [1] https://github.com/apache/httpd/commit/7c64b2e46820d5d7576d9f601142cd33c5c8c42b
>
> Cheers, Frank
> <ocsp-fix.patch><ocsp-fix2.patch>