You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Yann Ylavic <yl...@gmail.com> on 2015/06/14 11:54:16 UTC
SSLCertificateChainFile deprecation, still (was: svn commit: r1685371
- /httpd/httpd/branches/2.4.x/STATUS)
On Sun, Jun 14, 2015 at 11:29 AM, <gs...@apache.org> wrote:
> Author: gsmith
> Date: Sun Jun 14 09:29:50 2015
> New Revision: 1685371
>
> URL: http://svn.apache.org/r1685371
> Log:
> -1 vote w/ comment
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1685371&r1=1685370&r2=1685371&view=diff
> ==============================================================================
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Sun Jun 14 09:29:50 2015
> @@ -207,6 +207,8 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
> 2.4.x patch: http://people.apache.org/~ylavic/httpd-2.4.x-deprecated_SSLCertificateChainFile_once.patch
> trunk works (modulo CHANGES, above is a review patch only)
> +1: ylavic, trawick
> + -1: gsmith, Tested, don't work! APLOG_INFO|APLOG_STARTUP will not work
> + together. Similar APLOG_* caveat as APLOG_TOCLIENT.
Indeed...
So, AIUI, it won't be logged unless httpd is started with -e info or more.
Isn't that finally what we want since [warn] seems to high?
Re: SSLCertificateChainFile deprecation, still (was: svn commit:
r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
Posted by olli hauer <oh...@gmx.de>.
On 2015-06-16 13:39, Yann Ylavic wrote:
> On Mon, Jun 15, 2015 at 7:24 PM, olli hauer <oh...@gmx.de> wrote:
>>
>> As a side note, even I've read the Release Notes I was thankful to see my console was trashed with the deprecation warning ;)
>>
>> What I miss is a section on httpd.apache.org/docs/2.4/ with a link list what has changed since which release.
>> For example there are section "New features with Apache .." and "Upgrading to 2.4 from 2.2" but no section like
>>
>> Deprecated / Important changes between 2.4.x and 2.4.y
>> - mod_cgi: use of the magic mime-type is deprecated
>> - mod_ssl: SSLCertificateChainFile is deprecated
>> SSLRequire is deprecated
>> - mod_ldap: (ldaps://) support has been deprecated to be replaced with TLS
>> - mod_access_compat: deprecated by the new authz refactoring
>> - ...
>>
>>
>> I'm really not a good technical writer, but if such a list is welcome I will try to do my best to send a patch
>
> A patch for a dedicated section or a sub one in "Upgrading to 2.4 from
> 2.2" in very welcome ;)
>
OK, will try, but it will take some time, I think extending the misc section can be a good place.
Should I also note doc changes only existing in 2.4.x and not in trunk like r1485752?
Re: SSLCertificateChainFile deprecation, still (was: svn commit:
r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Jun 15, 2015 at 7:24 PM, olli hauer <oh...@gmx.de> wrote:
>
> As a side note, even I've read the Release Notes I was thankful to see my console was trashed with the deprecation warning ;)
>
> What I miss is a section on httpd.apache.org/docs/2.4/ with a link list what has changed since which release.
> For example there are section "New features with Apache .." and "Upgrading to 2.4 from 2.2" but no section like
>
> Deprecated / Important changes between 2.4.x and 2.4.y
> - mod_cgi: use of the magic mime-type is deprecated
> - mod_ssl: SSLCertificateChainFile is deprecated
> SSLRequire is deprecated
> - mod_ldap: (ldaps://) support has been deprecated to be replaced with TLS
> - mod_access_compat: deprecated by the new authz refactoring
> - ...
>
>
> I'm really not a good technical writer, but if such a list is welcome I will try to do my best to send a patch
A patch for a dedicated section or a sub one in "Upgrading to 2.4 from
2.2" in very welcome ;)
Re: SSLCertificateChainFile deprecation, still (was: svn commit:
r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
Posted by olli hauer <oh...@gmx.de>.
On 2015-06-15 03:36, Gregg Smith wrote:
> On 6/14/2015 6:14 PM, Gregg Smith wrote:
>> On 6/14/2015 2:56 PM, 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...
>>
>> It's a lose/lose situation either way. I didn't pick up on the startup monitors part of the thread.
>>
>> We are almost back to the way it was before the warning, I guess this is fine. No will know the better unless they go fishing for some other problem that may arise. At the very minimum it's something at least, should not make waves and i would bet everyone knows about it now unless 2.4.15 is their first.
>
> If this is their first, probably ought to remove this in httpd-ssl.conf also
>
> # Server Certificate Chain:
> # Point SSLCertificateChainFile at a file containing the
> # concatenation of PEM encoded CA certificates which form the
> # certificate chain for the server certificate. Alternatively
> # the referenced file can be the same as SSLCertificateFile
> # when the CA certificates are directly appended to the server
> # certificate for convenience.
> #SSLCertificateChainFile "@rel_sysconfdir@/server-ca.crt"
>
It is a valid statement, so I think it would be better to keep it and replace the description with something like
# This directive is deprecated, please concatenate the
# intermediate CA to the SSLCertificateFile.
#SSLCertificateChainFile "@rel_sysconfdir@/server-ca.crt"
As a side note, even I've read the Release Notes I was thankful to see my console was trashed with the deprecation warning ;)
What I miss is a section on httpd.apache.org/docs/2.4/ with a link list what has changed since which release.
For example there are section "New features with Apache .." and "Upgrading to 2.4 from 2.2" but no section like
Deprecated / Important changes between 2.4.x and 2.4.y
- mod_cgi: use of the magic mime-type is deprecated
- mod_ssl: SSLCertificateChainFile is deprecated
SSLRequire is deprecated
- mod_ldap: (ldaps://) support has been deprecated to be replaced with TLS
- mod_access_compat: deprecated by the new authz refactoring
- ...
I'm really not a good technical writer, but if such a list is welcome I will try to do my best to send a patch
Re: SSLCertificateChainFile deprecation, still (was: svn commit:
r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
Posted by Gregg Smith <gl...@gknw.net>.
On 6/14/2015 6:14 PM, Gregg Smith wrote:
> On 6/14/2015 2:56 PM, 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...
>
> It's a lose/lose situation either way. I didn't pick up on the startup
> monitors part of the thread.
>
> We are almost back to the way it was before the warning, I guess this
> is fine. No will know the better unless they go fishing for some other
> problem that may arise. At the very minimum it's something at least,
> should not make waves and i would bet everyone knows about it now
> unless 2.4.15 is their first.
If this is their first, probably ought to remove this in httpd-ssl.conf also
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convenience.
#SSLCertificateChainFile "@rel_sysconfdir@/server-ca.crt"
Re: SSLCertificateChainFile deprecation, still (was: svn commit:
r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
Posted by Gregg Smith <gl...@gknw.net>.
On 6/14/2015 2:56 PM, 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...
It's a lose/lose situation either way. I didn't pick up on the startup
monitors part of the thread.
We are almost back to the way it was before the warning, I guess this is
fine. No will know the better unless they go fishing for some other
problem that may arise. At the very minimum it's something at least,
should not make waves and i would bet everyone knows about it now unless
2.4.15 is their first.
You have my vote, sorry for the trouble.
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.
>
>
Re: SSLCertificateChainFile deprecation, still
Posted by Noel Butler <no...@ausics.net>.
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 (was: svn commit:
r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
Posted by Yann Ylavic <yl...@gmail.com>.
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...
Re: SSLCertificateChainFile deprecation, still (was: svn commit:
r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
Posted by Gregg Smith <gl...@gknw.net>.
On 6/14/2015 2:54 AM, Yann Ylavic wrote:
> On Sun, Jun 14, 2015 at 11:29 AM,<gs...@apache.org> wrote:
>> Author: gsmith
>> Date: Sun Jun 14 09:29:50 2015
>> New Revision: 1685371
>>
>> URL: http://svn.apache.org/r1685371
>> Log:
>> -1 vote w/ comment
>>
>> Modified:
>> httpd/httpd/branches/2.4.x/STATUS
>>
>> Modified: httpd/httpd/branches/2.4.x/STATUS
>> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1685371&r1=1685370&r2=1685371&view=diff
>> ==============================================================================
>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>> +++ httpd/httpd/branches/2.4.x/STATUS Sun Jun 14 09:29:50 2015
>> @@ -207,6 +207,8 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>> 2.4.x patch: http://people.apache.org/~ylavic/httpd-2.4.x-deprecated_SSLCertificateChainFile_once.patch
>> trunk works (modulo CHANGES, above is a review patch only)
>> +1: ylavic, trawick
>> + -1: gsmith, Tested, don't work! APLOG_INFO|APLOG_STARTUP will not work
>> + together. Similar APLOG_* caveat as APLOG_TOCLIENT.
> Indeed...
> So, AIUI, it won't be logged unless httpd is started with -e info or more.
> Isn't that finally what we want since [warn] seems to high?
Ok, yes that does work, this has been a day of learning.
However doing so I think the original intent is now lost which is to
inform the user of SSLCertificateChainFile's deprecation. The
unfortunate result of which was the hundreds/thousands of warnings 3
times over on servers with many ssl hosts. At least I got it three times
per host, but I only have a few. It also didn't take a -e warn to get it.
Now however should I want to follow up and use -e info, it's a game of
what-a-mole cause it will only tell me the first place in my config it's
at, not all of them. So essentially I would have to fix one, start again
with -e to find the next. Let's assume I don't have search & replace or
have included many conf files and do not have find in files at my disposal.
I think we can do both, not require a -e and simply inform the user
(just once at startup) of SSLCertificateChainFile's deprecation and then
give them list with -e info should they care to follow up on it.
I have reverted my -1 and will move out of the way. 2.4.14 is kaput with
the chunk size regression so we have a small window.
As my day must end now, this is untested. But wouldn't this be a
compromise to both? They will normally be gently informed (once) but -e
info will inundated them with every line in every file they are using
SSLCertificateChainFile in. In this case at lease they have requested it.
http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff