[users@httpd] mod_proxy_wstunnel intermittent empty response

[Jonathon Koyle]

I am running httpd-2.4.6 on CentOS7. I have an https virtual host
configured to proxy requests to a specific location as wss

  ProxyPass "wss://127.0.0.1:9000/"
  ProxyPassReverse "wss://${server_name}/ws/"


However, attempts to connect occasionally fail, using curl to test:
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H
"Protocols: stomp" https://127.0.0.1/ws -H "Sec-WebSocket-Version: 13" -H
"Sec-WebSocket-Key: asdfghjkl;qwertzxcvbnmlk" -k

A failure results in:
  curl: (52) Empty reply from server

Looking around I found this thread
http://apache-http-server.18135.x6.nabble.com/mod-proxy-wstunnel-ignores-proxy-wstunnel-transfer-errors-td5020240.html
that discusses what seems like a similar problem to me, and mentions a
patch, but doesn't actual mention a specific release, only 2.4.x.  I'm also
not certain, from the thread, if the problem addressed was intermittent or
not.

Has anybody else seen this behavior or have any suggestions?  Updating to a
version of httpd not in a Centos repo is not an option for me,
unfortunately.

Any help is appreciated.

-- 
Jonathon Koyle

[users@httpd] use cookie value as auth username

[Jesse Norell]

Hello,

  I'm trying to use an authz_dbd query to authorize based on the value
of a cookie (ie. if PHPSESSID cookie is set, a db query can test if it
should be authorized).  It seems the only parameter AUTHzDBDQuery will
supply to the sql query is the username in place of %s; this could work
if I could set what REMOTE_USER should be prior to the query running,
but I haven't found a way to do so.  Eg. here the username for the
query is from the auth provider (anon), the SetEnv doesn't the query:


  AuthName "Name"
  AuthType Basic
  AuthBasicProvider anon

  Anonymous_NoUserID on
  Anonymous_MustGiveEmail off
  Anonymous anonymous "*"

  SetEnvIf Cookie "PHPSESSID=([^ ]+)" REMOTE_USER=$1

  Require dbd-group foo

  # this will work, for any username entered in the browser:
  #AuthzDBDQuery "SELECT 'foo' FROM sys_session"

  # this does not work to obtain %s from PHPSESSID:
  AuthzDBDQuery "SELECT 'foo' FROM sys_session WHERE session_id = %s"



  I'm pretty sure I must convince apache to set a new REMOTE_USER (or
httpd_username?) internal variable, not an environment variable, but I
don't see how.  If I don't specify any AuthType, or set it to None, the
AuthzDBDQuery never runs and the error.log says it requires
authentication but authentication is not set up.  Any ideas are
appreciated - thanks!

  I'm running 2.4.25-3+deb9u5 from debian stretch.

Thanks,
Jesse Norell 

-- 
Jesse Norell
Kentec Communications, Inc.
970-522-8107  -  www.kci.net


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

[users@httpd] mod_ldap and Basic Auth

[john.ber...@us.fujitsu.com]

I have finally moved to Apache Httpd 2.4 from 2.2 and I am having issues 
getting our basic authentication to our ldap for some very specific areas. 
Below is what our 2.2 configuration used and worked just fine and the new 2.4 
config that is not working. When I use the 2.4 it prompts for username and 
password but throws a Internal Server Error after submitting.  I am sure it is 
something I am missing but I cannot figure it out.

2.2 config


AuthType basic
AuthBasicProvider ldap
AuthName "Partners"
SetHandler none
Order deny,allow
Deny from all
Allow from all
AuthLDAPURL ldap://servername:389/o=directory1.fnc.fujitsu.com
AuthzLDAPAuthoritative off
Require valid-user



AuthType basic
AuthBasicProvider ldap
AuthName "Partners"
SetHandler none
Order deny,allow
Deny from all
Allow from all
AuthLDAPURL ldap://servername:389/o=directory1.fnc.fujitsu.com
AuthzLDAPAuthoritative off
Require valid-user



AuthType basic
AuthBasicProvider ldap
AuthName "Partners"
SetHandler none
Order deny,allow
Deny from all
Allow from all
AuthLDAPURL ldap://servername:389/o=directory1.fnc.fujitsu.com
AuthzLDAPAuthoritative off
Require valid-user



2.4 config (If I add "Required all granted" if does not prompt and lets 
everyone in)

   
AuthType basic
AuthBasicAuthoritative On
AuthBasicProvider ldap
AuthName "Partners"
SetHandler none
AuthLDAPURL ldap://servername:389/o=directory1.fnc.fujitsu.com
Require valid-user
   

   
AuthType basic
AuthBasicAuthoritative On
AuthBasicProvider ldap
AuthName "Partners"
SetHandler none
AuthLDAPURL ldap://servername:389/o=directory1.fnc.fujitsu.com
Require valid-user
   

   
AuthType basic
AuthBasicAuthoritative On
AuthBasicProvider ldap
AuthName "Partners"
SetHandler none
AuthLDAPURL ldap://servername:389/o=directory1.fnc.fujitsu.com
Require valid-user
   

John Berger

Re: [users@httpd] IP address used by Apache reverse proxy?

[Gillis J. de Nijs]

I'm starting to think you don't know what you need, and we don't understand
what you want.  So, drop everything you (think you) know, and start over.

What are you trying to do?  Not how you're trying to do it, or why, but
WHAT do you want to do?  WHAT components are involved?

I'm thinking it's along the lines of:
- I have a subdomain registered at so-and-so.
- I want to use that subdomain to host a site on my local computer.
- The computer is behind my home router.
- I have a static public IP at home (on my router - or - it is bridged to
my computer)
- etc, etc...

On Tue, Sep 25, 2018 at 10:45 AM Osman Zakir 
wrote:

> When you mention the DocumentRoot, do you mean just the setting for vhosts
> or the document root for the reverse proxy?  Are you telling me I don't
> need a  directive if I have a ProxyPass "/" "http://target/;
> line?
>
> And is it fine to have the ProxyPass defined like this:
> ProxyPass "/"
> "E:/programming/visual_studio_2017/Projects/currency_converter/Release/" ?
> That's the path to the directory on my machine.
>
> Is the stuff from line 541 to line 546 not needed?
> --
> *From:* Frank Gingras 
> *Sent:* Tuesday, September 25, 2018 7:08 AM
> *To:* users@httpd.apache.org
> *Subject:* Re: [users@httpd] IP address used by Apache reverse proxy?
>
> Osman,
>
> Take a step back, you're all over the place. You need to focus on one task
> at a time, else you will never finish configuring your server.
>
> For the vhost, again, if you use ProxyPass / http://target/, then you do
> *not* need set set a DocumentRoot, as every single request will be proxied.
>
> If you proxy a specific URI path, i.e. ProxyPass /foo http://target/bar,
> then do *do* need a DocumentRoot to handle the requests that do not begin
> with /foo.
>
> For SSL/TLS, determine first if you want httpd to do the termination, or
> if your backend speaks TLS.
>
> On Mon, Sep 24, 2018 at 4:45 PM Osman Zakir 
> wrote:
>
> I got a subdomain from freedns.afraid.org that took the IP address of my
> computer. I tried to use it for my app, but when I navigated to the
> subdomain, it took me to the login page for my router's admin settings.  I
> tried specifying the port number I set on the Apache httpd configuration
> file, but that got me to an error page indicating that the browser can't
> find the site.
>
> I'm attaching httpd.conf again.  I need to know about the PassEnv lines as
> well, actually.  And also the stuff from line 541 downward.
>
> What am I still doing wrong?  Please help.  Thanks.
> --
> *From:* Eric Covener 
> *Sent:* Monday, September 24, 2018 7:08 PM
> *To:* users@httpd.apache.org
> *Subject:* Re: [users@httpd] IP address used by Apache reverse proxy?
>
> On Mon, Sep 24, 2018 at 7:30 AM Osman Zakir 
> wrote:
> >
> > The Apache document root and the document root for the reverse proxy
> should be different, right?
>
> Isn't Apache and the reverse proxy one and the same?
>
>  > And do you mean I need to specify the document root for the reverse
> proxy via the  directive?  Or do I just have to have that
> somewhere above or below the ProxyPass line?  And if I specify the
> reverse proxy document root in ProxyPass, I don't also need to specify
> it for the virtual host, right?  As for the port number for the
> reverse proxy, I'll try 8000 for now.
>
> The DocumentRoot won't ever be used with your ProxyPass /.
> If you later had ProxyPass of some more specific context root, like
> /app, then your document root would be used when the request didn't
> match the ProxyPass.
>
> The relative position doesn't matter as long as they are in the same
> context.
>
> > If I have this:
> >
> > < "E:/programming/visual_studio_2017/Projects/currency_converter/Release">
> > 
>
> > What should I put in there?
>
> What do you expect Apache to do with files in there? You've been
> talking about a reverse proxy.
>
> -
> 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
>
>

Re: [users@httpd] IP address used by Apache reverse proxy?

[Osman Zakir]

When you mention the DocumentRoot, do you mean just the setting for vhosts or 
the document root for the reverse proxy?  Are you telling me I don't need a 
 directive if I have a ProxyPass "/" "http://target/; line?

And is it fine to have the ProxyPass defined like this:
ProxyPass "/" 
"E:/programming/visual_studio_2017/Projects/currency_converter/Release/" ?  
That's the path to the directory on my machine.

Is the stuff from line 541 to line 546 not needed?

From: Frank Gingras 
Sent: Tuesday, September 25, 2018 7:08 AM
To: users@httpd.apache.org
Subject: Re: [users@httpd] IP address used by Apache reverse proxy?

Osman,

Take a step back, you're all over the place. You need to focus on one task at a 
time, else you will never finish configuring your server.

For the vhost, again, if you use ProxyPass / http://target/, then you do *not* 
need set set a DocumentRoot, as every single request will be proxied.

If you proxy a specific URI path, i.e. ProxyPass /foo http://target/bar, then 
do *do* need a DocumentRoot to handle the requests that do not begin with /foo.

For SSL/TLS, determine first if you want httpd to do the termination, or if 
your backend speaks TLS.

On Mon, Sep 24, 2018 at 4:45 PM Osman Zakir 
mailto:osmanzaki...@hotmail.com>> wrote:
I got a subdomain from freedns.afraid.org that took 
the IP address of my computer. I tried to use it for my app, but when I 
navigated to the subdomain, it took me to the login page for my router's admin 
settings.  I tried specifying the port number I set on the Apache httpd 
configuration file, but that got me to an error page indicating that the 
browser can't find the site.

I'm attaching httpd.conf again.  I need to know about the PassEnv lines as 
well, actually.  And also the stuff from line 541 downward.

What am I still doing wrong?  Please help.  Thanks.

From: Eric Covener mailto:cove...@gmail.com>>
Sent: Monday, September 24, 2018 7:08 PM
To: users@httpd.apache.org
Subject: Re: [users@httpd] IP address used by Apache reverse proxy?

On Mon, Sep 24, 2018 at 7:30 AM Osman Zakir 
mailto:osmanzaki...@hotmail.com>> wrote:
>
> The Apache document root and the document root for the reverse proxy should 
> be different, right?

Isn't Apache and the reverse proxy one and the same?

 > And do you mean I need to specify the document root for the reverse
proxy via the  directive?  Or do I just have to have that
somewhere above or below the ProxyPass line?  And if I specify the
reverse proxy document root in ProxyPass, I don't also need to specify
it for the virtual host, right?  As for the port number for the
reverse proxy, I'll try 8000 for now.

The DocumentRoot won't ever be used with your ProxyPass /.
If you later had ProxyPass of some more specific context root, like
/app, then your document root would be used when the request didn't
match the ProxyPass.

The relative position doesn't matter as long as they are in the same context.

> If I have this:
>
> < "E:/programming/visual_studio_2017/Projects/currency_converter/Release">
> 

> What should I put in there?

What do you expect Apache to do with files in there? You've been
talking about a reverse proxy.

-
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] Antwort: [users@httpd] tls_process_client_certificate:certificate verify failed - when using a PSS Signed intermediat

[Frank Wuttig]

Testet again with clean Ubuntu 18.04.1 LTS and default Ubuntu repositorys

Apache 2.4.29-1ubuntu4.3
Openssl 1.1.0g-2ubuntu4.1

Same issue.



Von:"Frank Wuttig" 
An: users@httpd.apache.org
Datum:  25.09.2018 08:25
Betreff:[users@httpd] tls_process_client_certificate:certificate 
verify failed - when using a PSS Signed intermediat
Gesendet von:   "Frank Wuttig" 



Hi,

we use a Clientauth configuration for a location without problems for many 
months

Ubuntu 16.04.5 LTS
Apache 2.4.18-2ubuntu3.9
openssl 1.0.2g-1ubuntu4.13


Now we upgraded Apache to use HTTP2

Ubuntu 16.04.5 LTS
Apache  2.4.34-1
openssl 1.1.0h-2.0


Apache Conf:

SSLEngine on
SSLVerifyDepth 2
SSLProxyEngine on
SSLProtocol -All +TLSv1.2 +TLSv1.1

SSLCipherSuite 
HIGH:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!EXP:!DES:!RC4:!3DES:!MD5:!PSK:!MEDIUM:!LOW:!SRP:!DSS


SSLCertificateFile /etc/apache2/ssl/blablub.pem
SSLCertificateKeyFile /etc/apache2/ssl/blablub.key
SSLCertificateChainFile /etc/apache2/ssl/blablub.ca_certificates.pem
SSLCACertificateFile /etc/apache2/ssl/ProductiveCAClientAuth.pem 

other stuff without ClientAuth...


SSLVerifyClient require
SSLVerifyDepth 2

ProxyPass https://server-1/test
ProxyPassReverse https://server-1/testg




Particularity:

The client certificates are issued by an intermediate CA which is itself 
PSS Signed. 
The root CA and the actual client certificates are signed normally SHA256.
Do not ask why, that's how it was built in the past and has worked so far

Error:

[Tue Sep 25 07:18:27.723798 2018] [ssl:debug] [pid 49219:tid 
140033499584256] ssl_engine_kernel.c(757): [client 89.187.203.114:61120] 
AH02255: Changed client verification type will force renegotiation
[Tue Sep 25 07:18:27.723803 2018] [ssl:info] [pid 49219:tid 
140033499584256] [client 89.187.203.114:61120] AH02221: Requesting 
connection re-negotiation
[Tue Sep 25 07:18:27.723827 2018] [ssl:debug] [pid 49219:tid 
140033499584256] ssl_engine_kernel.c(987): [client 89.187.203.114:61120] 
AH02260: Performing full renegotiation: complete handshake protocol 
(client does support secu
re renegotiation)
[Tue Sep 25 07:18:27.723867 2018] [ssl:info] [pid 49219:tid 
140033499584256] [client 89.187.203.114:61120] AH02226: Awaiting 
re-negotiation handshake
[Tue Sep 25 07:18:33.176966 2018] [ssl:error] [pid 49219:tid 
140033499584256] [client 89.187.203.114:61120] AH02261: Re-negotiation 
handshake failed
[Tue Sep 25 07:18:33.176987 2018] [ssl:error] [pid 49219:tid 
140033499584256] SSL Library Error: error:1417C086:SSL 
routines:tls_process_client_certificate:certificate verify failed
[Tue Sep 25 07:18:33.177005 2018] [core:trace3] [pid 49219:tid 
140033499584256] request.c(119): [client 89.187.203.114:61120] auth phase 
'check access (with Satisfy All)' gave status 403: /test/
[Tue Sep 25 07:18:33.177032 2018] [headers:debug] [pid 49219:tid 
140033499584256] mod_headers.c(900): AH01503: headers: 
ap_headers_error_filter()
[Tue Sep 25 07:18:33.177057 2018] [http:trace3] [pid 49219:tid 
140033499584256] http_filters.c(1128): [client 89.187.203.114:61120] 
Response sent with status 403, headers:
[Tue Sep 25 07:18:33.177062 2018] [http:trace5] [pid 49219:tid 
140033499584256] http_filters.c(1135): [client 89.187.203.114:61120] Date: 
Tue, 25 Sep 2018 05:18:27 GMT
[Tue Sep 25 07:18:33.177066 2018] [http:trace5] [pid 49219:tid 
140033499584256] http_filters.c(1138): [client 89.187.203.114:61120] 
Server: Apache/2.4.34 (Ubuntu)
[Tue Sep 25 07:18:33.177071 2018] [http:trace4] [pid 49219:tid 
140033499584256] http_filters.c(957): [client 89.187.203.114:61120] 
X-Frame-Options: SAMEORIGIN
[Tue Sep 25 07:18:33.177075 2018] [http:trace4] [pid 49219:tid 
140033499584256] http_filters.c(957): [client 89.187.203.114:61120] 
Content-Length: 320
[Tue Sep 25 07:18:33.177080 2018] [http:trace4] [pid 49219:tid 
140033499584256] http_filters.c(957): [client 89.187.203.114:61120] 
Connection: close
[Tue Sep 25 07:18:33.177084 2018] [http:trace4] [pid 49219:tid 
140033499584256] http_filters.c(957): [client 89.187.203.114:61120] 
Content-Type: text/html; charset=iso-8859-1


We tested it all again with client certificates issued by a SHA256 
intermediat CA. This works without problems. 
As I suspect that by updating Apache or openssl there is now a problem 
with PSS signed issuers.
Someone has an idea what you can do to make it fly again?

cheers 

Frank




Digitalisierung nach [Ihren] Regeln
Jetzt informieren unter 

[users@httpd] tls_process_client_certificate:certificate verify failed - when using a PSS Signed intermediat

[Frank Wuttig]

Hi,

we use a Clientauth configuration for a location without problems for many 
months

Ubuntu 16.04.5 LTS
Apache 2.4.18-2ubuntu3.9
openssl 1.0.2g-1ubuntu4.13


Now we upgraded Apache to use HTTP2

Ubuntu 16.04.5 LTS
Apache  2.4.34-1
openssl 1.1.0h-2.0


Apache Conf:

SSLEngine on
SSLVerifyDepth 2
SSLProxyEngine on
SSLProtocol -All +TLSv1.2 +TLSv1.1

SSLCipherSuite 
HIGH:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!EXP:!DES:!RC4:!3DES:!MD5:!PSK:!MEDIUM:!LOW:!SRP:!DSS

SSLCertificateFile /etc/apache2/ssl/blablub.pem
SSLCertificateKeyFile /etc/apache2/ssl/blablub.key
SSLCertificateChainFile /etc/apache2/ssl/blablub.ca_certificates.pem
SSLCACertificateFile /etc/apache2/ssl/ProductiveCAClientAuth.pem 

other stuff without ClientAuth...


SSLVerifyClient require
SSLVerifyDepth 2

ProxyPass https://server-1/test
ProxyPassReverse https://server-1/testg




Particularity:

The client certificates are issued by an intermediate CA which is itself 
PSS Signed. 
The root CA and the actual client certificates are signed normally SHA256.
Do not ask why, that's how it was built in the past and has worked so far

Error:

[Tue Sep 25 07:18:27.723798 2018] [ssl:debug] [pid 49219:tid 
140033499584256] ssl_engine_kernel.c(757): [client 89.187.203.114:61120] 
AH02255: Changed client verification type will force renegotiation
[Tue Sep 25 07:18:27.723803 2018] [ssl:info] [pid 49219:tid 
140033499584256] [client 89.187.203.114:61120] AH02221: Requesting 
connection re-negotiation
[Tue Sep 25 07:18:27.723827 2018] [ssl:debug] [pid 49219:tid 
140033499584256] ssl_engine_kernel.c(987): [client 89.187.203.114:61120] 
AH02260: Performing full renegotiation: complete handshake protocol 
(client does support secu
re renegotiation)
[Tue Sep 25 07:18:27.723867 2018] [ssl:info] [pid 49219:tid 
140033499584256] [client 89.187.203.114:61120] AH02226: Awaiting 
re-negotiation handshake
[Tue Sep 25 07:18:33.176966 2018] [ssl:error] [pid 49219:tid 
140033499584256] [client 89.187.203.114:61120] AH02261: Re-negotiation 
handshake failed
[Tue Sep 25 07:18:33.176987 2018] [ssl:error] [pid 49219:tid 
140033499584256] SSL Library Error: error:1417C086:SSL 
routines:tls_process_client_certificate:certificate verify failed
[Tue Sep 25 07:18:33.177005 2018] [core:trace3] [pid 49219:tid 
140033499584256] request.c(119): [client 89.187.203.114:61120] auth phase 
'check access (with Satisfy All)' gave status 403: /test/
[Tue Sep 25 07:18:33.177032 2018] [headers:debug] [pid 49219:tid 
140033499584256] mod_headers.c(900): AH01503: headers: 
ap_headers_error_filter()
[Tue Sep 25 07:18:33.177057 2018] [http:trace3] [pid 49219:tid 
140033499584256] http_filters.c(1128): [client 89.187.203.114:61120] 
Response sent with status 403, headers:
[Tue Sep 25 07:18:33.177062 2018] [http:trace5] [pid 49219:tid 
140033499584256] http_filters.c(1135): [client 89.187.203.114:61120] Date: 
Tue, 25 Sep 2018 05:18:27 GMT
[Tue Sep 25 07:18:33.177066 2018] [http:trace5] [pid 49219:tid 
140033499584256] http_filters.c(1138): [client 89.187.203.114:61120] 
Server: Apache/2.4.34 (Ubuntu)
[Tue Sep 25 07:18:33.177071 2018] [http:trace4] [pid 49219:tid 
140033499584256] http_filters.c(957): [client 89.187.203.114:61120] 
X-Frame-Options: SAMEORIGIN
[Tue Sep 25 07:18:33.177075 2018] [http:trace4] [pid 49219:tid 
140033499584256] http_filters.c(957): [client 89.187.203.114:61120] 
Content-Length: 320
[Tue Sep 25 07:18:33.177080 2018] [http:trace4] [pid 49219:tid 
140033499584256] http_filters.c(957): [client 89.187.203.114:61120] 
Connection: close
[Tue Sep 25 07:18:33.177084 2018] [http:trace4] [pid 49219:tid 
140033499584256] http_filters.c(957): [client 89.187.203.114:61120] 
Content-Type: text/html; charset=iso-8859-1


We tested it all again with client certificates issued by a SHA256 
intermediat CA. This works without problems. 
As I suspect that by updating Apache or openssl there is now a problem 
with PSS signed issuers.
Someone has an idea what you can do to make it fly again?

cheers 

Frank



---

Digitalisierung nach [Ihren] Regeln
Jetzt informieren unter: www.procilon.de/progov

---


procilon IT-Logistics GmbH

Leipziger Straße 110
04425 Taucha bei Leipzig