Connection issues

If you run the application e.g. with the Java™ version 1.8.0_144 you might get the following exception:

Exception in thread "main" com.phoenixcontact.ade.commonremoting.CommonRemotingException: certificate_unknown(46)
                at com.phoenixcontact.ade.commonremoting.impl.CommonRemotingProvider.connect(CommonRemotingProvider.java:215)
                at com.phoenixcontact.arp.system.rsc.ServiceManager.connect(ServiceManager.java:201)
                at com.phoenixcontact.arp.system.rsc.ServiceManager.connect(ServiceManager.java:174)
                at com.phoenixcontact.arp.system.rsc.ServiceManager.connect(ServiceManager.java:99)
                at com.mw.Main.main(Main.java:23)
Caused by: org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
                at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(Unknown Source)
                at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(Unknown Source)
                at org.bouncycastle.tls.TlsUtils.processServerCertificate(Unknown Source)
                at org.bouncycastle.tls.TlsClientProtocol.handleServerCertificate(Unknown Source)
                at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(Unknown Source)
                at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(Unknown Source)
                at org.bouncycastle.tls.TlsProtocol.processRecord(Unknown Source)
                at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source)
                at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
                at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
                at org.bouncycastle.tls.TlsClientProtocol.connect(Unknown Source)
                at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
                at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
                at com.phoenixcontact.arp.system.rsc.security.SslCommunicationChannel.connect(SslCommunicationChannel.java:114)
                at com.phoenixcontact.ade.internal.commonremoting.impl.RemotingStream.connect(RemotingStream.java:94)
                at com.phoenixcontact.ade.internal.commonremoting.impl.TransportSink.connect(TransportSink.java:92)
                at com.phoenixcontact.ade.commonremoting.impl.CommonRemotingProvider.connect(CommonRemotingProvider.java:197)
                ... 4 more
Caused by: java.security.cert.CertificateException: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
                at com.phoenixcontact.arp.system.rsc.security.PkixTrustManager.checkServerTrusted(PkixTrustManager.java:193)
                at org.bouncycastle.jsse.provider.ImportX509TrustManager_5.checkServerTrusted(Unknown Source)
                ... 21 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
                at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
                at java.security.cert.PKIXParameters.<init>(http://PKIXParameters.java:120)
                at com.phoenixcontact.arp.system.rsc.security.PkixTrustManager.checkServerTrusted(PkixTrustManager.java:151)
                ... 22 more

and the log message:

java.io.IOException: exception decrypting data - java.security.InvalidKeyException: Illegal key size

The reason for this issue is the limitation of AES to 128 bit key by the default JDK.

Execute the below steps to resolve the issue:

  1. Go to the Oracle website and search for ‘Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files’.
  2. Download the *.zip file for your Java version and extract it on your drive.
  3. From the extracted folder, copy local_policy.jar and US_export_policy.jar files.
  4. Go to your _java_installation_directory/jre/lib/security and paste the copied files. These files will already be there, you just need to copy and replace.
  5. Run your application.

The problem should be solved.

Delays caused by random number generation

If you are running your application on the platform the SSLContext initialization with BouncyCastle could take quite a long time (up to 15 minutes) due to a low entropy platform. The library used for random number generation relies on /dev/random by default for UNIX platforms. This can block the process because on some operating systems /dev/random waits for a certain amount of “noise” to be generated before returning a result.

There are several solutions:

  • Disable TLS verification.
  • Use the SUN Provider if it is possible in your scenario.
  • Although /dev/random is more secure, you could use /dev/urandom
    • Open $JAVA_HOME/lib/security/java.security or for Java 9 $JAVA_HOME/conf/security/java.security
    • Change the line securerandom.source=file:/dev/random to securerandom.source=file:/dev/urandom
    • It might also be required to change securerandom.strongAlgorithms=NativePRNGBlocking:SUN to securerandom.strongAlgorithms=NativePRNGNonBlocking:SUN
    • Restart your application.

Connection is closed after some time

The RSC connection will be closed after 5 minutes by default if there is no communication between client and device.

If you don’t want the connection to be closed you have to call a RSC service method regularly. Currently there is no keep alive mechanism.


Warning: Root privileges on the device are needed. We do not recommend and support this.


An other option is to disable the timeout. You have to set the sessionTimeout value to 0 and restart the PLCnext. You must be the root user to edit the file.
The timeout is specified in the /etc/plcnext/device/System/RscGateway/RscGateway.settings file by the sessionTimeout attribute in the TcpGatewaySettings. The session timeout determines the time in milliseconds after a remoting connection is discarded if no communication occurs.

<TcpGatewaySettings gatewayId="1" tcpPort="41100" sessionTimeout="300000" encrypted="true" identityStore="IDevID" />

The first connection setup takes a lot of time

If you run the application on the device, the first connection attempt might take up to 35 seconds. The reason is the initialization time of the cipher suites and Bouncy Castle provider. You can call the com.phoenixcontact.arp.system.rsc.ServiceManager.initialize() method to do the initialization beforehand.