Aw: Re: [users@httpd] Newer Apache does not offer TLS cipher with TLSv1 anymore

[Hildegard Meier]

Thanks for your answer, Stefan.

So I would suggest to make the documentation of SSLProtocol clear like this:

"
You need to name the 'highest' protocol and the 'lowest' protocol, and all 
protocols in between them, without gap.

E.g. if You want to support TLSv1.2 and TLSv1.0, you need to set

SSLProtocol -all +TLSv1.2 +TLSv1.1 +TLSv1

If you would only set

SSLProtocol -all +TLSv1.2 +TLSv1

Apache would stop at TLSv1.2 because there is a gap in the protocol list, and 
only support TLSv1.2

If you only want to support TLSv1.2, you would set

SSLProtocol TLSv1.2
"

I mean, this is weird, but if it is really like so, you should be brave and 
document this weirdness like it is, or fix it.

How could the useres figure this behaviour out otherwise? It took me hours to 
find the solution, and only by guessing and trying.


> I believe this is the result of a deliberate change in the OpenSSL API when 
> going to version 1.1.0.
>
> In earlier versions of OpenSSL one could switch on/off individual protocols, 
> whereas now one specifies a minimum and maximum TLS version to use.
>
> In Apache, the configuration handling needed to accomodate for that and the 
> implementation looks for the "highest" protocol and then scans "downward". If 
> a protocol is not listed, it basically stops. I am not sure why this decision 
> was taken, but it seems that one wanted to avoid enabling a protocol that was 
> not configured.
>


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: [users@httpd] Newer Apache does not offer TLS cipher with TLSv1 anymore

[Hildegard Meier]

Solution to have TLSv1.2 and TLSv1.0 support together again with Apache 2.4.29 
on Ubuntu 18:

Changing

SSLProtocol -all +TLSv1.2 +TLSv1

to

SSLProtocol -all +TLSv1.2 +TLSv1.1 +TLSv1

This gives the following sslscan output:

  Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384 DHE 2048 bits
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  AES256-SHA
Preferred TLSv1.1  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256
Accepted  TLSv1.1  256 bits  AES256-SHA
Preferred TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256
Accepted  TLSv1.0  256 bits  AES256-SHA

and connection with all three protocols with curl works, also from the old 
client which is not TLSv1.2 capable.

But I want only to allow TLSv1.2 and TLSv1.0, TLSv1.1 is not needed, so I do 
not want to allow it.

By luck, I found this Apache bug report about chaotic behaviour resulting from 
different combinations of options SSLProtocol and SSLCipherSuite:

https://bz.apache.org/bugzilla/show_bug.cgi?id=60739

This is really scary: Undocumented change of behaviour, behaviour that is not 
reasonable/logic, nearly zero documentation of option SSLProtocol.

Any explanation by the Apache devs, why
SSLProtocol -all +TLSv1.2 +TLSv1
did work with Apache 2.4.7 on Ubuntu 14

but with Apache 2.4.29 on Ubuntu 18 one has to set
SSLProtocol -all +TLSv1.2 +TLSv1.1 +TLSv1
to get TLSv1.0 protocol support?

Any suggestion how I can have TLSv1.2 and TLSv1.0 support, but no TLSv1.1 
support at the same time?


> Gesendet: Mittwoch, 02. Juni 2021 um 17:29 Uhr
> Von: "Hildegard Meier" 
> An: users@httpd.apache.org
> Betreff: [users@httpd] Newer Apache does not offer TLS cipher with TLSv1 
> anymore
>
> Hello,
>
> we host a website which clients still need to use the cipher 
> ECDHE-RSA-AES256-SHA
>
> with protocol "TLSv1.0" aka "TLSv1".
>
> With our old Apache server that worked. Spec:
> Ubuntu  14.04 LTS
> Apache  2.4.7-1ubuntu4.22
> OpenSSL 1.0.1f-1ubuntu2.27
>
> Apache config:
> SSLProtocol -all +TLSv1.2 +TLSv1
> SSLCipherSuite  
> ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA
>
> sslscan shows the following cipher support of the old Apache server:
> Supported Server Cipher(s):
> Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
> Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384 DHE 2048 bits
> Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
> Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256
> Preferred TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256
>
> So, ECDHE-RSA-AES256-SHA is offered both via TLSv1.2 and TLSv1.0.
>
> Now we have a newer Apache server setup. Spec:
> Ubuntu  18.04.1 LTS
> Apache  2.4.29-1ubuntu4.14
> OpenSSL 1.1.1-1ubuntu2.1~18.04.9
>
> The complete Apache config. is unchanged, so still:
> SSLProtocol -all +TLSv1.2 +TLSv1
> SSLCipherSuite  
> ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA
>
> But now sslscan shows for the new Apache server:
> Supported Server Cipher(s):
> Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
> Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384 DHE 2048 bits
> Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
> Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256
>
> The problem is, ECDHE-RSA-AES256-SHA is now _only_ supported via TLSv1.2, not 
> via TLSv1.0 anymore.
>
> How does this come?
>
> Is it possible to make the new Apache to offer ECDHE-RSA-AES256-SHA also via 
> TLSv1.0 again?
>
> Thank you very much.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: [users@httpd] Newer Apache does not offer TLS cipher with TLSv1 anymore

[Hildegard Meier]

When changing

SSLProtocol -all +TLSv1.2 +TLSv1

to

SSLProtocol -all +TLSv1

then TLSv1.0 support is there:

sslscan gives:

  Supported Server Cipher(s):
Preferred TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256
Accepted  TLSv1.0  256 bits  AES256-SHA


So this seems to be an issue of protocol preference in Apache?

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: [users@httpd] Newer Apache does not offer TLS cipher with TLSv1 anymore

[Hildegard Meier]

P.S.

OpenSSL seems to offer the cipher ECDHE-RSA-AES256-SHA via TLSv1 on the new 
server (Ubuntu 18):

openssl ciphers -v -s -tls1 | grep '^ECDHE-RSA-AES256-SHA '
ECDHE-RSA-AES256-SHATLSv1 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Newer Apache does not offer TLS cipher with TLSv1 anymore

[Hildegard Meier]

Hello,

we host a website which clients still need to use the cipher 
ECDHE-RSA-AES256-SHA

with protocol "TLSv1.0" aka "TLSv1".

With our old Apache server that worked. Spec:
Ubuntu  14.04 LTS
Apache  2.4.7-1ubuntu4.22
OpenSSL 1.0.1f-1ubuntu2.27

Apache config:
SSLProtocol -all +TLSv1.2 +TLSv1
SSLCipherSuite  
ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA

sslscan shows the following cipher support of the old Apache server:
Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384 DHE 2048 bits
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256
Preferred TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256

So, ECDHE-RSA-AES256-SHA is offered both via TLSv1.2 and TLSv1.0.

Now we have a newer Apache server setup. Spec:
Ubuntu  18.04.1 LTS
Apache  2.4.29-1ubuntu4.14
OpenSSL 1.1.1-1ubuntu2.1~18.04.9

The complete Apache config. is unchanged, so still:
SSLProtocol -all +TLSv1.2 +TLSv1
SSLCipherSuite  
ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA

But now sslscan shows for the new Apache server:
Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384 DHE 2048 bits
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA  Curve P-256 DHE 256

The problem is, ECDHE-RSA-AES256-SHA is now _only_ supported via TLSv1.2, not 
via TLSv1.0 anymore.

How does this come?

Is it possible to make the new Apache to offer ECDHE-RSA-AES256-SHA also via 
TLSv1.0 again?

Thank you very much.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: Re: Re: [users@httpd] Set SSLCipherSuite dependent on client IP

[Hildegard Meier]

I had the  in the  context, where also the SSLCipherSuite is 
defined.
As I understand, the Clients jumps in the Virtualhost context before TLS 
handshake because of SNI, so it should be theoretically possible to process the 
 in the virtualhost context before handshake.

But I had old non-SNI-cpable clients, too, so that would not have worked 
either, with non-SNI I guess you are right.

We will do now another way to get the old clients out of the way to be able to 
disable old weak ciphers in the vhost.

Thank you.


> Gesendet: Donnerstag, 25. Februar 2021 um 12:40 Uhr
> Von: "Yann Ylavic" 
> An: users@httpd.apache.org
> Betreff: Re: Re: [users@httpd] Set SSLCipherSuite dependent on client IP
>
> On Wed, Feb 24, 2021 at 6:01 PM Hildegard Meier  wrote:
> >
> > I thought about something like that as cause, but since the client IP is 
> > known from the very first start of the request, before TLS handshake, I 
> > thought it could be evaluated.
>
> Yes but to determine the context from which the  takes place
> (VirtualHost, directory, location..), the server needs to know the
> request header, thus negotiate TLS with the user-agent already.
> Chicken and egg..
>
> Regards;
> Yann.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: Re: Re: [users@httpd] Set SSLCipherSuite dependent on client IP

[Hildegard Meier]

SSLCipherSuite          -all:MD5

is served by Apache (at least with old Ubuntu 14) as expected.

 

Get's s F rating on

https://www.ssllabs.com/ssltest/

though :)

Nevermind, that SSLCipherSuite was just an example, I should have taken one that is really used, to prevent complication.

 
 

Gesendet: Donnerstag, 25. Februar 2021 um 13:55 Uhr
Von: "Brian Wolfe" 
An: users@httpd.apache.org
Betreff: Re: Re: [users@httpd] Set SSLCipherSuite dependent on client IP


The question is if the "If/Else" block is being evaluated. I suspect it is, but the selected CipherSuites are not available and therefore the global setting is used to negotiate.
 


On Thu, Feb 25, 2021 at 7:50 AM Yann Ylavic  wrote:

On Thu, Feb 25, 2021 at 1:44 PM Brian Wolfe  wrote:
>
> Are you sure that you have any MD5 ciphers enabled.

Wrong thread?

Regards;
Yann.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
 

 

 
--



Thanks,
Brian Wolfe

https://www.linkedin.com/in/brian-wolfe-3136425a/

 







-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: Re: [users@httpd] Set SSLCipherSuite dependent on client IP

[Hildegard Meier]

Thank you very much Eric, for your quick response and explanation. Do you have 
a source for it (aside of the source code ;) ?

I thought about something like that as cause, but since the client IP is known 
from the very first start of the request, before TLS handshake, I thought it 
could be evaluated.

Could it be possible another way to give clients of a specific vHost different 
SSLCipherSuite's depending on their IP address? (cipher of first handshake, no 
renegotiation)


> Gesendet: Mittwoch, 24. Februar 2021 um 14:26 Uhr
> Von: "Eric Covener" 
> An: users@httpd.apache.org
> Betreff: Re: [users@httpd] Set SSLCipherSuite dependent on client IP
>
> > Why does this not work?
>
>  is evaluated early in request processing, long after the
> handshake. However, the manual says:
> In per-directory context it forces a SSL renegotiation with the
> reconfigured Cipher Suite after the HTTP request was read but before
> the HTTP response is sent.
>
> I suggest testing w/o TLS13 and testing the equivalent config with
>  or  to see if renegotiation occurs w/o .
> You will have to carefully look for the final cipher.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: [users@httpd] Set SSLCipherSuite dependent on client IP

[Hildegard Meier]

P.S. Nevermind the port 4433 in the example, that's because load balancer port 
natting.

The vHost works fine with outbound port 443. This question is only about the 
if/else block in combination with SSLCipherSuite.

> Gesendet: Mittwoch, 24. Februar 2021 um 14:12 Uhr
> Von: "Hildegard Meier" 
> An: users@httpd.apache.org
> Betreff: [users@httpd] Set SSLCipherSuite dependent on client IP
>
> Hello,
>
> having Ubuntu 14 server with Apache 2.4.7
>
> I configured to have SSLCipherSuite dependent on the client IP address.
>
> But the If/Else directive seems to be just silently ignored, only and always 
> the global default SSLCipherSuite value is in effect.
>
> The SSLCipherSuite given in the If or Else block (which should be taken for 
> every client that is not in the 1.2.3.0/26 network) is not taken.
>
> Why does this not work?
> Is there another way to achieve the goal?
>
>
> Here the vHost config:
>
> 
>
> ServerName ssl-test.example.com
>
> DocumentRoot "/var/www/docs/empty"
>
> SSLEngine on
> SSLCertificateKeyFile   "/etc/apache2/ssl/keys/test.key"
> SSLCertificateFile  "/etc/apache2/ssl/certs/test.crt"
> SSLCertificateChainFile "/etc/apache2/ssl/certs/test.crt"
>
> 
> SSLCipherSuite  -all:MD5
> 
> 
> SSLCipherSuite  -all:SHA1
> 
>
> CustomLog "/var/log/apache2/test/access.log"  vhost_combined
> ErrorLog  "/var/log/apache2/test/error.443.log"
>
> 
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Set SSLCipherSuite dependent on client IP

[Hildegard Meier]

Hello,

having Ubuntu 14 server with Apache 2.4.7

I configured to have SSLCipherSuite dependent on the client IP address.

But the If/Else directive seems to be just silently ignored, only and always 
the global default SSLCipherSuite value is in effect.

The SSLCipherSuite given in the If or Else block (which should be taken for 
every client that is not in the 1.2.3.0/26 network) is not taken.

Why does this not work?
Is there another way to achieve the goal?


Here the vHost config:



ServerName ssl-test.example.com

DocumentRoot "/var/www/docs/empty"

SSLEngine on
SSLCertificateKeyFile   "/etc/apache2/ssl/keys/test.key"
SSLCertificateFile  "/etc/apache2/ssl/certs/test.crt"
SSLCertificateChainFile "/etc/apache2/ssl/certs/test.crt"


SSLCipherSuite  -all:MD5


SSLCipherSuite  -all:SHA1


CustomLog "/var/log/apache2/test/access.log"  vhost_combined
ErrorLog  "/var/log/apache2/test/error.443.log"




-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] [SOLVED] [users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[Hildegard Meier]

Hi Yann,

thanks for Your support. Your suggestion to comment(remove) the Mutex directive 
from /etc/apache2/apache2.conf solved the problem here.

No warning/emergency errors anymore. :)

Output of "apache2ctl -t -D DUMP_RUN_CFG" is now:

Mutex default: dir="/var/run/apache2/" mechanism=default


> >> > Mutex file:${APACHE_LOCK_DIR} default
> >>
> >> Does it come from Ubuntu?
> >> If so, I don't any modern Linux should configure the "file" mutex
> >> mechanism by default, and you could possibly report it...

Is reported here:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1565744

> > I just checked what is the active Mutex:
> >
> > #apache2ctl -t -D DUMP_RUN_CFG
> > ServerRoot: "/etc/apache2"
> > Main DocumentRoot: "/var/www"
> > Main ErrorLog: "/var/log/apache2/error.log"
> > Mutex watchdog-callback: using_defaults
> > Mutex rewrite-map: using_defaults
> > Mutex ssl-stapling: using_defaults
> > Mutex proxy: using_defaults
> > Mutex ssl-cache: using_defaults
> > Mutex default: dir="/var/lock/apache2" mechanism=fcntl
> 
> That's when you configure "Mutex fcntl:/var/lock/apache2" right, not
> by default (no Mutex)?

That's the output having the default Ubuntu 14 configuration directive "Mutex 
file:${APACHE_LOCK_DIR} default"


Best regards

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: Re: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[Hildegard Meier]

> There is an old dev@ thread that talks about the same deadlock
> avoidance issues from fcntl
> on other platforms (at least Solaris). I think it's not really usable
> in httpd as soon as you have two mutexes.

Read that, thought it would be only special for Solaris...

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: Re: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[Hildegard Meier]

> > Mutex file:${APACHE_LOCK_DIR} default
> 
> Does it come from Ubuntu?
> If so, I don't any modern Linux should configure the "file" mutex
> mechanism by default, and you could possibly report it...

Yes, that is the entry of Ubuntu 14 ("Trusty") default apache2.conf file, see
http://packages.ubuntu.com/de/trusty/apache2
there the linked file
http://archive.ubuntu.com/ubuntu/pool/main/a/apache2/apache2_2.4.7-1ubuntu4.5.debian.tar.gz
in the tarball the file
/debian/config-dir/apache2.conf


> Honestly I don't know how "fnctl" works on Linux, but I'd recommend
> using no Mutex directive at all (same as "Mutex default") which falls
> back to "Mutex sysvsem default" given your output of apachectl (i.e.
> "-D APR_USE_SYSVSEM_SERIALIZE"), or possibly "Mutex pthread default"
> which is the most efficient on Linux IMHO (also robust, leaks free on
> crashes).
Great, thanks, I think we will try without Mutex directive. So if apache2ctl -V 
gives
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
then the first is taken as default?

I just checked what is the active Mutex:

#apache2ctl -t -D DUMP_RUN_CFG
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/lock/apache2" mechanism=fcntl
Mutex mpm-accept: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_RUN_CFG
Define: ENABLE_USR_LIB_CGI_BIN
User: name="www-data" id=33
Group: name="www-data" id=33

It looks strange to me that fcntl is used but no files exist in 
/var/lock/apache2

> Hopefully, the "file" mechanism is not suitable anyway or modern OS.
Thanks for the info!
 

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[Hildegard Meier]

Reading
https://httpd.apache.org/docs/2.4/en/mod/core.html#mutex

I guess, expected behaviour of active directive

Mutex file:${APACHE_LOCK_DIR} default

would be
Mutex fnctl:${APACHE_LOCK_DIR} default

?
Maybe it's worth a try to add the line

Mutex fnctl:${APACHE_LOCK_DIR} ssl-cache

and look if
/var/lock/apache2/ssl-cache
gets created and the 

"AH02026: Failed to acquire SSL session cache lock" messages disappear?

But we need to test that on our standby server after upgrading that to Apache 
2.4 which will be done in 10 days or so.


> Gesendet: Dienstag, 08. März 2016 um 16:44 Uhr
> Von: "hildegard meier" <daku8...@gmx.de>
> An: users@httpd.apache.org
> Betreff: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock 
> avoided: AH02026: Failed to acquire SSL session cache lock"
>
> OS:
> Ubuntu 14.04 LTS
> 
> Kernel:
> 3.13.0-79-generic x86_64
> 
> Apache:
> 2.4.7-1ubuntu4.5
> 
> The Host has just been release-upgraded (with Ubuntu do-release-upgrade 
> command) From Ubuntu 12.04 LTS
> 
> All Apache config files are the new ones, old configuration entries have been 
> adopted to the new config files manually.
> 
> Issue:
> Most of the 74 vHosts are working fine. But on two vHosts there is coming the 
> following message nearly every minute:
> 
> [Tue Mar 08 16:08:18.596653 2016] [ssl:warn] [pid 8339:tid 140182179256064] 
> (35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache 
> lock
> [Tue Mar 08 16:08:20.791623 2016] [ssl:warn] [pid 8849:tid 140182112114432] 
> (35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache 
> lock
> [Tue Mar 08 16:08:54.230004 2016] [ssl:warn] [pid 8849:tid 140182162470656] 
> (35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache 
> lock
> [Tue Mar 08 16:13:28.180687 2016] [ssl:warn] [pid 10595:tid 140182095329024] 
> (35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache 
> lock
> 
> But we are not aware of any impact of this. Server generally working fine 
> (has some traffic- 700 established AJP proxy connections, 200 busy worker 
> threads, 100 Requests/s, 300 KB/s).
> 
> I did not find much about that message. Only official:
> 
> AH02026: Failed to acquire SSL session cache lock"  
> ./modules/ssl/ssl_engine_mutex.c:92
> (source: https://wiki.apache.org/httpd/ListOfErrors)
> 
> We use mpm worker:
> 
> /etc/apache2/mods-enabled/mpm_worker.conf
> 
> StartServers2
> MinSpareThreads 25
> MaxSpareThreads 75
> ThreadLimit 64
> ThreadsPerChild 35
> MaxRequestWorkers   560
> MaxConnectionsPerChild  1
> 
> 
> 
> /etc/apache2/mods-enabled/ssl.conf
> 
> SSLRandomSeed startup builtin
> SSLRandomSeed startup file:/dev/urandom 512
> SSLRandomSeed connect builtin
> SSLRandomSeed connect file:/dev/urandom 512
> 
> AddType application/x-x509-ca-cert .crt
> AddType application/x-pkcs7-crl .crl
> 
> SSLPassPhraseDialog exec:/usr/share/apache2/ask-for-passphrase
> 
> SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
> SSLSessionCacheTimeout  300
> 
> SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5:!RC4
> 
> SSLProtocol all -SSLv3
> 
> 
> 
> socache_shmcb.load
> is loaded (via symlink /etc/apache2/mods-enabled)
> 
> 
> /etc/apache2/apache2.conf
> Mutex file:${APACHE_LOCK_DIR} default
> 
> 
> /etc/apache2/envvars
> export APACHE_PID_FILE=/var/run/apache2/apache2$SUFFIX.pid
> export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
> export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
> 
> file
> /var/run/apache2/apache2.pid
> exists and contains the proper PID of apache process.
> 
> But there is no "ssl_scache":
> 
> ls -al /var/run/apache2/
> total 4
> drwxr-xr-x  2 root root  80 Mar  8 12:54 .
> drwxr-xr-x 18 root root 680 Mar  8 13:18 ..
> -rw-r--r--  1 root root   5 Mar  8 12:54 apache2.pid
> srwx--  1 www-data root   0 Mar  8 12:54 cgisock.1425
> 
> But according to apache status page, SSL cache is working:
> 
> SSL/TLS Session Cache Status:
> cache type: SHMCB, shared memory: 512000 bytes, current entries: 463
> subcaches: 32, indexes per subcache: 88
> time left on oldest entries' objects: avg: 26 seconds, (range: 0...71)
> index usage: 16%, cache usage: 20%
> total entries stored since starting: 27271
> total entries replaced since starting: 0
> total entries expired since starting: 22693
> total (pre-expiry) entries scrolled out of the cache: 0
> total retrieves since starting: 224953 hit, 14

Aw: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[Hildegard Meier]

We have also this messages with severity "emergency":

grep emerg /var/log/apache2/error.log
[Wed Mar 09 07:09:31.099331 2016] [mpm_worker:emerg] [pid 26526:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 09:49:31.931429 2016] [mpm_worker:emerg] [pid 20322:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 11:00:09.663350 2016] [mpm_worker:emerg] [pid 3062:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 11:33:02.20 2016] [mpm_worker:emerg] [pid 5608:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 11:33:24.130957 2016] [mpm_worker:emerg] [pid 9516:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 11:36:08.238661 2016] [mpm_worker:emerg] [pid 10392:tid 
139668485949184] (35)Resource deadlock avoided: AH00272: apr_proc_mutex_lock 
failed before this child process served any requests.
[Wed Mar 09 12:54:09.526485 2016] [mpm_worker:emerg] [pid 22783:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.
[Wed Mar 09 13:11:18.312498 2016] [mpm_worker:emerg] [pid 26526:tid 
139668485949184] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock 
failed. Attempting to shutdown process gracefully.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Aw: Re: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[hildegard meier]

Thanks Yann,

# apache2ctl -V
Server version: Apache/2.4.7 (Ubuntu)
Server built:   Jul 24 2015 17:25:11
Server's Module Magic Number: 20120211:27
Server loaded:  APR 1.5.1-dev, APR-UTIL 1.5.3
Compiled using: APR 1.5.1-dev, APR-UTIL 1.5.3
Architecture:   64-bit
Server MPM: worker
  threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"




--
> Gesendet: Dienstag, 08. März 2016 um 20:41 Uhr
> Von: "Yann Ylavic" <ylavic@gmail.com>
> An: users@httpd.apache.org
> Betreff: Re: [users@httpd] Lots of messages "[ssl:warn] Resource deadlock 
> avoided: AH02026: Failed to acquire SSL session cache lock"
>
> On Tue, Mar 8, 2016 at 4:44 PM, hildegard meier <daku8...@gmx.de> wrote:
> > OS:
> > Ubuntu 14.04 LTS
> >
> > Kernel:
> > 3.13.0-79-generic x86_64
> >
> > Apache:
> > 2.4.7-1ubuntu4.5
> 
> What's the output of:
> # apachectl -V
> ?
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
> 
>

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Lots of messages "[ssl:warn] Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock"

[hildegard meier]

OS:
Ubuntu 14.04 LTS

Kernel:
3.13.0-79-generic x86_64

Apache:
2.4.7-1ubuntu4.5

The Host has just been release-upgraded (with Ubuntu do-release-upgrade 
command) From Ubuntu 12.04 LTS

All Apache config files are the new ones, old configuration entries have been 
adopted to the new config files manually.

Issue:
Most of the 74 vHosts are working fine. But on two vHosts there is coming the 
following message nearly every minute:

[Tue Mar 08 16:08:18.596653 2016] [ssl:warn] [pid 8339:tid 140182179256064] 
(35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock
[Tue Mar 08 16:08:20.791623 2016] [ssl:warn] [pid 8849:tid 140182112114432] 
(35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock
[Tue Mar 08 16:08:54.230004 2016] [ssl:warn] [pid 8849:tid 140182162470656] 
(35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock
[Tue Mar 08 16:13:28.180687 2016] [ssl:warn] [pid 10595:tid 140182095329024] 
(35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock

But we are not aware of any impact of this. Server generally working fine (has 
some traffic- 700 established AJP proxy connections, 200 busy worker threads, 
100 Requests/s, 300 KB/s).

I did not find much about that message. Only official:

AH02026: Failed to acquire SSL session cache lock"  
./modules/ssl/ssl_engine_mutex.c:92
(source: https://wiki.apache.org/httpd/ListOfErrors)

We use mpm worker:

/etc/apache2/mods-enabled/mpm_worker.conf

StartServers2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 35
MaxRequestWorkers   560
MaxConnectionsPerChild  1



/etc/apache2/mods-enabled/ssl.conf

SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 512

AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl

SSLPassPhraseDialog exec:/usr/share/apache2/ask-for-passphrase

SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
SSLSessionCacheTimeout  300

SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5:!RC4

SSLProtocol all -SSLv3



socache_shmcb.load
is loaded (via symlink /etc/apache2/mods-enabled)


/etc/apache2/apache2.conf
Mutex file:${APACHE_LOCK_DIR} default


/etc/apache2/envvars
export APACHE_PID_FILE=/var/run/apache2/apache2$SUFFIX.pid
export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX

file
/var/run/apache2/apache2.pid
exists and contains the proper PID of apache process.

But there is no "ssl_scache":

ls -al /var/run/apache2/
total 4
drwxr-xr-x  2 root root  80 Mar  8 12:54 .
drwxr-xr-x 18 root root 680 Mar  8 13:18 ..
-rw-r--r--  1 root root   5 Mar  8 12:54 apache2.pid
srwx--  1 www-data root   0 Mar  8 12:54 cgisock.1425

But according to apache status page, SSL cache is working:

SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current entries: 463
subcaches: 32, indexes per subcache: 88
time left on oldest entries' objects: avg: 26 seconds, (range: 0...71)
index usage: 16%, cache usage: 20%
total entries stored since starting: 27271
total entries replaced since starting: 0
total entries expired since starting: 22693
total (pre-expiry) entries scrolled out of the cache: 0
total retrieves since starting: 224953 hit, 14045 miss
total removes since starting: 0 hit, 0 miss


There is also nothing in /var/lock/apache2:

ls -al /var/lock/apache2/
total 0
drwxr-xr-x 2 www-data root 40 Mar  8 12:54 .
drwxrwxrwt 3 root root 60 Mar  4 17:35 ..

I would expect that there would be files with the names of the mutex type, 
according to

"With the file-based mechanisms fcntl and flock, the path, if provided, is a 
directory where the lock file will be created [...] The basename of the file 
will be the mutex type"
(source: https://httpd.apache.org/docs/2.4/en/mod/core.html#mutex)

Could someone please tell if that is ok that there is neither a ssl_scache file 
nor mutex type named mutex files ?

What can I do to get rid of the "AH02026: Failed to acquire SSL session cache 
lock" messages?

What is the meaning of the message?

Thanks very much.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org