Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Liferay seems to think JDBC connection is secured when it isn't
This hasn't my best month with Liferay...at least attempting to get everything working smoothly on 7.3.2 CE. Here is the latest challenge:
I WAS using the JTDS JDBC driver for connections to Microsoft SQL Server (2017) but when I upgraded to 7.3.2 I started getting errors on isValid() when connecting and I think it has something to do with a requirement for a JDBC 4.0 driver. Not sure. Couldn't fix it so I changed to the MS SQL JDBC driver mssql-jdbc-8.2.0.jre8.jar But now I get the following stack trace which seems to indicate an SSL connection / encryption error and the connection is definitely NOT encrypted:
I don't know why it is thinking the connection is encrypted because it is not.
Specs are:
CentOS 8
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)Liferay 7.32 Tomcat bundle.
Completely stumped here. Any ideas?
I WAS using the JTDS JDBC driver for connections to Microsoft SQL Server (2017) but when I upgraded to 7.3.2 I started getting errors on isValid() when connecting and I think it has something to do with a requirement for a JDBC 4.0 driver. Not sure. Couldn't fix it so I changed to the MS SQL JDBC driver mssql-jdbc-8.2.0.jre8.jar But now I get the following stack trace which seems to indicate an SSL connection / encryption error and the connection is definitely NOT encrypted:
2020-06-23 01:38:17.698 ERROR [Start Level: Equinox Container: 6dfef227-7479-4240-9151-62b4980af0e3][HikariPool:541] HikariPool-3 - Exception during pool initialization.
com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "java.security.cert.CertificateException: Certificates do not conform to algorithm constraints". ClientConnectionId:e7a5ebc2-d489-4743-85ba-7873926508fe
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:2998)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1884)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2558)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:2216)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:2067)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:1204)
at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:825)
at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:112)
at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:118)
at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:358)
at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:201)
at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:443)
at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:514)
at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:111)
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:97)
at com.liferay.portal.dao.jdbc.util.DBInfoUtil.lambda$getDBInfo$0(DBInfoUtil.java:47)
at com.liferay.petra.concurrent.ConcurrentMapperHashMap.lambda$computeIfAbsent$1(ConcurrentMapperHashMap.java:114)
at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
at com.liferay.petra.concurrent.ConcurrentMapperHashMap.computeIfAbsent(ConcurrentMapperHashMap.java:111)
at com.liferay.portal.dao.jdbc.util.DBInfoUtil.getDBInfo(DBInfoUtil.java:44)
at com.liferay.portal.spring.hibernate.DialectDetector.getDialect(DialectDetector.java:51)
at com.liferay.portal.spring.hibernate.PortalHibernateConfiguration.newConfiguration(PortalHibernateConfiguration.java:198)
at org.springframework.orm.hibernate3.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:507)
at com.liferay.portal.spring.hibernate.PortalHibernateConfiguration.buildSessionFactory(PortalHibernateConfiguration.java:95)
at com.liferay.portal.spring.extender.internal.LiferayServiceExtender$LiferayServiceExtension.start(LiferayServiceExtender.java:146)
at com.liferay.portal.spring.extender.internal.LiferayServiceExtender.addingBundle(LiferayServiceExtender.java:81)
at com.liferay.portal.spring.extender.internal.LiferayServiceExtender.addingBundle(LiferayServiceExtender.java:59)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:475)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:1)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:230)
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:137)
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:129)
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:191)
at org.eclipse.osgi.container.Module.publishEvent(Module.java:476)
at org.eclipse.osgi.container.Module.doStart(Module.java:578)
at org.eclipse.osgi.container.Module.start(Module.java:449)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1682)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1662)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1624)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1555)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints
at sun.security.ssl.Alerts.getSSLException(Alerts.java:198)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1967)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:331)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:325)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1688)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1082)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:1010)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1079)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1388)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1416)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1400)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1802)
... 47 more
Caused by: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints
at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1236)
at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1158)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1100)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1670)
... 55 more
Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on keysize limits. RSA 1024bit key used with certificate: CN=SSL_Self_Signed_Fallback. Usage was tls server
at sun.security.util.DisabledAlgorithmConstraints$KeySizeConstraint.permits(DisabledAlgorithmConstraints.java:817)
at sun.security.util.DisabledAlgorithmConstraints$Constraints.permits(DisabledAlgorithmConstraints.java:419)
at sun.security.util.DisabledAlgorithmConstraints.permits(DisabledAlgorithmConstraints.java:167)
at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:332)
at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1232)
... 58 more
2020-06-23 01:38:17.702 ERROR [Start Level: Equinox Container: 6dfef227-7479-4240-9151-62b4980af0e3][LiferayServiceExtender:86] com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "java.security.cert.CertificateException: Certificates do not conform to algorithm constraints". ClientConnectionId:e7a5ebc2-d489-4743-85ba-7873926508fe
com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption.</init>I don't know why it is thinking the connection is encrypted because it is not.
Specs are:
CentOS 8
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)Liferay 7.32 Tomcat bundle.
Completely stumped here. Any ideas?
I think your cert is not secure enough. Use an rsa key that is greater than or equal to 1024 bits.
That is what I would gather, reading through the stack trace except there ISN'T a secure connection. It's just a regular old unencrypted connection on port 1433. If it isn't encrypted, if we aren't using SSL to secure the connection, if it works unencrypted with the JTDS driver, then why does the MS driver, or Liferay, think the connection IS secure when it isn't...?
You mention Liferay Portal CE 7.3.2 and SqlServer. In this combination, I expect Liferay not to think anything: I'd rather expect it not to work, as CE doesn't support commercial databases. Or did this change and I didn't notice?
Do you use https://github.com/amusarra/liferay-portal-database-all-in-one-support?
The commit log says that version 1.21 was updated and works with Liferay 7.3.2, so maybe there were some changes? So, maybe you need to upgrade that package?
Otherwise, can you please show us the connection string? You can of course "anonymize" it, but maybe it gives us an idea.
The commit log says that version 1.21 was updated and works with Liferay 7.3.2, so maybe there were some changes? So, maybe you need to upgrade that package?
Otherwise, can you please show us the connection string? You can of course "anonymize" it, but maybe it gives us an idea.
Thanks. No, I am not using Amusarra's "shim" although I do using it in the 7.0.6 version I am running. I thought the restriction was lifted from CE at a later release but maybe is wasn't and maybe now the message which used to be something like "This version of Liferay doesn't support Microsoft SQL server" isn't displaying any more. I'll try the Amusarra work around and see if that make a difference.
However, I am running 7.3.2 in Windows on my development PC and it displays none of this behavior even though I am using an mssql datasource. Works perfectly. I am not using Amusarra's jar but I am using the portal-ext.properties file to connect using JDBC alias' to connect to external data sources as described here: https://help.liferay.com/hc/en-us/articles/360032978871-Connecting-the-Data-Source-Using-a-DataSourceProvider (I couldn't get JNDI to work) .... So, maybe the JDBC route instead of the JNDI route bypasses the restriction on mssql data sources? I don't know? But I'll see what I can do with the Amusarra approach in Linux.
However, I am running 7.3.2 in Windows on my development PC and it displays none of this behavior even though I am using an mssql datasource. Works perfectly. I am not using Amusarra's jar but I am using the portal-ext.properties file to connect using JDBC alias' to connect to external data sources as described here: https://help.liferay.com/hc/en-us/articles/360032978871-Connecting-the-Data-Source-Using-a-DataSourceProvider (I couldn't get JNDI to work) .... So, maybe the JDBC route instead of the JNDI route bypasses the restriction on mssql data sources? I don't know? But I'll see what I can do with the Amusarra approach in Linux.
I don't think that the restriction applies to external datasources. Do you use MS SQL only for the external datasources?
Can you try to add encrypt=false to the connection string? Maybe the setting defaults to true with some driver versions?
The cipher configurations are sometimes updated, there are several limits to the keysize depending on the Java version.
https://www.java.com/en/configure_crypto.html
If you do, I would not advise to "fix" the limit, I would fix the certificate. The cn seems to be CN=SSL_Self_Signed_Fallback and that doesn't look correct anyway.
Can you try to add encrypt=false to the connection string? Maybe the setting defaults to true with some driver versions?
jdbc:sqlserver://yourserver:1433;databaseName=Something;encrypt=falseThe cipher configurations are sometimes updated, there are several limits to the keysize depending on the Java version.
https://www.java.com/en/configure_crypto.html
If you do, I would not advise to "fix" the limit, I would fix the certificate. The cn seems to be CN=SSL_Self_Signed_Fallback and that doesn't look correct anyway.
So, just to fill in all the remaining blanks here: I have a 7.0.6 LR CE that connects to the same SQL Server from the same Linux server but it is running a JTDS driver (JDBC 3.0) and using JNDI to connect. The 7.3.2 CE uses the JDBC connection through the portal-ext.properties file. I would expect that if JTDS can connect to the same SQL server without any encryption settings the same would apply to JDBC connections, even though it is using MS JDBC driver. I'll have to do some trial and error. Maybe use the MS driver instead of the MS driver in 7.0.6 and see what happens...
I'll just edit this: I tried using the Microsoft JDBC driver on my 7.0.6 CE instance. It causes the same issue there. So, I know it has nothing to do with Liferay. It has something to do with the Microsoft driver and Linux. The only reason that I am using the MS driver is because of the isValid() error I get with LR 7.3.2 and the JTDS driver. Does anyone know if LR 7.3.2 CE is requiring a JDBC 4.0 driver? It seems so since the isValid method call is a requirement of the JDBC 4.0 spec (I think)
I'll just edit this: I tried using the Microsoft JDBC driver on my 7.0.6 CE instance. It causes the same issue there. So, I know it has nothing to do with Liferay. It has something to do with the Microsoft driver and Linux. The only reason that I am using the MS driver is because of the isValid() error I get with LR 7.3.2 and the JTDS driver. Does anyone know if LR 7.3.2 CE is requiring a JDBC 4.0 driver? It seems so since the isValid method call is a requirement of the JDBC 4.0 spec (I think)
SOLVED
So, this basically was a black hole for my time as I pursued many dead ends on this. #1 Finding: As far as I know, this connection is NOT secured. Checked all the settings on the SQL 2012 server, there was nothing to indicate that the connection was secured. #2 I finally got to the trial and error stage where I compared the Windows 10 implementation with what was on the CentOS 8 server. I tried copying the cacerts file and finally grabbed the java.security file from the Windows 10 instance and it worked! The ONLY difference I could see was in this section:
#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageDefinition unless the
# corresponding RuntimePermission ("defineClassInPackage."+package) has
# been granted.
#
# by default, none of the class loaders supplied with the JDK call
# checkPackageDefinition.
At the end of the list in CentOS 8 was:
org.GNOME.Accessibility.,\
org.GNOME.Bonobo.
Whereas at the end of the list in Windows was:
com.sun.java.accessibility.
I have no idea of what those entries mean or why they would have somehow gotten the driver to think it was secured but that was the "fix". The driver is now happily connecting to the DB.
So, this basically was a black hole for my time as I pursued many dead ends on this. #1 Finding: As far as I know, this connection is NOT secured. Checked all the settings on the SQL 2012 server, there was nothing to indicate that the connection was secured. #2 I finally got to the trial and error stage where I compared the Windows 10 implementation with what was on the CentOS 8 server. I tried copying the cacerts file and finally grabbed the java.security file from the Windows 10 instance and it worked! The ONLY difference I could see was in this section:
#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageDefinition unless the
# corresponding RuntimePermission ("defineClassInPackage."+package) has
# been granted.
#
# by default, none of the class loaders supplied with the JDK call
# checkPackageDefinition.
At the end of the list in CentOS 8 was:
org.GNOME.Accessibility.,\
org.GNOME.Bonobo.
Whereas at the end of the list in Windows was:
com.sun.java.accessibility.
I have no idea of what those entries mean or why they would have somehow gotten the driver to think it was secured but that was the "fix". The driver is now happily connecting to the DB.
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™