Issue in SSL implementation - Using Weblogic as Application Server

[Brajesh Singh, geändert vor 8 Jahren.]

We are facing issues in SSL implementation for Liferay Portal. Using Weblogic as Application server. We have implemented all SSL related configuration on Weblogic end correctly. Added identity certificate chain (lgsportalXXXX.corp.XXXX.com.chain.pem) at following locations -

/ngs/app/lgsXXX/jdk1.7.0_71/jre/lib/security/cacerts
/ngs/app/lgsXXX/jdk1.7.0_71/jre/lib/security/cacerts
/ngs/app/lgsXXX/Oracle/Middleware/user_projects/domains/liferay/certs - location of identity and keystore file.

We have enabled debug logs for SSL and observing following errors in Managed server log -

####<May 11, 2015 11:58:09 PM GMT+00:00> <Debug> <SecuritySSL> <ma-XXXXXXX-lapp01.corp.XXX.com> <ms1> <ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'> <<WLS Kernel>> <> <> <1431388689321> <BEA-000000> <[Thread[ExecuteThread: '1' for queue: 'weblogic.socket.Muxer',5,Thread Group for Queue: 'weblogic.socket.Muxer']]weblogic.security.SSL.jsseadapter: SSLENGINE: SSLEngine.unwrap(ByteBuffer,ByteBuffer[]) called: result=Status = OK HandshakeStatus = NOT_HANDSHAKING
bytesConsumed = 1525 bytesProduced = 1470.>
####<May 11, 2015 11:58:09 PM GMT+00:00> <Debug> <SecuritySSL> <ma-XXXX-XXXX.corp.apple.com> <ms1> <ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'> <<WLS Kernel>> <> <> <1431388689321> <BEA-000000> <Exception processing certificates: peer not authenticated
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:421)
at weblogic.servlet.internal.VirtualConnection.initSSLAttributes(VirtualConnection.java:176)
at weblogic.servlet.internal.VirtualConnection.init(VirtualConnection.java:78)
at weblogic.servlet.internal.ServletRequestImpl.initFromRequestParser(ServletRequestImpl.java:269)
at weblogic.servlet.internal.MuxableSocketHTTP.dispatch(MuxableSocketHTTP.java:321)
at weblogic.socket.JSSEFilterImpl.dispatch(JSSEFilterImpl.java:202)
at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:965)
at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:897)
at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:130)
at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)

Basic architecture details - One Admin Server and One Managed Server. Application is deployed on Managed server. It's our development environment.

When we try to access using https url. It gets re-directed to http url and fails - as it's having https protocol in beginning. If I add https port number to this url manually - redirection works fine. For SSL implementation do we need to make at property file changes on the application end as well? Liferay application is looking out for certificates at what location? Please assist.

Let me know if any more details are needed.

[David H Nebinger, geändert vor 8 Jahren.]

Is this really a Liferay issue? I'm just wondering if this isn't a typical WebLogic issue with a (hopefully) simple WebLogic solution?

[Brajesh Singh, geändert vor 8 Jahren.]

RE: Issue in SSL implementation - Using Weblogic as Application Server

[Jack Bakker, geändert vor 8 Jahren.]

I have never let web container deal with SSL so can't help here. I put apache httpd in front to deal with http and https with then use a mod_jk connector to web container. I had to look once or twice into IIS (instead of apache httpd, given windows platform obligations) but IIS rewrite options are very limited compared to the power of apache httpd configs/features.

[David H Nebinger, geändert vor 8 Jahren.]

Sometimes, Jack, an organization will want SSL (encryption) between all endpoints, even internal ones. I think it depends upon the type of data you'd move between the links, sometimes it's just a boyscout using his "be prepared" motto to the fullest, sometimes it's an org protecting itself from incursion, sometimes it's just outright paranoia.