Security Vulnerability: Logged out users authenticated with X509 certificates can log back in without resending personal certificates using the same browser window

  • 7001788
  • 04-Nov-2008
  • 26-Apr-2012


Novell Access Manager 3 Linux Novell Identity Server
Novell Access Manager 3 Support Pack 4 applied
X509 authentication enabled on Identity Server
Problem common to Internet Explorer (IE) and Firefox browsers
Client certificates sent from browser to Identity Server


When a user authenticates using the standard Novell X509 authentication class using a certificate that is stored on a smartcard or within the browser certificate store, and the certificate validation process is successful, the user will see the target page on the browser. When the user is done and needs to logout of Access Manager, they will hit the logout link (/AGLogout on the Access Gateway or /nidp/app/plogout on the Identity Server) and get a message indicating that the user has been successfully logged out.

As long as the browser is not closed (user can even remove smartcard containing X509 certificate!), and the session timeouts have not expired, another user can come and take over the previous users session without being prompted to login again.


Make sure that the browser is closed after logging out of the Identity Server or Access Manager environment. This process can be automated using javascript within the logoutSuccess.jsp page. When a user logs out of Access Manager, the logout.jsp page is initially executed, followed by the logoutSuccess.jsp page assuming the logout request is successful. By injecting the following javascript into the logoutSuccess.jsp page, the user will be prompted to close the the browser:

<script type="text/javascript">

You can add a warning here so that users recognise the importance of closing the browser. There are other options to force the Window to close.

Another possible solution is to clear out the SSL cache on the browser after logout. This can be done by going to Internet Options -> Content -> Clear SSL State on IE for example.

Additional Information

The real issue here is twofold:

1. the browser, in the above case, does not do a full but partial SSL handshake. The client hello that is sent on the subsequent request after the user logs out includes an SSL sessionID, which the server still has reference to in it's cache. By closing the browser and reopening it, the SSL client hello will include an SSL sessionID on 0 and a full handshake will be performed with the SSL server.

2. the tomcat SSL server does not clear the cached entry upon logout of the Identity Server. There is a feature request to include this in future tomcat builds but so far it has not been made available (Apache has this option to clear the SSL state). The defect number for tracking purposes is available at When this is available, the Identity Server can interface into Tomcat's SSL cache and reset the session upon logout. The SSL key regeneration requirement is sent out by the server who initiates the Mutual SSL session (the Identity Server in our case) but as we interface into Tomcat and Tomcat does not provide the option to set this Mutual SSL key regeneration timer, we have to use the workarounds above.