You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Noel Butler <no...@ausics.net> on 2015/06/15 03:43:49 UTC
Re: SSLCertificateChainFile deprecation, still
On 15/06/2015 07:56, Yann Ylavic wrote:
> On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith <gl...@gknw.net> wrote:
>
>> http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff [1]
>
> I'm fine with this approach too.
> We have to decide whether a single [warn] is acceptable or not since
> it may still confuse startup monitors, which was a point raised in the
> [Vote] thread.
> I agree that the current patch proposed in STATUS is nearly the same
> as not noticing the user since it requires -e info in the command-line
> for anything to be visible, but I'm afraid any warning won't be
> accepted now...
A Single warn to LOG is good, perhaps even a single warn to console on
daemon START only - and only if this means it does NOT appear in any
reloads or ever again until the server is stop/started, if it does,
abandon the idea.
Not sure if the single console warn on START will affect cpanel, I don't
think it would since it likely part of system startup and no scripting
would be looking for any output, Jacob might want to chime in on that
one though.
Links:
------
[1]
http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff
Re: SSLCertificateChainFile deprecation, still
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jun 15, 2015, at 9:12 AM, Eric Covener <co...@gmail.com> wrote:
>
> Anyone else inclined to just remove the message?
I'm +1 for that.
Re: SSLCertificateChainFile deprecation, still
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Jun 15, 2015 at 11:10 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Mon, Jun 15, 2015 at 10:54 AM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>
>> On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener <co...@gmail.com> wrote:
>>
>>> Anyone else inclined to just remove the message? It's a deprecation that
>>> didn't happen on a release boundary. AFAICT there's no reason to change how
>>> you run your server unless you use two different cert chains and then you'd
>>> find the info in the manual.
>>>
>>
>> +1, this is highly irregular. Our general statement is that config
>> changes are not strictly necessary on subversion updates of httpd.
>> (Securing your SSLCipherList notwithstanding.)
>>
>> Bill
>>
>
> +1, but IMO the whole idea should be revisited.
>
> Storing intermediate certificates separately is a problem when you have
> multiple certificates with different algorithms. (Which server cert(s)
> do/does the intermediate cert file go with?)
>
> For cases where there's no ambiguity, we have a trade-off between
>
> 1) being able to get rid of the directive since the intermediate certs
> don't necessarily need to be stored separately
> 2) a future migration headache, if not nightmare, for sites with many
> vhosts where different users manage the certs
>
> We need to favor #2.
>
> For cases where there is an ambiguity, we should deprecate being able to
> configure that, and visibly warn that there's a likely problem ASAP.
>
well, "a likely problem" can't be right, unless they just configured it and
it doesn't work correctly yet :)
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: SSLCertificateChainFile deprecation, still
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Jun 15, 2015 at 10:54 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener <co...@gmail.com> wrote:
>
>> Anyone else inclined to just remove the message? It's a deprecation that
>> didn't happen on a release boundary. AFAICT there's no reason to change how
>> you run your server unless you use two different cert chains and then you'd
>> find the info in the manual.
>>
>
> +1, this is highly irregular. Our general statement is that config
> changes are not strictly necessary on subversion updates of httpd.
> (Securing your SSLCipherList notwithstanding.)
>
> Bill
>
+1, but IMO the whole idea should be revisited.
Storing intermediate certificates separately is a problem when you have
multiple certificates with different algorithms. (Which server cert(s)
do/does the intermediate cert file go with?)
For cases where there's no ambiguity, we have a trade-off between
1) being able to get rid of the directive since the intermediate certs
don't necessarily need to be stored separately
2) a future migration headache, if not nightmare, for sites with many
vhosts where different users manage the certs
We need to favor #2.
For cases where there is an ambiguity, we should deprecate being able to
configure that, and visibly warn that there's a likely problem ASAP.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: SSLCertificateChainFile deprecation, still
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener <co...@gmail.com> wrote:
> Anyone else inclined to just remove the message? It's a deprecation that
> didn't happen on a release boundary. AFAICT there's no reason to change how
> you run your server unless you use two different cert chains and then you'd
> find the info in the manual.
>
+1, this is highly irregular. Our general statement is that config changes
are not strictly necessary on subversion updates of httpd. (Securing your
SSLCipherList notwithstanding.)
Bill
Re: SSLCertificateChainFile deprecation, still
Posted by Tim Bannister <is...@c8h10n4o2.org.uk>.
On 15 June 2015 14:12:27 UTC+01:00, Eric Covener <co...@gmail.com> wrote:
>Anyone else inclined to just remove the message? It's a deprecation
>that didn't happen on a release boundary. AFAICT there's no reason to change
>how you run your server unless you use two different cert chains and then
>you'd find the info in the manual.
I think that suggestion is a good approach if the SSLCertificateChainFile directive can remain available for the full lifespan of 2.4.x
--
Tim Bannister – isoma@c8h10n4o2.org.uk
Re: SSLCertificateChainFile deprecation, still
Posted by Eric Covener <co...@gmail.com>.
Anyone else inclined to just remove the message? It's a deprecation that
didn't happen on a release boundary. AFAICT there's no reason to change how
you run your server unless you use two different cert chains and then you'd
find the info in the manual.
On Mon, Jun 15, 2015 at 8:57 AM Jim Jagielski <ji...@jagunet.com> wrote:
> Well, we have time now to Do This Right in 2.4.15, so....
>
> > On Jun 14, 2015, at 9:43 PM, Noel Butler <no...@ausics.net> wrote:
> >
> > On 15/06/2015 07:56, Yann Ylavic wrote:
> >
> >> On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith <gl...@gknw.net> wrote:
> >>>
> >>>
> http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff
> >>
> >> I'm fine with this approach too.
> >> We have to decide whether a single [warn] is acceptable or not since
> >> it may still confuse startup monitors, which was a point raised in the
> >> [Vote] thread.
> >> I agree that the current patch proposed in STATUS is nearly the same
> >> as not noticing the user since it requires -e info in the command-line
> >> for anything to be visible, but I'm afraid any warning won't be
> >> accepted now...
> >
> > A Single warn to LOG is good, perhaps even a single warn to console on
> daemon START only - and only if this means it does NOT appear in any
> reloads or ever again until the server is stop/started, if it does, abandon
> the idea.
> >
> > Not sure if the single console warn on START will affect cpanel, I don't
> think it would since it likely part of system startup and no scripting
> would be looking for any output, Jacob might want to chime in on that one
> though.
> >
> >
>
>
Re: SSLCertificateChainFile deprecation, still
Posted by Jim Jagielski <ji...@jaguNET.com>.
Well, we have time now to Do This Right in 2.4.15, so....
> On Jun 14, 2015, at 9:43 PM, Noel Butler <no...@ausics.net> wrote:
>
> On 15/06/2015 07:56, Yann Ylavic wrote:
>
>> On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith <gl...@gknw.net> wrote:
>>>
>>> http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff
>>
>> I'm fine with this approach too.
>> We have to decide whether a single [warn] is acceptable or not since
>> it may still confuse startup monitors, which was a point raised in the
>> [Vote] thread.
>> I agree that the current patch proposed in STATUS is nearly the same
>> as not noticing the user since it requires -e info in the command-line
>> for anything to be visible, but I'm afraid any warning won't be
>> accepted now...
>
> A Single warn to LOG is good, perhaps even a single warn to console on daemon START only - and only if this means it does NOT appear in any reloads or ever again until the server is stop/started, if it does, abandon the idea.
>
> Not sure if the single console warn on START will affect cpanel, I don't think it would since it likely part of system startup and no scripting would be looking for any output, Jacob might want to chime in on that one though.
>
>