Environment
NetIQ Access Manager 3.2
NetIQ Access Manager 3.2 Support Pack 2 applied
NetIQ Access Manager 3.2 Identity Server
Users accessing protected resources requiring X509 authentication and simple Name/Password based Authentication
NetIQ Access Manager 3.2 Support Pack 2 applied
NetIQ Access Manager 3.2 Identity Server
Users accessing protected resources requiring X509 authentication and simple Name/Password based Authentication
Situation
Access Manager 3.2.2 setup and running fine. The identity server is running on a
SLES 11 SP2 64-bit, fully patched server.
Multiple contracts including X509 and Secure Name Password enabled on the Identity Server.
Users, when their browsers are properly pre-configured with a User certificate, are able to login just fine using client certificates. However, when a browser without any imported client certificates on any device type tries to access a site secured with that x509 method, even when the IDP "Component File Logger Levels" are all set to off or info, multiple Java exceptions are written to the catalina.out file. With this site potentially getting 1000s of hits a day, concerns were raised about the content of the catalina log files.
Ideally, if the browser doesn't have a User certificate to hand back, we just need print a single line or two of a properly handled/worded error message. Here's the message that is reported back ...
Mar 22, 2013 1:57:27 PM org.apache.tomcat.util.net.jsse.JSSESupport handShake INFO: Error trying to obtain a certificate from the client javax.net.ssl.SSLProtocolException: handshake alert: no_certificate at com.sun.net.ssl.internal.ssl.ServerHandshaker.handshakeAlert(ServerHandshaker.java:1330) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1799) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:986) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:787) at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75) at java.io.InputStream.read(InputStream.java:82) at org.apache.tomcat.util.net.jsse.JSSESupport.handShake(JSSESupport.java:186) at org.apache.tomcat.util.net.jsse.JSSESupport.getPeerCertificateChain(JSSESupport.java:153) at org.apache.coyote.http11.Http11Processor.actionInternal(Http11Processor.java:343) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:834) at org.apache.coyote.Request.action(Request.java:344) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
Multiple contracts including X509 and Secure Name Password enabled on the Identity Server.
Users, when their browsers are properly pre-configured with a User certificate, are able to login just fine using client certificates. However, when a browser without any imported client certificates on any device type tries to access a site secured with that x509 method, even when the IDP "Component File Logger Levels" are all set to off or info, multiple Java exceptions are written to the catalina.out file. With this site potentially getting 1000s of hits a day, concerns were raised about the content of the catalina log files.
Ideally, if the browser doesn't have a User certificate to hand back, we just need print a single line or two of a properly handled/worded error message. Here's the message that is reported back ...
Mar 22, 2013 1:57:27 PM org.apache.tomcat.util.net.jsse.JSSESupport handShake INFO: Error trying to obtain a certificate from the client javax.net.ssl.SSLProtocolException: handshake alert: no_certificate at com.sun.net.ssl.internal.ssl.ServerHandshaker.handshakeAlert(ServerHandshaker.java:1330) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1799) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:986) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:787) at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75) at java.io.InputStream.read(InputStream.java:82) at org.apache.tomcat.util.net.jsse.JSSESupport.handShake(JSSESupport.java:186) at org.apache.tomcat.util.net.jsse.JSSESupport.getPeerCertificateChain(JSSESupport.java:153) at org.apache.coyote.http11.Http11Processor.actionInternal(Http11Processor.java:343) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:834) at org.apache.coyote.Request.action(Request.java:344) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
Resolution
Fixed in 3.2.2 IR1.
Additional Information
The /opt/novell/nam/idp/conf/logging.properties file was changed to remove this.