You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by "McGregor, Donald (Don) (CIV)" <mc...@nps.edu> on 2015/06/03 00:18:43 UTC
[users@httpd] Client Auth Retries
I’m trying to set up client authentication using smart cards and be reasonably polite about
auth failures. A typical failure mode is that the user doesn’t have the card inserted; I
should send them to a warning page, then let them retry.
The relevant config file for the top level:
SSLVerifyClient optional
RewriteEngine On
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS
RewriteRule .* /mistake/index.html [L]
<Directory /var/www/html/mistake>
SSLVerifyClient none
</Directory>
Client auth is optional, but if it fails they see the informational
page telling them to use a smart card, in a directory
without smart card auth required.
This successfully rewrites to the informational page when they
don’t have the smart card inserted. The first time in If client auth fails for
some reason they see the error page, and if they do have
the card and authenticate, they see the expected content.
But if they see the error page, then insert the card, and then
try to go to the https://myhost/content, they continue to
see the error page. It seems as if the HTTPS connection
is not being renegotiated or that the SSL_CLIENT_VERIFY
is not being reset to SUCCESS on retry. Or is there a
better way to do this?
RE: [users@httpd] Client Auth Retries
Posted by Scot Russell <sc...@hotmail.com>.
The documentation recommends a higher value for the sslsessioncache, probably for performance reasons. I wonder if you can unset that ssl header variable when your user hits the error page or before they try again, using mod_headers unset directive, configured only on that directory or file?
From: mcgredo@nps.edu
To: users@httpd.apache.org
Date: Thu, 4 Jun 2015 19:32:33 +0000
Subject: Re: [users@httpd] Client Auth Retries
I think that’s part of it—SSLSessionCache on the server was set to five minutes.
Dialing it down to 10 seconds seems to have solved the problem
on Safari, but it persists on Chrome, even after a server restart.
It fixes itself after a Chrome restart, so clearly Chrome is doing some caching
of something, somewhere.
What are the consequences of having a low SSLSessionCache value on the server?
Further client diagnosis:
* Chrome 43 OS X renegotiates with the smart card if you open an incognito
window. The same behavior manifests itself in other incognito windows,
though, i.e. if you fail smart card auth it won’t go back and retry
smart card auth. This suggests to me that Chrome is doing some
client side SSLSessionCache, and they maintain different caches
for regular windows and incognito windows, but within each cache
the problem persists.
* Safari 8.0.6 OS X works as expected with the SSLSessionCache setting on the
server side. Dialing up the SSLSessionCache replicates the problem.
So it can be both a client and server side issue.
On Jun 3, 2015, at 5:16 PM, Scot Russell <sc...@hotmail.com> wrote:
I don't have an answer for you, a couple thoughts though, are you using an SSL cache that may be caching the info? I think there is a cache directive in mod ssl. Or is there software on the client for handling the smart card that could be set or configured
to renegotiate?
From: mcgredo@nps.edu
To: users@httpd.apache.org
Date: Wed, 3 Jun 2015 23:21:57 +0000
Subject: Re: [users@httpd] Client Auth Retries
This behavior is puzzling.
*Once the browser goes to the “mistake” page, it won’t renegotiate
the SSL connection with the smart card despite
- No open https connections to the server
- The behavior persists across a server restart
- The behavior persists across a “clear cache” on the client browser (Chrome)
The only way to force it to use the smart card auth appears to be quitting and restarting
the browser.
On Jun 2, 2015, at 3:18 PM, McGregor, Donald (Don) (CIV) <mc...@nps.edu> wrote:
I’m trying to set up client authentication using smart cards and be reasonably polite about
auth failures. A typical failure mode is that the user doesn’t have the card inserted; I
should send them to a warning page, then let them retry.
The relevant config file for the top level:
SSLVerifyClient optional
RewriteEngine On
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS
RewriteRule .* /mistake/index.html [L]
<Directory /var/www/html/mistake>
SSLVerifyClient none
</Directory>
Client auth is optional, but if it fails they see the informational
page telling them to use a smart card, in a directory
without smart card auth required.
This successfully rewrites to the informational page when they
don’t have the smart card inserted. The first time in If client auth fails for
some reason they see the error page, and if they do have
the card and authenticate, they see the expected content.
But if they see the error page, then insert the card, and then
try to go to the https://myhost/content, they continue to
see the error page. It seems as if the HTTPS connection
is not being renegotiated or that the SSL_CLIENT_VERIFY
is not being reset to SUCCESS on retry. Or is there a
better way to do this?
Re: [users@httpd] Client Auth Retries
Posted by "McGregor, Donald (Don) (CIV)" <mc...@nps.edu>.
I think that’s part of it—SSLSessionCache on the server was set to five minutes.
Dialing it down to 10 seconds seems to have solved the problem
on Safari, but it persists on Chrome, even after a server restart.
It fixes itself after a Chrome restart, so clearly Chrome is doing some caching
of something, somewhere.
What are the consequences of having a low SSLSessionCache value on the server?
Further client diagnosis:
* Chrome 43 OS X renegotiates with the smart card if you open an incognito
window. The same behavior manifests itself in other incognito windows,
though, i.e. if you fail smart card auth it won’t go back and retry
smart card auth. This suggests to me that Chrome is doing some
client side SSLSessionCache, and they maintain different caches
for regular windows and incognito windows, but within each cache
the problem persists.
* Safari 8.0.6 OS X works as expected with the SSLSessionCache setting on the
server side. Dialing up the SSLSessionCache replicates the problem.
So it can be both a client and server side issue.
On Jun 3, 2015, at 5:16 PM, Scot Russell <sc...@hotmail.com>> wrote:
I don't have an answer for you, a couple thoughts though, are you using an SSL cache that may be caching the info? I think there is a cache directive in mod ssl. Or is there software on the client for handling the smart card that could be set or configured to renegotiate?
________________________________
From: mcgredo@nps.edu<ma...@nps.edu>
To: users@httpd.apache.org<ma...@httpd.apache.org>
Date: Wed, 3 Jun 2015 23:21:57 +0000
Subject: Re: [users@httpd] Client Auth Retries
This behavior is puzzling.
*Once the browser goes to the “mistake” page, it won’t renegotiate
the SSL connection with the smart card despite
- No open https connections to the server
- The behavior persists across a server restart
- The behavior persists across a “clear cache” on the client browser (Chrome)
The only way to force it to use the smart card auth appears to be quitting and restarting
the browser.
On Jun 2, 2015, at 3:18 PM, McGregor, Donald (Don) (CIV) <mc...@nps.edu>> wrote:
I’m trying to set up client authentication using smart cards and be reasonably polite about
auth failures. A typical failure mode is that the user doesn’t have the card inserted; I
should send them to a warning page, then let them retry.
The relevant config file for the top level:
SSLVerifyClient optional
RewriteEngine On
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS
RewriteRule .* /mistake/index.html [L]
<Directory /var/www/html/mistake>
SSLVerifyClient none
</Directory>
Client auth is optional, but if it fails they see the informational
page telling them to use a smart card, in a directory
without smart card auth required.
This successfully rewrites to the informational page when they
don’t have the smart card inserted. The first time in If client auth fails for
some reason they see the error page, and if they do have
the card and authenticate, they see the expected content.
But if they see the error page, then insert the card, and then
try to go to the https://myhost/content, they continue to
see the error page. It seems as if the HTTPS connection
is not being renegotiated or that the SSL_CLIENT_VERIFY
is not being reset to SUCCESS on retry. Or is there a
better way to do this?
RE: [users@httpd] Client Auth Retries
Posted by Scot Russell <sc...@hotmail.com>.
I don't have an answer for you, a couple thoughts though, are you using an SSL cache that may be caching the info? I think there is a cache directive in mod ssl. Or is there software on the client for handling the smart card that could be set or configured to renegotiate?
From: mcgredo@nps.edu
To: users@httpd.apache.org
Date: Wed, 3 Jun 2015 23:21:57 +0000
Subject: Re: [users@httpd] Client Auth Retries
This behavior is puzzling.
*Once the browser goes to the “mistake” page, it won’t renegotiate
the SSL connection with the smart card despite
- No open https connections to the server
- The behavior persists across a server restart
- The behavior persists across a “clear cache” on the client browser (Chrome)
The only way to force it to use the smart card auth appears to be quitting and restarting
the browser.
On Jun 2, 2015, at 3:18 PM, McGregor, Donald (Don) (CIV) <mc...@nps.edu> wrote:
I’m trying to set up client authentication using smart cards and be reasonably polite about
auth failures. A typical failure mode is that the user doesn’t have the card inserted; I
should send them to a warning page, then let them retry.
The relevant config file for the top level:
SSLVerifyClient optional
RewriteEngine On
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS
RewriteRule .* /mistake/index.html [L]
<Directory /var/www/html/mistake>
SSLVerifyClient none
</Directory>
Client auth is optional, but if it fails they see the informational
page telling them to use a smart card, in a directory
without smart card auth required.
This successfully rewrites to the informational page when they
don’t have the smart card inserted. The first time in If client auth fails for
some reason they see the error page, and if they do have
the card and authenticate, they see the expected content.
But if they see the error page, then insert the card, and then
try to go to the https://myhost/content, they continue to
see the error page. It seems as if the HTTPS connection
is not being renegotiated or that the SSL_CLIENT_VERIFY
is not being reset to SUCCESS on retry. Or is there a
better way to do this?
Re: [users@httpd] Client Auth Retries
Posted by "McGregor, Donald (Don) (CIV)" <mc...@nps.edu>.
This behavior is puzzling.
*Once the browser goes to the “mistake” page, it won’t renegotiate
the SSL connection with the smart card despite
- No open https connections to the server
- The behavior persists across a server restart
- The behavior persists across a “clear cache” on the client browser (Chrome)
The only way to force it to use the smart card auth appears to be quitting and restarting
the browser.
On Jun 2, 2015, at 3:18 PM, McGregor, Donald (Don) (CIV) <mc...@nps.edu>> wrote:
I’m trying to set up client authentication using smart cards and be reasonably polite about
auth failures. A typical failure mode is that the user doesn’t have the card inserted; I
should send them to a warning page, then let them retry.
The relevant config file for the top level:
SSLVerifyClient optional
RewriteEngine On
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS
RewriteRule .* /mistake/index.html [L]
<Directory /var/www/html/mistake>
SSLVerifyClient none
</Directory>
Client auth is optional, but if it fails they see the informational
page telling them to use a smart card, in a directory
without smart card auth required.
This successfully rewrites to the informational page when they
don’t have the smart card inserted. The first time in If client auth fails for
some reason they see the error page, and if they do have
the card and authenticate, they see the expected content.
But if they see the error page, then insert the card, and then
try to go to the https://myhost/content, they continue to
see the error page. It seems as if the HTTPS connection
is not being renegotiated or that the SSL_CLIENT_VERIFY
is not being reset to SUCCESS on retry. Or is there a
better way to do this?