Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
On 2015-06-16 13:39, Yann Ylavic wrote: On Mon, Jun 15, 2015 at 7:24 PM, olli hauer oha...@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)
On Mon, Jun 15, 2015 at 7:24 PM, olli hauer oha...@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
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 j...@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 noel.but...@ausics.net wrote: On 15/06/2015 07:56, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith g...@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
Well, we have time now to Do This Right in 2.4.15, so On Jun 14, 2015, at 9:43 PM, Noel Butler noel.but...@ausics.net wrote: On 15/06/2015 07:56, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith g...@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
On Jun 15, 2015, at 9:12 AM, Eric Covener cove...@gmail.com wrote: Anyone else inclined to just remove the message? I'm +1 for that.
Re: SSLCertificateChainFile deprecation, still
On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener cove...@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
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 cove...@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
On 15 June 2015 14:12:27 UTC+01:00, Eric Covener cove...@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 – is...@c8h10n4o2.org.uk
Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
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 Smithg...@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
On Mon, Jun 15, 2015 at 11:10 AM, Jeff Trawick traw...@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 cove...@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 (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
On 6/14/2015 2:54 AM, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 11:29 AM,gsm...@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=1685371r1=1685370r2=1685371view=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
SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)
On Sun, Jun 14, 2015 at 11:29 AM, gsm...@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=1685371r1=1685370r2=1685371view=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)
On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith g...@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)
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 Smithg...@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
On 15/06/2015 07:56, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith g...@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)
On 6/14/2015 2:56 PM, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smithg...@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.
